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? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
