Bug#625521: glibc: causes segfault in Xorg
Le 04/05/2011 09:05, Jonathan Nieder a écrit :
> Aurelien Jarno wrote:
>> Le 04/05/2011 07:43, Jonathan Nieder a écrit :
>>> Jonathan Nieder wrote:
>
>>>> Sounds like http://sourceware.org/bugzilla/show_bug.cgi?id=12518
>>>> which is fixed (sort of) by commit 0354e355 (2011-04-01).
>>
>> Are you sure this is related? I find strange a recent version of xorg is
>> still not fixed
>
> No, not sure --- I was only reminded. But it does fit the symptoms
> well: regression occuring when upgrading to glibc 2.13, consisting of
> a segfault in memcpy_sse3.
>
> (As you suggested) it might be specific to some driver or some aspect
> of the configuration. The easiest way to confirm would be with
> valgrind.
>
>> No, it's not something possible to cherry-pick as it is based on symbol
>> versioning from version 2.14. Also it only really apply to binary-only
>> distribution, in Debian as soon as your rebuild the package, it will use
>> the new 2.14 symbols, and memcpy instead of memmove.
>
> That sounds great --- it would take care of upgrades from broken
> packages in squeeze and as soon as you rebuild a package, there is a
> chance to fix it.
Except that package rebuild doesn't mean a new upload (e.g binNMUs).
> I imagine the release team wouldn't like it much, though.
>> I don't think we can really keep a version in experimental just for
>> that. And reverting that patch means nobody will complain, and issues
>> will never be fixed.
>
> Reverting may be the best way in the short term, especially if the
> upstream fix is four months away. I suppose Steve was right to ask
> for help on -devel. Maybe someone will come up with a better idea.
I am not convinced that the upstream fix is really the solution. As soon
as the package is rebuild, the problem will happen again.
> E.g., how about adopting hjl's suggestion and making the
> behavior (temporarily) conditional on a LD_DONT_BIND_IFUNC_MEMCPY_TO_MEMMOVE
> environment variable?
I don't really feel like enabling critical features depending on an
environment variable that might not be properly propagated in some shell
scripts.
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurelien@aurel32.net http://www.aurel32.net
Reply to: