Bug#625522: glibc: causes segfault in Xorg
Le 04/05/2011 14:02, Jonathan Nieder a écrit :
> Aurelien Jarno wrote:
>
>> Except that package rebuild doesn't mean a new upload (e.g binNMUs).
>
> Yes, it would be painful if many packages have bugs of this kind.
> Open source projects tend to check for this (and I've never run into
> it after using libc 2.13 for a while) but I could easily be
> underestimating how bad it is.
>
> What I meant is that packages rebuilt against libc from sid are
> generally targetted at wheezy. That would (one hopes) give a little
> time to test and fix them.
>
>> I am not convinced that the upstream fix is really the solution. As soon
>> as the package is rebuild, the problem will happen again.
>
> I think it's mostly meant as a workaround to allow people to keep
> using Flash and old binaries.
>
> Another big downside is making almost everything depend on libc6 (>=
> 2.14). Binaries built against glibc with the upstream fix wouldn't be
> usable on older systems.
>
>> Le 04/05/2011 09:05, Jonathan Nieder a écrit :
>
>>> 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.
>
> I'm not a huge fan of the envvar trick, but I think you read it
> backwards. Unlike hjl in the bug log, I was suggesting using the safe
> behavior when the envvar is not set. At worst a script using sudo or
> "env -i" would cause programs it calls to use memmove instead of
> memcpy.
>
> Unfortunately I fear testers would be unlikely to actually use such
> a variable. Even MALLOC_PERTURB_ is not as widely used as one would
> like, judging from the bugs it sometimes uncovers.
>
> So yes, back to the drawing board. Thanks for your thoughtfulness.
>
I have tried to play a bit with some test codes. I have discovered that
even with old memcpy() implementation, it's not always possible to have
code that overlap. What changes with the new memcpy_ssse3 is that the
the copy happens backward, so the conditions are not the same.
It means that if we simply replace memcpy() by memmove(), people might
write code that works well with the new libc, but doesn't work on old
libc (or even worse depending on how other distributions have chosen to
workaround this bug, if they chose to do so). It doesn't seems to be a
good idea, especially for people using Debian as a development platform.
Basically it seems we only want to replace calls to __memcpy_ssse3_back
by calls to __memmove_ssse3_back.
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurelien@aurel32.net http://www.aurel32.net
Reply to: