Re: glibc: causes segfault in Xorg
Hi,
On Wed, May 04, 2011 at 10:56:27PM -0500, Steve M. Robbins wrote:
> > And furthermore, even if Debian chooses to "fix" this, upstreams will
> > be forced to eventually cater to the default glibc behavior for every
> > other libc distro out there that does not have their own "fix" (and
> > non-libc OS's where this behavior already exists),
>
> That's fine: let others be the guinea pigs, then introduce the
> optimized memcpy later when the rest of the world has adapted.
I hope the glibc maintainer does not share this view, then. If we were in
the midst of preparing a release, I'd agree and argue that such a change
shouldn't happen, because of the risk of regression, but otherwise the
whole point of testing/unstable is to find these types of things and
get them fixed before the next release.
> > so gains would be potentially limited.
>
> For me, having a working system would be a great gain!
As would be with getting the buggy applications fixed. My guess is
that the glibc upstream would side for the latter of these two, and I
don't think it's unreasonable that the debian maintainer might decide
to follow suit, since the buggy applications will be (eventually)
caught and fixed.
> > That said, regressions do suck, especially when they take the form of
> > heisenbugs. But one could easily hack something LD_PRELOAD'able check
> > for stuff like this without forcing a global change.
>
> Sounds interesting. What do you have in mind?
The same types of hacks used to find other "nonstandard" or "undefined"
behavior (à la valgrind). Simply override the problematic function
with your own via an LD_PRELOAD'd shared library. Proof of concept:
me@host:~/debug-memcpy$ ./test_memcpy
before: aaaaaaaabbbbbbbbccccccccddddddddeeeeeeeeffffffffgggggggghhhhhhh
after: aaaaaaaabbbbbbbbddddddddeeeeeeeeffffffffffffffffgggggggghhhhhhh
me@host:~/debug-memcpy$ env LD_PRELOAD=./memcpy.so ./test_memcpy
before: aaaaaaaabbbbbbbbccccccccddddddddeeeeeeeeffffffffgggggggghhhhhhh
Error: memcpy used on overlapping regions
Aborted
me@host:~/debug-memcpy$ env MEMCPY=warn LD_PRELOAD=./memcpy.so ./test_memcpy
before: aaaaaaaabbbbbbbbccccccccddddddddeeeeeeeeffffffffgggggggghhhhhhh
Warning: memcpy used on overlapping regions
after: aaaaaaaabbbbbbbbddddddddeeeeeeeeffffffffffffffffgggggggghhhhhhh
me@host:~/debug-memcpy$ env MEMCPY=safe LD_PRELOAD=./memcpy.so ./test_memcpy
before: aaaaaaaabbbbbbbbccccccccddddddddeeeeeeeeffffffffgggggggghhhhhhh
after: aaaaaaaabbbbbbbbddddddddeeeeeeeeffffffffffffffffgggggggghhhhhhh
The first case above illustrates the "undefined behavior" which might crash,
the remaining two show using an LD_PRELOADED version of memcpy with the
checks to override the behavior.
I put a tarball up on http://seanius.net/tmp/debug-memcpy.tgz if you want to
check it out, it's maybe a dozen lines of actual code. Note that I haven't
tested the bounds checking corner cases for 100% accuracy.
If you were running something super critical on testing, like a mars rover
or a robot that does brain surgery, you could install this system-wide and
hack the default action, and then you get your stability back. Otherwise,
I'd think taking the default glibc behavior and using something like this
as one of several debugging tools when the heisenbugs pop up would be
pretty reasonable. Maybe valgrind already does checks like this, but
if not, I imagine that it wouldn't be too hard to add the same check there.
sean
--
Reply to: