| |||||||||||||
Glibc change exposing bugsGlibc change exposing bugsPosted Nov 10, 2010 21:47 UTC (Wed) by jedbrown (subscriber, #49919)In reply to: Glibc change exposing bugs by stijn Parent article: Glibc change exposing bugs
Valgrind produces exactly such a warning.
(Log in to post comments)
Glibc change exposing bugs Posted Nov 10, 2010 22:09 UTC (Wed) by stijn (subscriber, #570) [Link]
You are right. My point would have been phrased better like this:
In a communal view of software production and use it seems a bit unthoughtful to push this through and let (less technical) users suffer. It makes the software and the makers look bad. It makes it worse if that is shrugged off in a disdainful manner.
Glibc change exposing bugs Posted Nov 11, 2010 18:47 UTC (Thu) by oak (subscriber, #2786) [Link]
> Valgrind produces exactly such a warning.
And it has been doing it for nearly a decade. And of course many other free memory debugging facilities like Duma (improved version of Electric Fence), mpatrol etc. produce these warnings too. As I would assume proprietary ones (on other platforms) to do also...
One could also define _FORTIFY_SOURCE to turn memcpy() etc into checking, slower versions. For more info, see:
Glibc change exposing bugs Posted Nov 17, 2010 14:45 UTC (Wed) by meuh (subscriber, #22042) [Link]
As I said here https://bugzilla.redhat.com/show_bug.cgi?id=638477#c116
Using -D_FORTIFY_SOURCE enable only check for overflow when source and destination length are known (or can be computed).
_chk() variant of memset(), memcpy(), etc. didn't check for overlap.
And one should know that GCC provides inline versions of such functions, so valgrind won't be able to overload them and provide stronger argument checking.
Glibc change exposing bugs Posted Nov 17, 2010 19:08 UTC (Wed) by oak (subscriber, #2786) [Link] > And one should know that GCC provides inline versions of such functionsWasn't this article about Glibc memcpy(), not the GCC (libgcc?) one? Anyway, AFAIK GCC does that only if code is compiled with optimizations. Valgrind and -O0 compiled code are speed-wise pretty horrible combination though. Then it might be better to use one of the other memory debugging tools that don't do CPU emulation like Valgrind does... Note that GCC doesn't inline its memcpy() code just for explicit (fixed size) memcpy() calls. Inlined version may also be used for assignments and developers are able to mess up addresses of variables used in thing like this too: struct foobar_t *a = arg1, *b = arg2; ... *a = *b; (I found this issue on implicit GCC memcpy() when my code didn't have correct alignment for one of above kind of pointers on platform that required things to be properly aligned. It triggering a kernel alignment exception handler bug had me scratching my head until more knowledgeable colleague came to rescue... I think with overlapping pointer addresses results may be even more mysterious as they show up later.)
|
|||||||||||||