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
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
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
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.
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
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
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.
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
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
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
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
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
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
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
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
Trimming cc list because this is only semi-related to the bug, but...
On 1 June 2015 at 02:45, Fabian Greffrath fab...@debian.org wrote:
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
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
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,
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:
---
Hello Fabian,
unfortunately this did not work too (with or without packed).
Kind regards,
Bernhard
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
Saludos Felipe,
Am Montag, den 01.06.2015, 12:12 -0300 schrieb Felipe Sateler:
In general I would strongly advise to specify all the flags you want
to enable and have the build system fail if they cannot be enabled. At
the same time, explicitly disable all flags not used in the debian
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
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
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,
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
-
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
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,
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.
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
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
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
Processing control commands:
tags -1 -newcomer
Bug #786438 [libmp3lame0] libmp3lame0: general protection error in
libmp3lame.so.0.0.0
Removed tag(s) newcomer.
--
786438: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786438
Debian Bug Tracking System
Contact ow...@bugs.debian.org
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,
33 matches
Mail list logo
