Hi Bernhard et al., Am Samstag, den 06.06.2015, 14:59 +0200 schrieb Bernhard Übelacker: > Hello Fabian, > after some more searching and testing here is my "opinion" on this issue:
thank you for your analysis of the issue. However, I think I have come up with a simpler fix meanwhile: By declaring the affected variables as "static" I make sure they are allocated at build time (well, sort of) with proper alignment instead of at run-time within an unknown FPU mode. Could you please confirm that the attached patch fixes the issue? Thank you so much! - Fabian > > > - 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 >
--- a/libmp3lame/vector/xmm_quantize_sub.c +++ b/libmp3lame/vector/xmm_quantize_sub.c @@ -61,11 +61,13 @@ init_xrpow_core_sse(gr_info * const cod_ int upper4 = (upper / 4) * 4; int rest = upper-upper4; - const vecfloat_union fabs_mask = {{ 0x7FFFFFFF, 0x7FFFFFFF, 0x7FFFFFFF, 0x7FFFFFFF }}; - const __m128 vec_fabs_mask = _mm_loadu_ps(&fabs_mask._float[0]); - vecfloat_union vec_xrpow_max; - vecfloat_union vec_sum; - vecfloat_union vec_tmp; + static const vecfloat_union fabs_mask = {{ 0x7FFFFFFF, 0x7FFFFFFF, 0x7FFFFFFF, 0x7FFFFFFF }}; + static __m128 vec_fabs_mask; + static vecfloat_union vec_xrpow_max; + static vecfloat_union vec_sum; + static vecfloat_union vec_tmp; + + vec_fabs_mask = _mm_loadu_ps(&fabs_mask._float[0]); _mm_prefetch((char *) cod_info->xr, _MM_HINT_T0); _mm_prefetch((char *) xrpow, _MM_HINT_T0);
signature.asc
Description: This is a digitally signed message part