GNOME Bugzilla – Bug 500833
[FFT] Struct alignment issues on sparc
Last modified: 2009-01-16 11:43:45 UTC
Hi, since we enabled to run the unit test suite on the Debian build servers there were some unit test failures on various architectures: For all architectures the pipelines/theoraenc unit test failed: Running suite(s): theoraenc 33%: Checks: 3, Failures: 2, Errors: 0 pipelines/theoraenc.c:58:F:general:tf:0: expected duration 0:00:00.100000000, but got duration 0:00:00.200000000 pipelines/theoraenc.c:58:F:general:tf:0: expected duration 0:00:00.100000000, but got duration 0:00:00.200000000 FAIL: pipelines/theoraenc This is with libtheora 1.0~beta2. ------------------------------------ On powerpc/s390 pipelines/streamheader and elements/gdpdepay failed: Running suite(s): gdpdepay 66%: Checks: 3, Failures: 1, Errors: 0 elements/gdpdepay.c:372:F:general:tf:0: Assertion 'GST_BUFFER_FLAG_IS_SET (outbuffer, GST_BUFFER_FLAG_IN_CAPS)' failed FAIL: elements/gdpdepay Running suite(s): streamheader 50%: Checks: 2, Failures: 1, Errors: 0 pipelines/streamheader.c:203:F:general:tf:0: 'n_in_caps' (0) is not equal to '3' (3) FAIL: pipelines/streamheader this seems to be similar to the core unit test failure on those archs: Running suite(s): data protocol 80%: Checks: 5, Failures: 1, Errors: 0 libs/gdp.c:150:F:general:tf:0: GST_BUFFER_IN_CAPS flag should have been copied ! which is probably a compiler bug. ------------------------------------ On ia64 libs/cddabasesrc.c failed: Running suite(s): cddabasesrc 0%: Checks: 2, Failures: 0, Errors: 2 libs/cddabasesrc.c:290:E:general:tf:0: (after this point) Received signal 7 (Bus error) libs/cddabasesrc.c:323:E:general:tf:0: (after this point) Received signal 7 (Bus error) FAIL: libs/cddabasesrc ------------------------------------ On hppa libs/fft failed: Running suite(s): fft library 76%: Checks: 13, Failures: 0, Errors: 3 libs/fft.c:410:E:general:tf:0: (after this point) Received signal 10 (Bus error) libs/fft.c:448:E:general:tf:0: (after this point) Received signal 10 (Bus error) libs/fft.c:490:E:general:tf:0: (after this point) Received signal 10 (Bus error) FAIL: libs/fft At least the theora failure seems to be a general problem. The other's could be caused by the hardware, compiler, etc too. Needs further investigation.
The failure in libs/fft also happens on sparc, the powerpc/s390 one is handled in bug #348114.
The theoraenc bug is handled in bug #497964. So this leaves the sparc/hppa failures on libs/fft and the ia64 failure on libs/cddabasesrc.
Do you have access to those machines to investigate?
I'd bet those bus errors are loading/storing at an unaligned address. Also, does check have the ability to dump stack when it gets a segfault/bus error?
> I'd bet those bus errors are loading/storing at an unaligned address. > > Also, does check have the ability to dump stack when it gets a segfault/bus > error? Don't know if check does, but there's a half-baked patch in bug #404631 that does that.
Ok, this fixes libs/cddabasesrc on IA64: 2008-02-27 Sebastian Dröge <slomo@circular-chaos.org> * gst-libs/gst/cdda/sha1.c: (sha_transform): Use memcpy() instead of upcasting a byte array to long *. This fixes an unaligned memory access, resulting in SIGBUS on IA64. This should be ported to GCheckSum once we can use GLib 2.16. Partially fixes bug #500833.
Ok, for the fft SIGBUS things are more difficult: First SIGBUS is in 0xf7fb3a70 in kiss_fft_f64_alloc (nfft=1024, inverse_fft=0, mem=0x45af4, lenmem=0xffa6d3ac) at kiss_fft_f64.c:363 363 for (i = 0; i < nfft; ++i) { Moving the definition of "pi" to the top of the function body fixes this. Next problem is: 0xf7f80500 in kf_work (Fout=0x49bfc, f=0x3dac8, fstride=256, in_stride=1, factors=0x45b24, st=0x45af4) at kiss_fft_f64.c:270 270 *Fout = *f; (gdb) bt
+ Trace 190610
The problem here seems to be the following: timedata is given as double * to kiss_fftr_f64(), casted to pointer to a struct { double a; double b; } and used as that in the line where it explodes. I wonder why, the doubles in the array are all properly aligned and both members of the struct should be aligned the same way. Any ideas? :)
> 0xf7f80500 in kf_work (Fout=0x49bfc, f=0x3dac8, fstride=256, in_stride=1, > factors=0x45b24, st=0x45af4) at kiss_fft_f64.c:270 > 270 *Fout = *f; > (gdb) bt > #0 0xf7f80500 in kf_work (Fout=0x49bfc, f=0x3dac8, fstride=256, in_stride=1, > factors=0x45b24, st=0x45af4) at kiss_fft_f64.c:270 > #1 0xf7f80580 in kf_work (Fout=0x49bfc, f=0x3dac8, fstride=64, in_stride=1, > factors=0x45b1c, st=0x45af4) at kiss_fft_f64.c:275 > ... > > I wonder why, the doubles in the array are all properly aligned and both > members of the struct should be aligned the same way. Any ideas? :) Isn't Fout supposed to be properly aligned (to multiples of 8?) too?
Yes, it is... thanks for spotting :) Now let's find the cause...
Aligning it to 8, 16 or even 32 bytes doesn't make a difference... unfortunately I currently can't get a new backtrace because gdb on that machine simply hangs when starting the test case :/
*** Bug 548193 has been marked as a duplicate of this bug. ***
Created attachment 126373 [details] [review] fft-alignment.diff Possible patch for the FFT SIGBUS on sparc... I'll test it later on sparc ;)
Yes, this patch fixes the SIGBUS on sparc :)
2009-01-16 Sebastian Dröge <sebastian.droege@collabora.co.uk> * gst-libs/gst/fft/_kiss_fft_guts_f32.h: * gst-libs/gst/fft/_kiss_fft_guts_f64.h: * gst-libs/gst/fft/_kiss_fft_guts_s16.h: * gst-libs/gst/fft/_kiss_fft_guts_s32.h: * gst-libs/gst/fft/kiss_fftr_f32.c: (kiss_fftr_f32_alloc): * gst-libs/gst/fft/kiss_fftr_f64.c: (kiss_fftr_f64_alloc): * gst-libs/gst/fft/kiss_fftr_s16.c: (kiss_fftr_s16_alloc): * gst-libs/gst/fft/kiss_fftr_s32.c: (kiss_fftr_s32_alloc): Use correct struct alignment everywhere to prevent unaligned memory accesses, resulting in SIGBUS on sparc and probably others. Fixes bug #500833.