alignment exception reading xing header

[Paul Forgey]

In line 1666 of mp3-scanner.c from the the 0.2.3 release (right after debug logging “Found Xing header”):

xing_flags=*((int*)&buffer[index+fi.xing_offset+4+4]);

This can cause a problem on non-x86 based platforms where alignment matters. Certain files are causing mt-daapd to crash on my sparc linux machine with a bus error. This should be a memcpy, not a dereference and assignment since (index+fi.xing_offset) & 0x3 isn’t guaranteed.

Same for line 1674:

fi.number_of_frames=*((int*)&buffer[index+fi.xing_offset+4+8]);

These are the only two places I have found so far where this is being done. After making these changes it appears I am up and running.

[rpedde]

Hrm. I usually know better than this, but I’m actually kind of surprised this hasn’t been caught before. In fact, I didn’t realize the xscale didn’t sigbus on unaligned. Would have thought the nslu2 platform would have died, too.

I’ll fix that in next nightlies.

Do you have a solaris sparc box?

I really really need a solaris tester.

[Paul Forgey]

Linux sparc, not Solaris. Best I can do for you is test your code isn’t mis-assuming byte order or alignment, but otherwise the user mode stuff is identical to any other linux, including x86.

AFAIK the x86 is the only common architecture that lets you get away with accessing unaligned pointers, and even while it won’t complain it will hurt performance.

[rpedde]

Yeah, that’s what I thought too… except I develop on ppc (osx) and hadn’t seen it on this machine. Guess I just got lucky.

I looked up arm, though, and it looks like it does allow unaligned access, just like x86 — that explains why I didn’t see it on the NSLU2.

— Ron

[Paul Forgey]

I did say AFAIK :). Contrary to what I thought, I just verified my OSX-ppc machine allows unaligned pointers too, so you wouldn’t have come across it.

[Author]

Posts