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

[Bernhard Übelacker]

Hello Fabian,
after some more searching and testing here is my "opinion" on this issue:


- OCaml versions 4.01 (used in Jessie) and before are not doing stack
  alignment on 16 byte boundaries [1].

- GCC does 16 byte stack alignment (at least when using SSE instructions)
  at compile time.

- Now when calling libmp3lame0 from lame executable (gcc) this works just fine.
  But calling from liquidsoap (ocaml) we end up calling libmp3lame0 with a unaligned
  stack therefore getting the SIGSEGV on the "movaps %xmm0,0x20(%esp)".
  (See the second stack and the address of vec_xrpow_max in [2].)


But until now I could not fully proove my theory because:
- OCaml version 4.02 is just in experimental. Using this version would need to
  compile also all the packages depending on ocaml.
- Just using this patch in [1] is also not binary compatible with the packages
  depending on ocaml, therefore needing them all to recompile too.

For this reason chances for such a change to OCaml to enter Jessie are low?


One thing did avoid the crash, that was adding "__attribute__((aligned(0x20)))"
to the vecfloat_union used inside libmp3lame0 [3].
Requesting an alignment of 0x10 seems without effect.
(Probably because GCC does this already and is therefore removed.)


Options we have, if above could be proven right:
- change libmp3lame0 [3] (at least for stable), even when it is not guilty
- test rebuilding OCaml and all dependents with the patch in [1]
- wait if problem vanishes when OCaml 4.02 enters unstable/testing.
- get someone from debian-ocaml-maint involved.


[1] http://caml.inria.fr/mantis/view.php?id=6038#c11630
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786438#22
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786438#87


Kind regards,
Bernhard