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