Bug#625522: glibc: causes segfault in Xorg
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.
Reply to: