Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 14 Aug 2012 22:15:09 -0500
From: "jfoug" <>
To: <>
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.


>From: Solar Designer []
>On Tue, Aug 14, 2012 at 11:04:16PM +0200, magnum wrote:
>> BTW, the Test Suite *should* have triggered this segfault, but did
>> Very confusing. Maybe I'll do some forensics to understand the whole
>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.

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.