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 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4dc1292a.6010...@aurel32.net
