Bug#368991: Processed: Re: Bug#368991: banshee: crash when click play
On Mon, Jun 19, 2006 at 06:28:40PM +0200, Loïc Minier wrote:
From the gcc man page, -mpreferred-stack-boundary flag:
To ensure proper alignment of this values on the stack, the stack
boundary must be as aligned as that required by any value stored on
the stack.
[...]
None of liboil, banshee, or even mono seem to be built with
-mpreferred-stack-boundary, yet I can imagine some of this software has
misaligned the stack. Is there a way to find out which and add stack
alignment code before external function calls?
After some discussion with Loïc on IRC, I've implemented something
like this, it works for us both. So I'm pretty sure it works fine on
i386.
Where I'm sure it doesn't work is amd64, since I don't have access
to an amd64 machine. Michael Ablassmeier reported it works there
though.
The idea is to add a little wrapper function around the sse
functions to make sure the stack is aligned before they are called.
Would be nice if gcc could do this, without its support some asm
magic does work though.
I've attached the patch. It would be nice if someone who knows amd64
assembly could review this, and add proper amd64 support via ifdefs
if needed.
Cheers,
Christian Aichinger
--- liboil-0.3.9.orig/liboil/sse/composite_sse_2pix.c 2005-12-21
02:27:54.0 +0100
+++ liboil-0.3.9/liboil/sse/composite_sse_2pix.c2006-06-20
16:12:12.0 +0200
@@ -32,6 +32,29 @@
#include emmintrin.h
#include liboil/liboilcolorspace.h
+/* Work around non-aligned stack frames (which causes the intristics to crash
+ * by making sure the stack frame is always aligned
+ */
+#define OIL_SSE_WRAPPER(name,ret, ...) \
+ret name(__VA_ARGS__) __attribute__((used));\
+ret name ## _wrap (__VA_ARGS__) { \
+OIL_SSE_WRAPPER_CALL(name); \
+}
+
+#define OIL_SSE_WRAPPER_CALL(name) \
+asm volatile( \
+\n\t \
+subl $0x10,%%esp\n\t \
+andl $0xfff0,%%esp\n\t\
+\
+movdqu 8(%%ebp),%%xmm0\n\t\
+movdqa %%xmm0,(%%esp)\n\t \
+\
+call #name \n\t\
+movl %%ebp,%%esp\n\t \
+: : \
+: eax,ecx,edx,xmm0)
+
/* non-SSE2 compositing support */
#define COMPOSITE_OVER(d,s,m) ((d) + (s) - oil_muldiv_255((d),(m)))
#define COMPOSITE_ADD(d,s) oil_clamp_255((d) + (s))
@@ -41,20 +64,12 @@
* the channel value in the low byte. This means 2 pixels per pass.
*/
-union m128_int {
- __m128i m128;
- uint64_t ull[2];
-};
-
-static const struct _SSEData {
- union m128_int sse_8x00ff;
- union m128_int sse_8x0080;
-} c = {
-.sse_8x00ff.ull = {0x00ff00ff00ff00ffULL, 0x00ff00ff00ff00ffULL},
-.sse_8x0080.ull = {0x0080008000800080ULL, 0x0080008000800080ULL},
-};
+static const __m128i c_sse_8x00ff =
+{0x00ff00ff00ff00ffULL, 0x00ff00ff00ff00ffULL};
+static const __m128i c_sse_8x0080 =
+{0x0080008000800080ULL, 0x0080008000800080ULL};
-#define MC(x) (c.sse_##x.m128)
+#define MC(x) (c_sse_##x)
/* Shuffles the given value such that the alpha for each pixel appears in each
* channel of the pixel.
@@ -188,7 +203,11 @@
COMPOSITE_IN(oil_argb_B(*src), m));
}
}
-OIL_DEFINE_IMPL_FULL (composite_in_argb_const_src_sse_2pix,
+
+OIL_SSE_WRAPPER(composite_in_argb_const_src_sse_2pix, static void,
+uint32_t *dest, const uint32_t *src, const uint8_t *mask, int n)
+
+OIL_DEFINE_IMPL_FULL (composite_in_argb_const_src_sse_2pix_wrap,
composite_in_argb_const_src, OIL_IMPL_FLAG_SSE2);
static void
@@ -216,7 +235,10 @@
COMPOSITE_IN(oil_argb_B(s), mask[0]));
}
}
-OIL_DEFINE_IMPL_FULL (composite_in_argb_const_mask_sse_2pix,
+OIL_SSE_WRAPPER(composite_in_argb_const_mask_sse_2pix, static void,
+uint32_t *dest, const uint32_t *src, const uint8_t *mask, int n)
+
+OIL_DEFINE_IMPL_FULL (composite_in_argb_const_mask_sse_2pix_wrap,
composite_in_argb_const_mask, OIL_IMPL_FLAG_SSE2);
static void
@@ -272,7 +294,11 @@
*dest++ = d;
}
}
-OIL_DEFINE_IMPL_FULL (composite_over_argb_const_src_sse_2pix,
+
+OIL_SSE_WRAPPER(composite_over_argb_const_src_sse_2pix, static void,
+uint32_t *dest, const uint32_t *src, int n)
+
+OIL_DEFINE_IMPL_FULL (composite_over_argb_const_src_sse_2pix_wrap,
composite_over_argb_const_src, OIL_IMPL_FLAG_SSE2);
static void
@@
Bug#368991: Processed: Re: Bug#368991: banshee: crash when click play
Hi Christian, On Thu, Jun 08, 2006, Christian Aichinger wrote: | $ gcc -I/usr/include/liboil-0.3 -Wall -ggdb a.c -c -o a.o -mpreferred-stack-boundary=2 From the gcc man page, -mpreferred-stack-boundary flag: [] To ensure proper alignment of this values on the stack, the stack boundary must be as aligned as that required by any value stored on the stack. Further, every function must be generated such that it keeps the stack aligned. Thus calling a function compiled with a higher preferred stack boundary from a function compiled with a lower preferred stack boundary will most likely misalign the stack. It is recommended that libraries that use callbacks always use the default setting. None of liboil, banshee, or even mono seem to be built with -mpreferred-stack-boundary, yet I can imagine some of this software has misaligned the stack. Is there a way to find out which and add stack alignment code before external function calls? Bye, -- Loïc Minier [EMAIL PROTECTED]
Bug#368991: Processed: Re: Bug#368991: banshee: crash when click play
On Thu, Jun 08, 2006 at 02:06:01PM -0700, David Schleef wrote: GCC is really dumb in this area, since it often assumes things about stack alignment that just aren't true. GCC doesn't even always follow the rules it assumes. In general, liboil has been able to avoid these situations on other architectures, so I'll just fix the code here. Is there any progress on this? This bug is currently (indirectly) what's holding up removal of xorg-x11 from unstable, so I guess fixing it soonish would be a good idea, if at all possible. :-) /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#368991: Processed: Re: Bug#368991: banshee: crash when click play
On Thu, Jun 08, 2006 at 07:24:16AM +0200, Christian Aichinger wrote: Normally this is not problematic, since gcc aligns the stack boundary to 16 bytes by default. However this doesn't seem to hold for mono/banshee, or if one manually changes that alignment. This makes sense. Thanks for figuring this out. GCC is really dumb in this area, since it often assumes things about stack alignment that just aren't true. GCC doesn't even always follow the rules it assumes. In general, liboil has been able to avoid these situations on other architectures, so I'll just fix the code here. Thankfully, this should be easy to put into a testsuite. dave... -- David Schleef Big Kitten LLC (http://www.bigkitten.com/) -- data acquisition on Linux -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#368991: Processed: Re: Bug#368991: banshee: crash when click play
On Wed, Jun 07, 2006 at 05:22:38PM +0200, Sebastian Dröge wrote: Hi, attached is the output of oil-bugreport on an affected machine (Pentium IV) and a backtrace of banshee after the segfault. I hope this helps. The same also happens to muine when compiled with gst0.10 support btw Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1212806848 (LWP 5271)] 0xb1bf6f87 in add_f32_sse_unroll2 (dest=0x890bd30, src1=0x890c0c8, src2=0x890c460, n=100) at math_sse_unroll2.c:44 44 xmm0 = _mm_loadu_ps(src1); (gdb) bt #0 0xb1bf6f87 in add_f32_sse_unroll2 (dest=0x890bd30, src1=0x890c0c8, src2=0x890c460, n=100) at math_sse_unroll2.c:44 I assume you got this backtrace with a liboil compiled with -O0. If that's the case, this is _not_ the place where it crashes with -O2. I wasted several hours at this point myself, sadly :-/ If you care you can try it with an unmodified liboil, at the crash `bt` won't really work, but you can do `x/20i $pc`, that'll show the code I posted in my report (starting at the === SEGV marker). You should be able to get the same trace as I via `x/20i ($pc-0x2b)`. Cheers, Christian Aichinger signature.asc Description: Digital signature
Bug#368991: Processed: Re: Bug#368991: banshee: crash when click play
I can reproduce this bug outside of banshee and mono *wheee*. Also,
I think I understand the problem too now, and what really causes it.
First of all, the repro steps:
| $ cat a.c
| #include stdio.h
| #include liboil/liboil.h
|
| int main() {
| printf(oil_init...\n);
| oil_init();
| printf(Done...\n);
| return 0;
| }
|
| $ gcc -I/usr/include/liboil-0.3 -Wall -ggdb a.c -c -o a.o
-mpreferred-stack-boundary=2
| $ gcc a.o /usr/lib/liboil-0.3.so
| $ ./a.out
| oil_init...
| zsh: segmentation fault ./a.out
The segfault is caused by the optimize_all call inside of oil_init,
when it tries all possible implementations.
The crash happens here:
| 0xb453c013 composite_in_argb_sse_2pix+35: movdqa 0x704c(%ebx),%xmm0
| 0xb453c01b composite_in_argb_sse_2pix+43: movdqa %xmm0,0xffc8(%ebp)
=== SEGV
This corresponds to the following code in composite_sse_2pix.c:
| static inline __m128i
| muldiv_255_sse2(__m128i a, __m128i b)
| {
| __m128i ret;
| __m128i roundconst = MC(8x0080);
|
| ret = _mm_mullo_epi16(a, b);
| ret = _mm_adds_epu16(ret, roundconst);
The problem is that gcc somehow has believes that it has to copy
that MC(8x0080) thing to the stack. Gcc tries to copy the constant
using movqda, which requires that memory operands are 16-byte
aligned. If it's not, the CPU raises a #GP exception, which the
kernel translates to a SEGV [1].
Normally this is not problematic, since gcc aligns the stack
boundary to 16 bytes by default. However this doesn't seem to hold
for mono/banshee, or if one manually changes that alignment.
Gcc can be convinced to optimize roundconst away and directly use
the MC(8x0080) constant, so that particular segfault goes away
(patches attached). There are however several other segfaults in
other places.
A fix can be found for some of them, but the problem is that you'd
have to prevent the use of any __m128 constants on the stack. This
means no local variables, no implicit copies by gcc, ...
That's quite a major PITA, if it's even possible at all.
The other possibility is to tell gcc that it's got to 16-byte align
those variables, no matter what. There's an alignment attribute for
that, which can be either applied to variables[2] or to types[3].
However when I tried it out, it didn't work, gcc(-4.0) always
generated the same faulty code that relied on the frame starting at
a multiple of 16.
To conclude, manually fixing up all this stuff seems impossible, and
getting gcc to solve it didn't work for me either.
So unless you have any better ideas we could ask the gcc folks if
they know a solution for this.
HTH,
Christian Aichinger
[1] http://enrico.phys.cmu.edu/QCDcluster/intel/vtune/reference/vc183.htm
[2] http://gcc.gnu.org/onlinedocs/gcc-3.3.1/gcc/Variable-Attributes.html
[3] http://gcc.gnu.org/onlinedocs/gcc-3.3.1/gcc/Type-Attributes.html
--- liboil-0.3.9.orig/liboil/sse/composite_sse_2pix.c 2006-06-08
04:41:50.0 +0200
+++ liboil-0.3.9/liboil/sse/composite_sse_2pix.c2006-06-08
04:43:28.0 +0200
@@ -41,20 +41,10 @@
* the channel value in the low byte. This means 2 pixels per pass.
*/
-union m128_int {
- __m128i m128;
- uint64_t ull[2];
-};
-
-static const struct _SSEData {
- union m128_int sse_8x00ff;
- union m128_int sse_8x0080;
-} c = {
-.sse_8x00ff.ull = {0x00ff00ff00ff00ffULL, 0x00ff00ff00ff00ffULL},
-.sse_8x0080.ull = {0x0080008000800080ULL, 0x0080008000800080ULL},
-};
+static const __m128i c_sse_8x00ff = {0x00ff00ff00ff00ffULL,
0x00ff00ff00ff00ffULL};
+static const __m128i c_sse_8x0080 = {0x0080008000800080ULL,
0x0080008000800080ULL};
-#define MC(x) (c.sse_##x.m128)
+#define MC(x) (c_sse_##x)
/* Shuffles the given value such that the alpha for each pixel appears in each
* channel of the pixel.
--- liboil-0.3.9.orig/liboil/sse/composite_sse_4pix.c 2006-06-08
04:41:50.0 +0200
+++ liboil-0.3.9/liboil/sse/composite_sse_4pix.c2006-06-08
05:15:38.0 +0200
@@ -32,20 +32,10 @@
#include emmintrin.h
#include liboil/liboilcolorspace.h
-union m128_int {
- __m128i m128;
- uint64_t ull[2];
-};
-
-static const struct _SSEData {
- union m128_int sse_16xff;
- union m128_int sse_8x0080;
-} c = {
-.sse_16xff.ull = {0xULL, 0xULL},
-.sse_8x0080.ull = {0x0080008000800080ULL, 0x0080008000800080ULL},
-};
+static const __m128i c_sse_16xff = {0xULL,
0xULL};
+static const __m128i c_sse_8x0080 = {0x0080008000800080ULL,
0x0080008000800080ULL};
-#define MC(x) (c.sse_##x.m128)
+#define MC(x) (c_sse_##x)
/* non-SSE2 compositing support */
#define COMPOSITE_OVER(d,s,m) ((d) + (s) - oil_muldiv_255((d),(m)))
signature.asc
Description: Digital signature
Bug#368991: Processed: Re: Bug#368991: banshee: crash when click play
Hi, attached is the output of oil-bugreport on an affected machine (Pentium IV) and a backtrace of banshee after the segfault. I hope this helps. The same also happens to muine when compiled with gst0.10 support btw Bye Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1212806848 (LWP 5271)] 0xb1bf6f87 in add_f32_sse_unroll2 (dest=0x890bd30, src1=0x890c0c8, src2=0x890c460, n=100) at math_sse_unroll2.c:44 44 xmm0 = _mm_loadu_ps(src1); (gdb) bt #0 0xb1bf6f87 in add_f32_sse_unroll2 (dest=0x890bd30, src1=0x890c0c8, src2=0x890c460, n=100) at math_sse_unroll2.c:44 #1 0xb1bdcc0c in _oil_test_marshal_function (func=0xb1bf6f34, args=0xbf8654d4, n_args=4, pointer_mask=30, prof=0x890b7ec) at liboilmarshal.c:51 #2 0xb1bdf5bb in oil_test_check_function (priv=0x890b000) at liboiltest.c:270 #3 0xb1bdb7ec in oil_cpu_fault_check_try (func=0xb1bdf2c8 oil_test_check_function, priv=0x890b000) at liboilcpu.c:201 #4 0xb1bdf83a in oil_test_check_impl (test=0x890b000, impl=0xb1c2dcc0) at liboiltest.c:357 #5 0xb1bdc45f in oil_class_optimize (klass=0xb1c30cc0) at liboilfunction.c:360 #6 0xb1bdc058 in oil_optimize_all () at liboilfunction.c:181 #7 0xb1bdbf93 in oil_init () at liboilfunction.c:140 #8 0xb1c7c175 in resample_init () at resample.c:46 #9 0xb1c7ba31 in plugin_init (plugin=0x890c0c8) at gstaudioresample.c:682 #10 0xb53b8ca1 in gst_plugin_register_func (plugin=0x8282138, module=value optimized out, desc=0xb1c80360) at gstplugin.c:259 #11 0xb53b93cc in gst_plugin_load_file (filename=0x8286838 /usr/lib/gstreamer-0.10/libgstaudioresample.so, error=0xbf865844) at gstplugin.c:446 #12 0xb53b9a44 in gst_plugin_load_by_name (name=0x8286af0 audioresample) at gstplugin.c:870 #13 0xb53b9ef0 in gst_plugin_feature_load (feature=0x8282890) at gstpluginfeature.c:113 #14 0xb53a0c83 in gst_element_factory_create (factory=0x8282890, name=0xb517c00f aresample) at gstelementfactory.c:352 #15 0xb53a0fe4 in gst_element_factory_make (factoryname=0xb517c019 audioresample, name=0xb517c00f aresample) at gstelementfactory.c:434 #16 0xb5171dcb in gen_audio_element (play_bin=0x82b8048) at gstplaybin.c:768 #17 0xb5172ee9 in setup_sinks (play_base_bin=0x82b8048, group=0x8902590) at gstplaybin.c:1176 #18 0xb5176576 in group_commit (play_base_bin=0x82b8048, fatal=value optimized out, subtitle=0) at gstplaybasebin.c:439 #19 0xb6fd7423 in IA__g_cclosure_marshal_VOID__VOID (closure=0x88da128, return_value=0x0, n_param_values=1, param_values=0xbf865d68, invocation_hint=0xbf865c58, marshal_data=0xb5176abc) at gmarshal.c:77 #20 0xb6fcb79f in IA__g_closure_invoke (closure=0x88da128, return_value=0x890c0c8, n_param_values=143704264, param_values=0x890c0c8, invocation_hint=0x890c0c8) at gclosure.c:490 #21 0xb6fda2ea in signal_emit_unlocked_R (node=0x820d630, detail=0, instance=0x88dd020, emission_return=0x0, instance_and_params=0xbf865d68) at gsignal.c:2438 #22 0xb6fdbb19 in IA__g_signal_emit_valist (instance=0x88dd020, signal_id=34, detail=0, var_args=value optimized out) at gsignal.c:2197 #23 0xb6fdbe89 in IA__g_signal_emit (instance=0x890c0c8, signal_id=143704264, detail=143704264) at gsignal.c:2241 #24 0xb539c0ee in gst_element_no_more_pads (element=0x88dd020) at gstelement.c:769 #25 0xb1ce1e40 in no_more_pads (element=0x890c0c8, dynamic=0x88f1500) at gstdecodebin.c:1155 #26 0xb6fd7423 in IA__g_cclosure_marshal_VOID__VOID (closure=0x88f1640, return_value=0x0, n_param_values=1, param_values=0xbf866278, invocation_hint=0xbf866168, marshal_data=0xb1ce1cff) at gmarshal.c:77 #27 0xb6fcb79f in IA__g_closure_invoke (closure=0x88f1640, return_value=0x890c0c8, n_param_values=143704264, param_values=0x890c0c8, invocation_hint=0x890c0c8) at gclosure.c:490 #28 0xb6fda2ea in signal_emit_unlocked_R (node=0x820d630, detail=0, instance=0x82c80b8, emission_return=0x0, instance_and_params=0xbf866278) at gsignal.c:2438 #29 0xb6fdbb19 in IA__g_signal_emit_valist (instance=0x82c80b8, signal_id=34, detail=0, var_args=value optimized out) at gsignal.c:2197 #30 0xb6fdbe89 in IA__g_signal_emit (instance=0x890c0c8, signal_id=143704264, detail=143704264) at gsignal.c:2241 #31 0xb539c0ee in gst_element_no_more_pads (element=0x82c80b8) at gstelement.c:769 #32 0xb1cca07c in gst_id3demux_add_srcpad (id3demux=0x82c80b8, new_caps=value optimized out) at gstid3demux.c:286 #33 0xb1ccb888 in gst_id3demux_sink_activate (sinkpad=0x88dc038) at gstid3demux.c:900 #34 0xb53b0ad3 in gst_pad_set_active (pad=0x88dc038, active=1) at gstpad.c:638 #35 0xb539f343 in activate_pads (pad=0x88dc038, ret=0x890c0c8, active=0xbf866684) at gstelement.c:2254 #36 0xb53a9db4 in gst_iterator_fold (it=0x88f1780, func=0xb539f31b activate_pads, ret=0xbf866694, user_data=0xbf866684) at gstiterator.c:503 #37 0xb539f3e4 in iterator_fold_with_resync (iter=0x88f1780, func=0xb539f31b activate_pads, ret=0xbf866694, user_data=0xbf866684) at gstelement.c:2272 #38 0xb539f57b in gst_element_pads_activate (element=0x82c80b8, active=1) at
Bug#368991: Processed: Re: Bug#368991: banshee: crash when click play
On Fri, May 26, 2006 at 10:33:29AM -0700, Debian Bug Tracking System wrote: Processing commands for [EMAIL PROTECTED]: reassign 368991 liboil Bug#368991: banshee: crash when click play Bug reassigned from package `banshee' to `liboil'. Why is this a liboil bug? dave... -- David Schleef Big Kitten LLC (http://www.bigkitten.com/) -- data acquisition on Linux -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
