|
Message-ID: <003601cd7a94$2d6dc710$88495530$@net> Date: Tue, 14 Aug 2012 22:15:09 -0500 From: "jfoug" <jfoug@....net> To: <john-dev@...ts.openwall.com> Subject: RE: Serious wordlist.c bug fixed (all branches) Those are the worst kind of bugs to find. You likely are right. It is freed, and then very shortly after that, used to display something, and no obvious error happens. A stale pointer like that might work almost every time. But then for some strange load reason, fail. If it is explained right, by Magnum, and later reused, then it absolutely needs to be left intact, even if it 'seemed' to be working. A good way to find these ugly problems, is with a debugging allocation lib. The free will hammer the memory, before freeing it, or do something else like not freeing it, and setting a HW lock on the memory, so if the app touches that memory again, it will core (or assert or something). Then if that dangling pointer is used, the memory is NOT the same as it was before calling the free, or you will get a core file, or an assertion output of some kind. I thought tools like valgrind would find these type of things? I used to use bounds checker and it was wonderful at finding these things. Purify on sparc does it, but that tool finds SO many false positives, it makes it hard to use. Jim. >From: Solar Designer [mailto:solar@...nwall.com] > >On Tue, Aug 14, 2012 at 11:04:16PM +0200, magnum wrote: >> BTW, the Test Suite *should* have triggered this segfault, but did >not. >> Very confusing. Maybe I'll do some forensics to understand the whole >issue. > >Why, it is very common that free() does not actually alter the memory, >nor release it back to the OS yet. Once you've free()d something, >you're not guaranteed that it'll stay around and be intact anymore, but >you're also not guaranteed that it won't. > >Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.