Bug#786438: libmp3lame0: general protection error in libmp3lame.so.0.0.0

[Bernhard Übelacker]

Hello Fabian,

Am 02.06.2015 um 12:11 schrieb Fabian Greffrath:
> but that shouldn't make a difference, because the code already worked
> correctly when you forced it to 16-bit boundaries by using
> posix_memalign().

I just wanted to have a less invasive change.


> What happens if you re-arrange the definition of the vecfloat_union so
> that _m128 is its first member, i.e.
> 
> typedef union {
>      __m128  _m128;
>      int32_t _i_32[4]; /* unions are initialized by its first member */
>      float   _float[4];
> } vecfloat_union;
> 
> This is how these unions are used in most examples that I found. 

With _m128 being the first line the crash still happens with
or without the attribute.


> Also, do you have any idea what this comment in there wants to tell us?

I guess this is a hint for this initialization:
-    const vecfloat_union fabs_mask = {{ 0x7FFFFFFF, 0x7FFFFFFF, 0x7FFFFFFF, 0x7FFFFFFF }};

This could be probably more explicit (but less portable)
by doing something like this:
+    const vecfloat_union fabs_mask = { ._i_32 = { 0x7FFFFFFF, 0x7FFFFFFF, 0x7FFFFFFF, 0x7FFFFFFF } };

With this, reordering the members of the union does not affect audio output.


> You could even drop the _i_32[] member, it is not used in the code.
> Maybe the compiler recognized that and somehow optimized that out,
> messing the alignment thereby?

Removing _i_32 seems to initialize the union differently and therefore
the result is different.
With _i_32 removed (and the alignment 0x20) audio is not working anymore.


Kind regards,
Bernhard