Bug#786438: libmp3lame0: general protection error in libmp3lame.so.0.0.0
Am Dienstag, den 09.06.2015, 15:20 +0200 schrieb Fabian Greffrath: With upstream patch application in mind, I'd rather modify Makefile.am. In the per-function variant the attribute intruction would have to be #ifdef'd out of the way for non-GCC compilers, whereas automake is already rather GCC-centric anyway. I have decided to go the per-function way and add __GNUC__ protectors. I will upload a fixed package shortly. Thank you very much for your help with analyzing this bug and your patient suggestions and patches! - Fabian signature.asc Description: This is a digitally signed message part
Bug#786438: libmp3lame0: general protection error in libmp3lame.so.0.0.0
Hello Fabian, can confirm that both variants are fixing the issue. I would prefer the function level fix, but as there is already a change to the build system that does exclusively apply to this file, I think both are equally good. (And when OCaml 4.02 enters Stretch we can try removing it again.) Kind regards, Bernhard -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#786438: libmp3lame0: general protection error in libmp3lame.so.0.0.0
Hi Bernhard, Am Dienstag, den 09.06.2015, 13:52 +0200 schrieb Bernhard Übelacker: can confirm that both variants are fixing the issue. Thank you! I would prefer the function level fix, but as there is already a change to the build system that does exclusively apply to this file, I think both are equally good. With upstream patch application in mind, I'd rather modify Makefile.am. In the per-function variant the attribute intruction would have to be #ifdef'd out of the way for non-GCC compilers, whereas automake is already rather GCC-centric anyway. (And when OCaml 4.02 enters Stretch we can try removing it again.) Yes, but I'd like to fix this in Jessie, and it is a lot more convincing for the Stable Release Managers if the patch has gone the route through unstable-testing before. Cheers, Fabian signature.asc Description: This is a digitally signed message part
Bug#786438: libmp3lame0: general protection error in libmp3lame.so.0.0.0
Control: tags -1 patch
Hi all,
Am Montag, den 08.06.2015, 11:45 +0200 schrieb Fabian Greffrath:
So, in absence of a better approach, [...]
I think I have found another, maybe even the final, fix for this issue.
Remember that the operands in SSE functions must be aligned on 16-byte
boundaries. In the init_xrpow_core_sse() function these operands are on
the stack. However, when the code is called from the ocaml bindings,
the stack is allocated by ocaml which does not adhere to the 16-byte
boundary rule and thus casues the code to crash. So what we really need
here is a means for the init_xrpow_core_sse() function to maintain its
own stack and align it according to its needs. Now, guess what compiler
flag I found yesterday? ;)
-mstackrealign
Realign the stack at entry. On the x86, the -mstackrealign option
generates an alternate prologue and epilogue that realigns the run-time
stack if necessary. This supports mixing legacy codes that keep 4-byte
stack alignment with modern codes that keep 16-byte stack alignment for
SSE compatibility. See also the attribute force_align_arg_pointer,
applicable to individual functions.
This flag applies per-file. If it is added to
liblamevectorroutines_la_CFLAGS (next to the -msse flag) in
libmp3lame/vector/Makefile.am the crash does not occure anymore.
There is also a very similar per-function variant in the form of the
force_align_arg_pointer attribute, but in the case at hand, all
functions in the libmp3lame/vector/xmm_quantize_sub.c file call SSE
-related code and thus I think it is safe to apply this flag file-wide.
I'll be glad to read that this flag fixes the issue for you as well and
read your opinions about the per-function or per-file variants.
Best regards,
Fabian
--- a/libmp3lame/vector/xmm_quantize_sub.c
+++ b/libmp3lame/vector/xmm_quantize_sub.c
@@ -52,6 +52,7 @@ static const FLOAT costab[TRI_SIZE * 2]
+__attribute__((force_align_arg_pointer))
void
init_xrpow_core_sse(gr_info * const cod_info, FLOAT xrpow[576], int upper, FLOAT * sum)
{
--- a/libmp3lame/vector/Makefile.am
+++ b/libmp3lame/vector/Makefile.am
@@ -20,6 +20,7 @@ xmm_sources = xmm_quantize_sub.c
if WITH_XMM
liblamevectorroutines_la_SOURCES = $(xmm_sources)
+liblamevectorroutines_la_CFLAGS = -msse -mstackrealign
endif
noinst_HEADERS = lame_intrin.h
signature.asc
Description: This is a digitally signed message part
Bug#786438: libmp3lame0: general protection error in libmp3lame.so.0.0.0
Am Samstag, den 06.06.2015, 14:59 +0200 schrieb Bernhard Übelacker: - change libmp3lame0 [3] (at least for stable), even when it is not guilty This would be an option. Forcing alignment on an increased boundary so GCC does not fall into thinking that the stack will be 16-bit aligned anyway so it can ignore this attribute. - test rebuilding OCaml and all dependents with the patch in [1] - wait if problem vanishes when OCaml 4.02 enters unstable/testing. These two are unforttunately out of the question for Jessie. - get someone from debian-ocaml-maint involved. Sure, why not. But what could we ask them. We already know (i.e. hope) that the issue has been addressed by OCAML upstream and will vanish as soon as the new release will enter sid. So, in absence of a better approach, I am inclined to upload the fix adding __attribute__((aligned(0x20))) to Jessie. My own approach using static variables is indeed too prone to race conditions. Thanks! - Fabian signature.asc Description: This is a digitally signed message part
Bug#786438: libmp3lame0: general protection error in libmp3lame.so.0.0.0
Hello Fabian, your patch fixes the issue. But I fear by using static we potentially introduce a race condition, if there are any applications encoding in two threads? (May I ask if there are any reasons against __attribute__((aligned(0x20)))?) Kind regards, Bernhard I used following to build with your patch: mkdir libmp3lame0-with-static-var; cd libmp3lame0-with-static-var apt-get source libmp3lame0 wget https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;msg=117;filename=lame-static-vecfloat-msse.patch;bug=786438; -O lame-static-vecfloat-msse.patch cd lame-3.99.5+repack1/ patch -p1 ../lame-static-vecfloat-msse.patch dpkg-buildpackage -b -uc -us cd .. su -c dpkg -i libmp3lame0_3.99.5+repack1-7_i386.deb libmp3lame-dev_3.99.5+repack1-7_i386.deb -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#786438: libmp3lame0: general protection error in libmp3lame.so.0.0.0
Hi Bernhard, Am Sonntag, den 07.06.2015, 14:36 +0200 schrieb Bernhard Übelacker: your patch fixes the issue. \o/ But I fear by using static we potentially introduce a race condition, if there are any applications encoding in two threads? I see, maybe we could add a security net there (e.g. another static variable that is set to 1 at the beginning of the function and to 0 at the end and a while (variable) loop just before that at the beginning). (May I ask if there are any reasons against __attribute__((aligned(0x20)))?) Hm, because (a) it should not even be necessary and (b) it is not portable to non-GCC compilers. The variables are already properly aligned, but not if the FPU is in x387 mode. Cheers, Fabian signature.asc Description: This is a digitally signed message part
Bug#786438: libmp3lame0: general protection error in libmp3lame.so.0.0.0
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 = {{ 0x7FFF, 0x7FFF, 0x7FFF, 0x7FFF }};
-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 = {{ 0x7FFF, 0x7FFF, 0x7FFF, 0x7FFF }};
+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
Bug#786438: libmp3lame0: general protection error in libmp3lame.so.0.0.0
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#786438: libmp3lame0: general protection error in libmp3lame.so.0.0.0
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 = {{ 0x7FFF, 0x7FFF, 0x7FFF,
0x7FFF }};
This could be probably more explicit (but less portable)
by doing something like this:
+const vecfloat_union fabs_mask = { ._i_32 = { 0x7FFF, 0x7FFF,
0x7FFF, 0x7FFF } };
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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#786438: libmp3lame0: general protection error in libmp3lame.so.0.0.0
Hello Fabian,
Am 02.06.2015 um 06:25 schrieb Fabian Greffrath:
Hm, are we missing a specific compiler flag in addition to -msse or are
we probably hunting down a compiler bug here?
Could it be also some linker flag of the .so or liquidsoap? I tried to build
a minimal example but then the crash does not appear anymore.
Nevertheless, as I experimented with bigger align values it stopped crashing.
Following worked inside qemu VM:
--- ./libmp3lame/vector/xmm_quantize_sub.c.orig 2011-05-07 18:05:17.0
+0200
+++ ./libmp3lame/vector/xmm_quantize_sub.c 2015-06-02 11:50:01.76800
+0200
@@ -40,7 +40,7 @@ typedef union {
int32_t _i_32[4]; /* unions are initialized by its first member */
float _float[4];
__m128 _m128;
-} vecfloat_union;
+} __attribute__((aligned(0x20))) vecfloat_union;
#define TRI_SIZE (5-1) /* 1024 = 4**5 */
static const FLOAT costab[TRI_SIZE * 2] = {
Kind regards,
Bernhard
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#786438: libmp3lame0: general protection error in libmp3lame.so.0.0.0
Hi Bernhard,
Am Dienstag, den 02.06.2015, 11:55 +0200 schrieb Bernhard Übelacker:
Nevertheless, as I experimented with bigger align values it stopped crashing.
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().
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. Also,
do you have any idea what this comment in there wants to tell us?
Thank you!
- Fabian
signature.asc
Description: This is a digitally signed message part
Bug#786438: libmp3lame0: general protection error in libmp3lame.so.0.0.0
Am Dienstag, den 02.06.2015, 12:11 +0200 schrieb Fabian Greffrath:
typedef union {
__m128 _m128;
int32_t _i_32[4]; /* unions are initialized by its first member */
float _float[4];
} vecfloat_union;
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?
- Fabian
signature.asc
Description: This is a digitally signed message part
Bug#786438: libmp3lame0: general protection error in libmp3lame.so.0.0.0
Am Dienstag, den 02.06.2015, 13:46 +0200 schrieb Bernhard Übelacker:
I just wanted to have a less invasive change.
Me too. And there isn't even anything wrong with that code. We just need
to find a way to give the compiler a hint with the clue bat.
I guess this is a hint for this initialization:
-const vecfloat_union fabs_mask = {{ 0x7FFF, 0x7FFF, 0x7FFF,
0x7FFF }};
Isn't 0x7FFF == nan in float? Maybe we could get rid of the int type
and initialize the union through the float members with 0./0.? But maybe
this is just a stupid idea.
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.
Gosh, this is to pull my hair out. ;)
- Fabian
signature.asc
Description: This is a digitally signed message part
Bug#786438: [Fwd: Bug#786438: libmp3lame0: general protection error in libmp3lame.so.0.0.0]
Dear Robert, a bug has been reported against the Debian lame package on arch i386 [1]. The library fails with a SIGSEGV in init_xrpow_core_sse(). As it turns out, this is a general-protection exception triggered by non-aligned memory access. Bernhard Übelacker succeeded to create a patch that forces the variables into alignment by using posix_memslign(), but we are not sure if there may be better suitable solutions to this issue. I am asking you for input on this issue. Could you please have a look at the patch Bernhard provides and share your opinion? NB: This issue has not been raised before, because somehow the ./configure script failed to detect the presence of the xmmintrin.h header in previous package versions and thus decided that it would not want to build the internal vector lib. This has apparently just changed recently. Best regards, Fabian [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786438 ---BeginMessage--- Hello Fabian, hello Detrick, I could reproduce a SIGSEGV on arch i386 inside qemu VM by these actions: (amd64 did not show the fault) - apt-get install icecast2 liquidsoap liquidsoap-plugin-icecast liquidsoap-plugin-lame liquidsoap-plugin-mad liquidsoap-plugin-ogg liquidsoap-plugin-vorbis - enable and start icecast2 (/etc/default/icecast2) - get a mp3 file and put it to current directory as test.mp3 - create test.sh - start liquidsoap in debugger gdb --args /usr/bin/liquidsoap test.sh content of test.sh: #!/usr/bin/liquidsoap set(log.file.path,/dev/stdout) myplaylist = single(test.mp3) output.icecast(%mp3, host = localhost, port = 8000, password = hackme, mount = basic-radio.ogg, myplaylist) (gdb) bt #0 0xb76e30c9 in init_xrpow_core_sse () from /usr/lib/i386-linux-gnu/libmp3lame.so.0 #1 0xb76d2ebf in ?? () from /usr/lib/i386-linux-gnu/libmp3lame.so.0 #2 0xb76d65e6 in CBR_iteration_loop () from /usr/lib/i386-linux-gnu/libmp3lame.so.0 #3 0xb76c3e27 in lame_encode_mp3_frame () from /usr/lib/i386-linux-gnu/libmp3lame.so.0 #4 0xb76c8e4f in ?? () from /usr/lib/i386-linux-gnu/libmp3lame.so.0 #5 0xb76c9b48 in lame_encode_buffer_float () from /usr/lib/i386-linux-gnu/libmp3lame.so.0 #6 0xb781cf77 in ocaml_lame_encode_buffer_float () from /usr/lib/liquidsoap/1.1.1/plugins/lame.cmxs #7 0xb781b72f in camlLame__fun_1175 () from /usr/lib/liquidsoap/1.1.1/plugins/lame.cmxs #8 0x0820b06f in camlOutput__f_1354 () #9 0x0820b0c5 in camlOutput__fun_1740 () #10 0x0820b7dd in camlOutput__fun_1600 () #11 0x08257c6f in camlClock__fun_1848 () #12 0x08310b3c in camlList__fold_left_1073 () #13 0x08258740 in camlClock__fun_1813 () #14 0x082582a5 in camlClock__loop_1351 () #15 0x08258daa in camlClock__fun_2074 () #16 0x082703e3 in camlTutils__fun_1346 () #17 0x08307ac8 in camlThread__fun_1081 () #18 0x083612fa in caml_start_program () #19 0x0834a675 in ?? () #20 0xb7f1befb in start_thread (arg=0x79e8b781) at pthread_create.c:309 #21 0xcde0b850 in ?? () #22 0x79e8b781 in ?? () #23 0x8350b45b in ?? () #24 0x8dc314c4 in ?? () #25 0x00b6 in ?? () #26 0x27bc8d00 in ?? () #27 0x in ?? () Building libmp3lame0 with debug information: - export DEB_BUILD_OPTIONS=nostrip - apt-get build-dep libmp3lame0 - apt-get source libmp3lame0 - dpkg-buildpackage -b - dpkg -i libmp3lame0_*.deb - gdb --args /usr/bin/liquidsoap test.sh Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb49ffb40 (LWP 20251)] init_xrpow_core_sse (cod_info=0x8731a00, xrpow=0xb49fa6f4, upper=575, sum=0xb49fa5d0) at xmm_quantize_sub.c:73 73 vec_xrpow_max._m128 = _mm_set_ps1(0); (gdb) bt #0 init_xrpow_core_sse (cod_info=0x8731a00, xrpow=0xb49fa6f4, upper=575, sum=0xb49fa5d0) at xmm_quantize_sub.c:73 #1 0xb76cf71f in init_xrpow (gfc=0x87318d0, cod_info=0x8731a00, xrpow=0xb49fa6f4) at quantize.c:127 #2 0xb76d2cc6 in CBR_iteration_loop (gfc=0x87318d0, pe=0xb49fb0c4, ms_ener_ratio=0xb49fb09c, ratio=0xb49fd06c) at quantize.c:2034 #3 0xb76c0c37 in lame_encode_mp3_frame (gfc=gfc@entry=0x87318d0, inbuf_l=0x873e48c, inbuf_r=0x87422cc, mp3buf=mp3buf@entry=0xb4a081b9 , mp3buf_size=mp3buf_size@entry=8988) at encoder.c:518 #4 0xb76c5a22 in lame_encode_buffer_sample_t (mp3buf_size=9405, mp3buf=0xb4a081b9 , nsamples=optimized out, gfc=optimized out) at lame.c:1786 #5 lame_encode_buffer_template (gfp=gfp@entry=0x865f580, buffer_l=buffer_l@entry=0xb4a048e8, buffer_r=buffer_r@entry=0xb4a06480, nsamples=nsamples@entry=1764, mp3buf=mp3buf@entry=0xb4a08018 \377\373\220D, mp3buf_size=mp3buf_size@entry=9405, pcm_type=pcm_type@entry=pcm_float_type, aa=aa@entry=1, norm=norm@entry=1) at lame.c:1897 #6 0xb76c6648 in lame_encode_buffer_float (gfp=0x865f580, pcm_l=0xb4a048e8, pcm_r=0xb4a06480, nsamples=1764, mp3buf=0xb4a08018 \377\373\220D, mp3buf_size=9405) at lame.c:1918 #7 0xb7819f77 in ocaml_lame_encode_buffer_float () from /usr/lib/liquidsoap/1.1.1/plugins/lame.cmxs #8 0xb781872f in camlLame__fun_1175 () from /usr/lib/liquidsoap/1.1.1/plugins/lame.cmxs #9 0x0820b07f in
Bug#786438: libmp3lame0: general protection error in libmp3lame.so.0.0.0
Hi Bernhard, Am Freitag, den 29.05.2015, 19:02 +0200 schrieb Bernhard Übelacker: Tried to declare the variable with __attribute__ ((aligned (16))) but did not change anything. I just reset my i386 chroot and don't have enough bandwidth from the train to reconstruct it enough to further debug this for today. Could you please try with __attribute__((aligned(16),packed)), too? Thank you! - Fabian signature.asc Description: This is a digitally signed message part
Bug#786438: libmp3lame0: general protection error in libmp3lame.so.0.0.0
Hello Fabian,
did the test inside the i386 VM.
But it did not help either. The packed gets ignored.
(But I am not sure if I use the __attribute__ the right way?)
Kind regards,
Bernhard
---
const vecfloat_union fabs_mask __attribute__((aligned(16),packed)) = {{
0x7FFF, 0x7FFF, 0x7FFF, 0x7FFF }};
const __m128 vec_fabs_mask __attribute__((aligned(16),packed)) =
_mm_loadu_ps(fabs_mask._float[0]);
vecfloat_union vec_xrpow_max __attribute__((aligned(16),packed));
vecfloat_union vec_sum __attribute__((aligned(16),packed));
vecfloat_union vec_tmp __attribute__((aligned(16),packed));
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../.. -I../../include -I.
-I../../libmp3lame -I../../mpglib -I../.. -D_FORTIFY_SOURCE=2 -msse -O3
-fomit-frame-pointer -ffast-math -maccumulate-outgoing-args -fschedule-insns2
-fbranch-count-reg -fforce-addr -march=i586 -mtune=native -Wall -pipe -g -O2
-fstack-protector-strong -Wformat -Werror=format-security -c xmm_quantize_sub.c
-fPIC -DPIC -o .libs/liblamevectorroutines_la-xmm_quantize_sub.o
xmm_quantize_sub.c: In function 'init_xrpow_core_sse':
xmm_quantize_sub.c:64:5: warning: 'packed' attribute ignored [-Wattributes]
const vecfloat_union fabs_mask __attribute__((aligned(16),packed)) =
{{ 0x7FFF, 0x7FFF, 0x7FFF, 0x7FFF }};
^
xmm_quantize_sub.c:65:5: warning: 'packed' attribute ignored [-Wattributes]
const __m128 vec_fabs_mask __attribute__((aligned(16),packed)) =
_mm_loadu_ps(fabs_mask._float[0]);
^
xmm_quantize_sub.c:66:5: warning: 'packed' attribute ignored [-Wattributes]
vecfloat_union vec_xrpow_max __attribute__((aligned(16),packed));
^
xmm_quantize_sub.c:67:5: warning: 'packed' attribute ignored [-Wattributes]
vecfloat_union vec_sum __attribute__((aligned(16),packed));
^
xmm_quantize_sub.c:68:5: warning: 'packed' attribute ignored [-Wattributes]
vecfloat_union vec_tmp __attribute__((aligned(16),packed));
^
xmm_quantize_sub.c: In function 'fht_SSE2':
xmm_quantize_sub.c:172:20: warning: variable 'v_s2' set but not used
[-Wunused-but-set-variable]
__m128 v_s2;
^
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#786438: libmp3lame0: general protection error in libmp3lame.so.0.0.0
Hi again,
Am Montag, den 01.06.2015, 18:32 +0200 schrieb Bernhard Übelacker:
did the test inside the i386 VM.
But it did not help either. The packed gets ignored.
(But I am not sure if I use the __attribute__ the right way?)
I think it should rather go this way:
--- a/libmp3lame/vector/xmm_quantize_sub.c
+++ b/libmp3lame/vector/xmm_quantize_sub.c
@@ -40,7 +40,7 @@ typedef union {
int32_t _i_32[4]; /* unions are initialized by its first member */
float _float[4];
__m128 _m128;
-} vecfloat_union;
+} __attribute__((aligned(16),packed)) vecfloat_union;
Thank you anyway!
- Fabian
signature.asc
Description: This is a digitally signed message part
Bug#786438: libmp3lame0: general protection error in libmp3lame.so.0.0.0
Hello Fabian, unfortunately this did not work too (with or without packed). Kind regards, Bernhard -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#786438: libmp3lame0: general protection error in libmp3lame.so.0.0.0
Am Montag, den 01.06.2015, 20:44 +0200 schrieb Bernhard Übelacker: unfortunately this did not work too (with or without packed). Hm, are we missing a specific compiler flag in addition to -msse or are we probably hunting down a compiler bug here? - Fabian signature.asc Description: This is a digitally signed message part
Bug#786438: libmp3lame0: general protection error in libmp3lame.so.0.0.0
Am Montag, den 01.06.2015, 07:05 +0200 schrieb Fabian Greffrath: The main difference between the packages in wheezy and jessie is that the former is not built with SSE instructions at all. So, it seems that we have not intriduced a bug, but merely uncovered a bug that was well hidden before, because the code path in question was never enabled. This is from the diff of both build logs (wheezy and jessie) during the ./configure phase: @@ -440,9 +566,9 @@ checking sys/time.h presence... yes checking for sys/time.h... yes checking for unistd.h... (cached) yes -checking xmmintrin.h usability... no -checking xmmintrin.h presence... no -checking for xmmintrin.h... no +checking xmmintrin.h usability... yes +checking xmmintrin.h presence... yes +checking for xmmintrin.h... yes checking linux/soundcard.h usability... yes checking linux/soundcard.h presence... yes checking for linux/soundcard.h... yes [...] @@ -516,11 +642,12 @@ checking if dynamic linking of the frontends is requested... yes checking glibc mathinline bug... no checking for termcap... yes -checking if I have to build the internal vector lib... no +checking if I have to build the internal vector lib... yes checking for nasm... /usr/bin/nasm checking for assembler routines for this processor type... yes checking for additional optimizations... full checking for debug options... no +checking that generated files are newer than configure... done configure: creating ./config.status config.status: creating Makefile config.status: creating libmp3lame/Makefile I have no idea why xmmintrin.h was not detected on wheezy, but this is clearly the reason why different code paths have been chosen between wheezy and jessie and why the bug is only encountered in the latter. - Fabian signature.asc Description: This is a digitally signed message part
Bug#786438: libmp3lame0: general protection error in libmp3lame.so.0.0.0
Hi again, Am Samstag, den 30.05.2015, 05:12 +0200 schrieb Bernhard Übelacker: = 0xb76df6c9 init_xrpow_core_sse+105:movaps %xmm0,0x20(%esp) Yes, this movaps seems to be a SSE instruction. Also the changes in the previous patch should not change the instructions but only the alignment of the memory the instructions operate on. And if that is the case, with proper alignment it is working. But probably there is a better way to convince gcc to align the memory ... so, we have a suspect here, but not really a culprit yet. The main difference between the packages in wheezy and jessie is that the former is not built with SSE instructions at all. So, it seems that we have not intriduced a bug, but merely uncovered a bug that was well hidden before, because the code path in question was never enabled. The problem is that I am rather illiterate with regard to SSE code, to me the code looks all fine. I am thus inclined to disable SSE instructions again in the lame package. This may be ugly but serves as a work-around in unstable. But I don't think that such drastic measure is the most reasonable thing to do to the package in stable. So, I'd really appreciate if someone with more insight into SSE code could have a deeper look at it and try to figure out why the code fails on jessie i386. - Fabian signature.asc Description: This is a digitally signed message part
Bug#786438: libmp3lame0: general protection error in libmp3lame.so.0.0.0
Hello Fabian, hello Detrick, Am 29.05.2015 um 22:02 schrieb Fabian Greffrath: I could reproduce a SIGSEGV on arch i386 inside qemu VM by these actions: is this on a fresh Jessie install? Is a Jessie-Testing installation from 30th November 2014. At least upgraded to the latest (Jessie) versions 20 days ago. (amd64 did not show the fault) Ack, I couldn't reproduce it on my amd64 system as well. I tried a little further and was able to reproduce the crash in a Jessie i386 chroot on a 64bit-kernel too, so probably we can rule out a qemu bug. (Had proc not bind-mounted into chroot.) (gdb) bt #0 0xb76e30c9 in init_xrpow_core_sse () from /usr/lib/i386-linux-gnu/libmp3lame.so.0 So, this seems to be a bug in SSE code. Which means that either the code itself is buggy or your system does not support SSE instructions at all (though the latter should throw a SIGILL instead of a SIGSEGV). = 0xb76df6c9 init_xrpow_core_sse+105:movaps %xmm0,0x20(%esp) Yes, this movaps seems to be a SSE instruction. Also the changes in the previous patch should not change the instructions but only the alignment of the memory the instructions operate on. And if that is the case, with proper alignment it is working. But probably there is a better way to convince gcc to align the memory ... Would both of you please tell my the content of /proc/cpuinfo? In the qemu VM (qemu-system-x86_64 --enable-kvm -cpu host): benutzer@debian:~$ cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 107 model name : AMD Athlon(tm) 64 X2 Dual Core Processor 5000+ stepping: 1 microcode : 0x165 cpu MHz : 2600.000 cache size : 512 KB fdiv_bug: no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt lm 3dnowext 3dnow extd_apicid pni cx16 x2apic hypervisor lahf_lm cmp_legacy svm cr8_legacy 3dnowprefetch vmmcall bogomips: 5200.00 clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: On the host not inside chroot: root@rechner:/home/bernhard# cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 107 model name : AMD Athlon(tm) 64 X2 Dual Core Processor 5000+ stepping: 1 cpu MHz : 2600.000 cache size : 512 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow rep_good nopl extd_apicid pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy 3dnowprefetch lbrv vmmcall bogomips: 5223.84 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp tm stc 100mhzsteps (the same for the second core) Kind regards, Bernhard -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#786438: libmp3lame0: general protection error in libmp3lame.so.0.0.0
Hello Fabian, hello Detrick, I could reproduce a SIGSEGV on arch i386 inside qemu VM by these actions: (amd64 did not show the fault) - apt-get install icecast2 liquidsoap liquidsoap-plugin-icecast liquidsoap-plugin-lame liquidsoap-plugin-mad liquidsoap-plugin-ogg liquidsoap-plugin-vorbis - enable and start icecast2 (/etc/default/icecast2) - get a mp3 file and put it to current directory as test.mp3 - create test.sh - start liquidsoap in debugger gdb --args /usr/bin/liquidsoap test.sh content of test.sh: #!/usr/bin/liquidsoap set(log.file.path,/dev/stdout) myplaylist = single(test.mp3) output.icecast(%mp3, host = localhost, port = 8000, password = hackme, mount = basic-radio.ogg, myplaylist) (gdb) bt #0 0xb76e30c9 in init_xrpow_core_sse () from /usr/lib/i386-linux-gnu/libmp3lame.so.0 #1 0xb76d2ebf in ?? () from /usr/lib/i386-linux-gnu/libmp3lame.so.0 #2 0xb76d65e6 in CBR_iteration_loop () from /usr/lib/i386-linux-gnu/libmp3lame.so.0 #3 0xb76c3e27 in lame_encode_mp3_frame () from /usr/lib/i386-linux-gnu/libmp3lame.so.0 #4 0xb76c8e4f in ?? () from /usr/lib/i386-linux-gnu/libmp3lame.so.0 #5 0xb76c9b48 in lame_encode_buffer_float () from /usr/lib/i386-linux-gnu/libmp3lame.so.0 #6 0xb781cf77 in ocaml_lame_encode_buffer_float () from /usr/lib/liquidsoap/1.1.1/plugins/lame.cmxs #7 0xb781b72f in camlLame__fun_1175 () from /usr/lib/liquidsoap/1.1.1/plugins/lame.cmxs #8 0x0820b06f in camlOutput__f_1354 () #9 0x0820b0c5 in camlOutput__fun_1740 () #10 0x0820b7dd in camlOutput__fun_1600 () #11 0x08257c6f in camlClock__fun_1848 () #12 0x08310b3c in camlList__fold_left_1073 () #13 0x08258740 in camlClock__fun_1813 () #14 0x082582a5 in camlClock__loop_1351 () #15 0x08258daa in camlClock__fun_2074 () #16 0x082703e3 in camlTutils__fun_1346 () #17 0x08307ac8 in camlThread__fun_1081 () #18 0x083612fa in caml_start_program () #19 0x0834a675 in ?? () #20 0xb7f1befb in start_thread (arg=0x79e8b781) at pthread_create.c:309 #21 0xcde0b850 in ?? () #22 0x79e8b781 in ?? () #23 0x8350b45b in ?? () #24 0x8dc314c4 in ?? () #25 0x00b6 in ?? () #26 0x27bc8d00 in ?? () #27 0x in ?? () Building libmp3lame0 with debug information: - export DEB_BUILD_OPTIONS=nostrip - apt-get build-dep libmp3lame0 - apt-get source libmp3lame0 - dpkg-buildpackage -b - dpkg -i libmp3lame0_*.deb - gdb --args /usr/bin/liquidsoap test.sh Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb49ffb40 (LWP 20251)] init_xrpow_core_sse (cod_info=0x8731a00, xrpow=0xb49fa6f4, upper=575, sum=0xb49fa5d0) at xmm_quantize_sub.c:73 73 vec_xrpow_max._m128 = _mm_set_ps1(0); (gdb) bt #0 init_xrpow_core_sse (cod_info=0x8731a00, xrpow=0xb49fa6f4, upper=575, sum=0xb49fa5d0) at xmm_quantize_sub.c:73 #1 0xb76cf71f in init_xrpow (gfc=0x87318d0, cod_info=0x8731a00, xrpow=0xb49fa6f4) at quantize.c:127 #2 0xb76d2cc6 in CBR_iteration_loop (gfc=0x87318d0, pe=0xb49fb0c4, ms_ener_ratio=0xb49fb09c, ratio=0xb49fd06c) at quantize.c:2034 #3 0xb76c0c37 in lame_encode_mp3_frame (gfc=gfc@entry=0x87318d0, inbuf_l=0x873e48c, inbuf_r=0x87422cc, mp3buf=mp3buf@entry=0xb4a081b9 , mp3buf_size=mp3buf_size@entry=8988) at encoder.c:518 #4 0xb76c5a22 in lame_encode_buffer_sample_t (mp3buf_size=9405, mp3buf=0xb4a081b9 , nsamples=optimized out, gfc=optimized out) at lame.c:1786 #5 lame_encode_buffer_template (gfp=gfp@entry=0x865f580, buffer_l=buffer_l@entry=0xb4a048e8, buffer_r=buffer_r@entry=0xb4a06480, nsamples=nsamples@entry=1764, mp3buf=mp3buf@entry=0xb4a08018 \377\373\220D, mp3buf_size=mp3buf_size@entry=9405, pcm_type=pcm_type@entry=pcm_float_type, aa=aa@entry=1, norm=norm@entry=1) at lame.c:1897 #6 0xb76c6648 in lame_encode_buffer_float (gfp=0x865f580, pcm_l=0xb4a048e8, pcm_r=0xb4a06480, nsamples=1764, mp3buf=0xb4a08018 \377\373\220D, mp3buf_size=9405) at lame.c:1918 #7 0xb7819f77 in ocaml_lame_encode_buffer_float () from /usr/lib/liquidsoap/1.1.1/plugins/lame.cmxs #8 0xb781872f in camlLame__fun_1175 () from /usr/lib/liquidsoap/1.1.1/plugins/lame.cmxs #9 0x0820b07f in camlOutput__f_1354 () #10 0x0820b0d5 in camlOutput__fun_1740 () #11 0x0820b7ed in camlOutput__fun_1600 () #12 0x08257c7f in camlClock__fun_1848 () #13 0x08310b4c in camlList__fold_left_1073 () #14 0x08258750 in camlClock__fun_1813 () #15 0x082582b5 in camlClock__loop_1351 () #16 0x08258dba in camlClock__fun_2074 () #17 0x082703f3 in camlTutils__fun_1346 () #18 0x08307ad8 in camlThread__fun_1081 () at thread.ml:37 #19 0x08360506 in caml_start_program () #20 0x0834a6b4 in caml_thread_start () #21 0xb7f18efb in start_thread (arg=0x85e8b781) at pthread_create.c:309 #22 0x9de0b850 in ?? () #23 0x85e8b781 in ?? () #24 0x8350b47d in ?? () #25 0x8dc314c4 in ?? () #26 0x00b6 in ?? () #27 0x27bc8d00 in ?? () #28 0x in ?? () (gdb) bt full 1 #0 init_xrpow_core_sse (cod_info=0x8731a00, xrpow=0xb49fa6f4, upper=575, sum=0xb49fa5d0) at xmm_quantize_sub.c:73 i = optimized out tmp_max = 0 tmp_sum = 0 upper4 = 572
Bug#786438: libmp3lame0: general protection error in libmp3lame.so.0.0.0
On Wed, May 27, 2015 at 10:30 AM, Fabian Greffrath fab...@debian.org wrote: Am Mittwoch, den 27.05.2015, 10:03 -0400 schrieb Detrick Merz: lame does *not* seem to produce this same error. I took a freshly built wheezy system, installed icecast2 and liquidsoap as before, upgraded to jessie, saw the general protection error when trying to start liquidsoap. I then installed lame, fed it a wav, and it happily produced an mp3 file. No errors appeared on stdout or in /var/log/messages. Alright, so it appears that this bug is rather in liquidsoap (or one of its plugins or the way they call libmp3lame) than in libmp3lame itself. Before I ask you to rebuild lame on your system, please tell me the *exact* steps that are required to reproduce the bug. I've rebuilt my test system a few times to make sure I've covered the steps correctly. - Install Debian Wheezy i386 net install (minimal is fine) - apt-get install icecast2 - apt-get install liquidsoap - start icecast2 - configure liquidsoap to output.icecast(%mp3) - sed -i 's/wheezy/jessie/g' /etc/apt/sources.list - apt-get update - apt-get install icecast2 (optional) - apt-get install liquidsoap OR apt-get upgrade - /etc/init.d/liquidsoap stop - /etc/init.d/liquidsoap start OR - Install Debian Wheezy i386 net install (minimal is fine) - sed -i 's/wheezy/jessie/g' /etc/apt/sources.list - apt-get update - apt-get upgrade - apt-get dist-upgrade - apt-get install icecast2 - apt-get install liquidsoap - start icecast2 - configure liquidsoap to output.icecast(%mp3) In the past couple of days I've discovered that using a clean Jessie install does not seem to produce the same error. I thought I had tested that before and seen otherwise, but I've tried it multiple times and cannot reproduce it with a clean Jessie build. Given the two sets of paths listed above to reproduce this, I'm guessing there's some holdover from the Wheezy install that's the root cause, but it's probably not something explicitly in liquidsoap or the libmp3lame library? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#786438: libmp3lame0: general protection error in libmp3lame.so.0.0.0
Hi Bernhard, hi Detrick, Am Freitag, den 29.05.2015, 19:02 +0200 schrieb Bernhard Übelacker: I could reproduce a SIGSEGV on arch i386 inside qemu VM by these actions: is this on a fresh Jessie install? (amd64 did not show the fault) Ack, I couldn't reproduce it on my amd64 system as well. (gdb) bt #0 0xb76e30c9 in init_xrpow_core_sse () from /usr/lib/i386-linux-gnu/libmp3lame.so.0 So, this seems to be a bug in SSE code. Which means that either the code itself is buggy or your system does not support SSE instructions at all (though the latter should throw a SIGILL instead of a SIGSEGV). Would both of you please tell my the content of /proc/cpuinfo? Thanks! Fabian signature.asc Description: This is a digitally signed message part
Bug#786438: libmp3lame0: general protection error in libmp3lame.so.0.0.0
Hi again Detrick, Am Freitag, den 29.05.2015, 15:55 -0400 schrieb Detrick Merz: Given the two sets of paths listed above to reproduce this, I'm guessing there's some holdover from the Wheezy install that's the root cause, but it's probably not something explicitly in liquidsoap or the libmp3lame library? i find this puzzling. Could you make sure you end up with the same libmp3lame package when dist-upgrading and when installing a fresh Jessie system? Also, could you make sure if the lib throws a SIGSEGV or a SIGILL? - Fabian signature.asc Description: This is a digitally signed message part
Bug#786438: libmp3lame0: general protection error in libmp3lame.so.0.0.0
Hi Detrick, please leave the bug's email address in the CC field. Am Mittwoch, den 27.05.2015, 10:03 -0400 schrieb Detrick Merz: lame does *not* seem to produce this same error. I took a freshly built wheezy system, installed icecast2 and liquidsoap as before, upgraded to jessie, saw the general protection error when trying to start liquidsoap. I then installed lame, fed it a wav, and it happily produced an mp3 file. No errors appeared on stdout or in /var/log/messages. Alright, so it appears that this bug is rather in liquidsoap (or one of its plugins or the way they call libmp3lame) than in libmp3lame itself. I'm happy to do what I can if it'll help, and I don't exactly have a broken system since I can revert to the old library. Send all the demands you want, I will do what I can. Before I ask you to rebuild lame on your system, please tell me the *exact* steps that are required to reproduce the bug. Thank you! - Fabian signature.asc Description: This is a digitally signed message part
Bug#786438: libmp3lame0: general protection error in libmp3lame.so.0.0.0
Control: tags -1 -newcomer Hi Detrick, thank you for your bug report! Am Donnerstag, den 21.05.2015, 13:35 -0400 schrieb Detrick Merz: Tags: newcomer The newcomer tag is meant for bugs that are easy enough for new contributors to pick up. I don't think this is the case here, honestly. ;) I was finally able to get it working again by reverting to libmp3lame0 v3.99.5+repack1-3. Phew, a lot has changed between this revision and the one in Jessie. Since the protection error seems to come from the library, are you able to reproduce it using the lame frontend from the package of the same name? And if yes, would you be able to rebuild the package with debug symbols in order to run it with gdb and produce a backtrace (note to myself: TODO add lame-dbg package!)? Sorry I cannot be more helpful than demanding all these thing from you at this point. :/ Hope this will help. cheers, Fabian PS: I will be mostly offline for the next week or so... signature.asc Description: This is a digitally signed message part
Bug#786438: libmp3lame0: general protection error in libmp3lame.so.0.0.0
Package: libmp3lame0 Version: 3.99.5+repack1-7 Severity: important Tags: newcomer Dear Maintainer, Upon upgrading from wheezy to jessie, liquidsoap stopped being able to stream mp3 to icecast2. Streams in other formats (e.g. vorbis) continued to work. When running libmp3lame0 3.99.5+repack1-7, errors appeared in /var/log/messages: May 15 11:53:28 fluffy kernel: [ 3874.762067] liquidsoap[1515] general protection ip:b682f0c9 sp:b28f9538 error:0 in libmp3lame.so.0.0.0[b6801000+48000] I was finally able to get it working again by reverting to libmp3lame0 v3.99.5+repack1-3. More specifically, I: - built a fresh wheezy system - installed icecast2 liquidsoap - made a backup of /usr/lib/i386-linux-gnu/libmp3lame.so.0.0.0 (md5: 6a3c42fe4c459d1815950a32db828e41, this is from 3.99.5+repack1-3) - pointed /etc/apt/sources.list to the jessie repository - apt-get update - apt-get install icecast2 - apt-get install liquidsoap (liquidsoap continued to work at this point, until it was restarted) - copied the backup of libmp3lame.so.0.0.0 into /usr/lib/i386-linux-gnu/ - restarted liquidsoap successfully Taking the wheezy-jessie upgrade a step further by doing an apt-get upgrade and apt-get dist-upgrade resulting in libmp3lame.so.0.0.0 being replaced with a newer version again, which reintroduced the general protection error. Again, when I reverted back to the older version of the library the issue went away. I'll also note that I was able to reproduce the issue with a fresh jessie install. I've rebuilt this system several times trying to resolve this issue. The system has a fairly minimal install (only the SSH server package is selected during the install process, only icecast2 and liquidsoap are installed after the build is complete). I've also reproduced this on two different i386 systems, although both are AMD Athlon based. Thanks, -detrick -- System Information: Debian Release: 8.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.16.0-4-686-pae (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libmp3lame0 depends on: ii libc6 2.19-18 ii multiarch-support 2.19-18 libmp3lame0 recommends no packages. libmp3lame0 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
