1

I do have with memcpy (depending on params) a warning/error: Alignment trap

I understand it like that, that pointers are not aligned. But in my special case it is strange, that are u8*. And, sometimes there are this messages, sometimes not. It seems that memcp itself works fine (so result seems to be ok). I can’t see a coincidence when it is ok and when not ?!?

u32 pictureCopy(u8 *to, u32 *from)
{
  u32 expected_size;
  u8 *source;
  u8 *target;
  u32 *counter;
  u32 *size;
  ....
  counter = from-2;
  size = from-1;

    source = (u8 *)from;
    target = to;

    for (int i=0; i<expected_size/2 ; i+= saved_image_setting2.width) {
      printf("\n# i, target, source, size %i, %p, %p, %i\n", i, &target[i], &source[i], saved_image_setting2.width);
      sleep(1);
      memcpy(&target[i], &source[i], saved_image_setting2.width);
      sleep(1);
      printf("\nend %i\n", i);
    }

Output is like that:

# i, target, source, size 0, 0xb500800a, 0xb5cf2008, 84
Alignment trap: sps (1493) PC=0xb6e1ced4 Instr=0x14913004 Address=0xb5cf2056 FSR 0x011
end 0
#i, target, source, size 84, 0xb500805e, 0xb5cf205c, 84
end 84

## i, target, source, size 168, 0xb50080b2, 0xb5cf20b0, 84
Alignment trap: sps (1493) PC=0xb6e1ced4 Instr=0x14913004 Address=0xb5cf20fe FSR 0x011
end 168
## i, target, source, size 252, 0xb5008106, 0xb5cf2104, 84
end 252

Looking at the pointers, first is always not a multiple of 4, but 2nd pointer is. Length is same! I don’t understand. What is problem and what differes between this lines.

Testing this with valgrind doesn’t give me a clue. valgrind --leak-check=yes

Rishikesh Raje
  • 8,556
  • 2
  • 16
  • 31
Arno
  • 257
  • 1
  • 10
  • hmmm so... `from` is always aligned for u32? – Antti Haapala -- Слава Україні Oct 25 '18 at 08:00
  • If `from` is indeed always aligned then seems like a compiler bug... – Antti Haapala -- Слава Україні Oct 25 '18 at 08:02
  • Please format your question correctly. – Jabberwocky Oct 25 '18 at 08:27
  • Problem might be in implementation of memcpy. If it make copy by using words instead of bytes, and there is bug/misconfiguration in alignment handling. – SKi Oct 25 '18 at 09:11
  • What's your OS and exact hardware? – Andrew Henle Oct 25 '18 at 09:28
  • Mh, even if 'from' is not 32byte aligned - it is transformed to a 8bit-pointer -> source. And both pointers are at multiple of 2, so 16bit aligned. It seems every second memcpy rises a trap, but I can't see a difference for these?
    Hardware is a Zynq, dual core A9 ARM, OS is Yocto Linux     – Arno Oct 25 '18 at 09:33
  • Is it actual RAM or Device memory like a framebuffer? ARM is picky about unaligned access in “not normal memory”.... – mevets Oct 25 '18 at 19:57
  • @mevets: Thanks for this hint. I didn't keep that in mind but in fact, that function is to transfer data from RAM outside Linux (data come from FPGA to DDR-memory, this part is divided from Linux by devicetree) to internal (cached) RAM, as manipulating this RAM outside is much to slow. Ok, but that doesn't explain, why every second copy generates a trap - at least taking into account that pointers seems to be in each case same ?!? Even more strange - running that code with valgrind shows no Alignment trap. – Arno Oct 26 '18 at 05:57
  • Replace your memcpy with a hand written routine. As far as I ever looked into this, the A9 was capricious about these things. I had to debug something where mutexes had been put into an uncached memory area. Some times they worked; sometimes the store-conditional would fail. Most spinlocks assume that the only SC-failure is contention, so retry forever. – mevets Oct 26 '18 at 13:26

0 Answers0