What are the meaning of the items in the "alignment trap" error message?

Question

During my debugging, I got the following error message.

Alignment trap: my_main (29858) PC=0x00170ad8 Instr=0xe5960008 Address=0x00f28daa FSR 0x0f3

I've looked around a bit and found a lot of information on this (broken link) real-time embedded website . So now I know what PC and Instr refers to, but I still haven't found anything about the Address and FSR part.

What is FSR? What address does Address refer to? According to proc/xxxx/maps that address is even outside the scope of my program. Does anybody know what the last two items mean? I need information on these to solve this alignment problem.

MAP output

00008000-001fe000 r-xp 00000000 03:02 16204      /home/myuser/my_main
00205000-00248000 rw-p 001f5000 03:02 16204      /home/myuser/my_main
00248000-00299000 rwxp 00248000 00:00 0
40000000-40018000 r-xp 00000000 03:01 2095       /lib/ld-2.3.3.so
40018000-4001b000 rw-p 40018000 00:00 0
4001f000-40020000 r--p 00017000 03:01 2095       /lib/ld-2.3.3.so
40020000-40021000 rw-p 00018000 03:01 2095       /lib/ld-2.3.3.so
40021000-40023000 r-xp 00000000 03:01 15724      /usr/lib/libem7.so.1.0.1
40023000-40029000 ---p 00002000 03:01 15724      /usr/lib/libem7.so.1.0.1
40029000-4002b000 rw-p 00000000 03:01 15724      /usr/lib/libem7.so.1.0.1
4002b000-40031000 r-xp 00000000 03:01 2057       /lib/tls/librt-2.3.3.so
40031000-40033000 ---p 00006000 03:01 2057       /lib/tls/librt-2.3.3.so
40033000-40038000 rw-p 00000000 03:01 2057       /lib/tls/librt-2.3.3.so
40038000-40039000 r--p 00005000 03:01 2057       /lib/tls/librt-2.3.3.so
40039000-4003a000 rw-p 00006000 03:01 2057       /lib/tls/librt-2.3.3.so
4003a000-4004a000 r-xp 00000000 03:01 2060       /lib/tls/libpthread-2.3.3.so
4004a000-40051000 rw-p 00008000 03:01 2060       /lib/tls/libpthread-2.3.3.so
40051000-40052000 r--p 0000f000 03:01 2060       /lib/tls/libpthread-2.3.3.so
40052000-40053000 rw-p 00010000 03:01 2060       /lib/tls/libpthread-2.3.3.so
40053000-40055000 rw-p 40053000 00:00 0
40055000-4010e000 r-xp 00000000 03:01 15703      /usr/lib/libstdc++.so.6.0.3
4010e000-40115000 ---p 000b9000 03:01 15703      /usr/lib/libstdc++.so.6.0.3
40115000-40119000 rw-p 000b8000 03:01 15703      /usr/lib/libstdc++.so.6.0.3
40119000-4011f000 rw-p 40119000 00:00 0
4011f000-401b7000 r-xp 00000000 03:01 2076       /lib/tls/libm-2.3.3.so
401b7000-401be000 rw-p 00090000 03:01 2076       /lib/tls/libm-2.3.3.so
401be000-401bf000 r--p 00097000 03:01 2076       /lib/tls/libm-2.3.3.so
401bf000-401c0000 rw-p 00098000 03:01 2076       /lib/tls/libm-2.3.3.so
401c0000-401c8000 r-xp 00000000 03:01 2005       /lib/libgcc_s.so.1
401c8000-401c9000 rw-p 00008000 03:01 2005       /lib/libgcc_s.so.1
401c9000-402cb000 r-xp 00000000 03:01 2078       /lib/tls/libc-2.3.3.so
402cb000-402d1000 ---p 00102000 03:01 2078       /lib/tls/libc-2.3.3.so
402d1000-402d2000 rw-p 00100000 03:01 2078       /lib/tls/libc-2.3.3.so
402d2000-402d4000 r--p 00101000 03:01 2078       /lib/tls/libc-2.3.3.so
402d4000-402d6000 rw-p 00103000 03:01 2078       /lib/tls/libc-2.3.3.so
402d6000-402d8000 rw-p 402d6000 00:00 0
402d8000-402e5000 rw-s 00000000 00:07 0          /SYSV12345678 (deleted)
402e5000-402e6000 ---p 402e5000 00:00 0
402e6000-402f5000 rwxp 402e6000 00:00 0
403c1000-4049d000 rw-p 403c1000 00:00 0
7efeb000-7f000000 rwxp 7efeb000 00:00 0

Solution 1

PC=0x00170ad8

This is telling you the current value of the program counter, it can be used to determine which instruction in your program is causing the trap. If you’re on ARM as I think you are, this is actually the current instruction plus 8, so the instruction causing the trap is located at 0x00170ad0.

Instr=0xe5960008

This is the encoding of the faulting instruction. If this is on ARM, that instruction is ldr r0, [r6, #8]

Address=0x00f28daa

This is telling you the address from which your program attempted to load, causing the fault. Assuming everything else so far is correct, this is r6 + 8, so r6 held 0x00f28da2 at the time of the fault.

FSR 0xf3

This is the value held in the fault status register. It tells you what fault occurred. This particular value is an older encoding (pre-ARMv7) for an Alignment fault.

Solution 2

Most likely your CPU does not support reads/writes from/to memory of values at misaligned addresses. If you're accessing a 4-byte variable, then clearly Address=0x00f28daa isn't a multiple of 4. Only single bytes can be read/written at arbitrarily aligned addresses.

That article explains it well.

Comments

[Naze Kimi]

Thank you for your answer. But I guess my question was not clear. I actually wanted to know what exactly those items refer to. Are they memory addresses being read or written to? I need information about what that address is to solve this alignment problem.

[Alexey Frunze]

0x00f28daa isn't in the map. I bet it's a pointer obtained with pointer arithmetic and/or pointer casting and it points to some data either in the data section (rodata and bss included) or on the stack or in the heap. Run your code in the debugger. You'll find out quickly the problematic place.

[Alexey Frunze]

Another possibility is that you have an uninitialized or corrupted pointer.

[Alexey Frunze]

Downvote? Was this answer wrong w.r.t. the problem? Or insufficiently detailed/convincing/etc?

[Adam Bowen]

The answer doesn't answer the question, the question is about the meaning of the output, not the cause of the output.

[Naze Kimi]

@Alexey, cheers mate. I don't know who down voted you, but I think Adam's comment has a point.

[Naze Kimi]

One more thing, how did you know "Instr=0xe5960008" is "ldr r0, [r6, #8]". The objdump indeed says so.

[Stephen Canon]

@NazeKimi: I just decoded it by referring to the ARM reference manual.