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