- This topic has 4 replies, 2 voices, and was last updated 19 years ago by
.
-
Posts
-
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.
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.
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.
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
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.
- The forum ‘General Discussion’ is closed to new topics and replies.