[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: glibc: causes segfault in Xorg

On Wed, May 04, 2011 at 12:42:16AM -0500, Steve M. Robbins wrote:
> On Wed, May 04, 2011 at 12:10:48AM -0500, 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).
> Oh my word.  So glibc 2.13 breaks random binaries that happened to
> incorrectly use memcpy() instead of memmove()?

memcpy() has fat warnings about the areas not overlapping, and that's the
very purpose of that function: a memmove() that is faster but less safe.

> What's wrong with the glibc developers (and Ulrich Drepper in particular)?

Nothing wrong, it is exactly the same as new compilers breaking behaviour
forbidden by the standard that used to work before.

The only problem is the breakage happening rarely, and thus being able to
survive for long.

> I'm with Linus on this: let's just revert to the old behaviour.  A
> tiny amount of clock cycles saved isn't worth the instability.

I'd instead propose to sacrifice a tiny amount of cycles to check for
overlapping and abort()ing so buggy code can be fixed.  Random instability
is the worst kind of error, a clean crash is easy to fix.  Heck, we can even
make a change just before wheezy is frozen to make it call memmove() when a
breakage is detected.  Just please don't paper over the bugs until then.

1KB		// Microsoft corollary to Hanlon's razor:
		//	Never attribute to stupidity what can be
		//	adequately explained by malice.

Attachment: signature.asc
Description: Digital signature

Reply to: