Message-Id:	<4.1.19990215100100.00a59420@hal.nt.tuwien.ac.at>
X-Sender:	tony AT hal DOT nt DOT tuwien DOT ac DOT at
X-Mailer:	QUALCOMM Windows Eudora Pro Version 4.1
Date:	Mon, 15 Feb 1999 10:43:31 +0100
To:	djgpp AT delorie DOT com
From:	Anton Helm <tony AT nt DOT tuwien DOT ac DOT at>
Subject:	debugging free() problems
Mime-Version:	1.0
Reply-To:	djgpp AT delorie DOT com

One of the programming errors I make from time to time
is freeing a part of the memory that has been freed before.

ANSI says
<quote>
The free funczion causes the space pointed to by ptr to be deallocated, that is, made
available for further allocation. If ptr is a NULL pointer, no action occurs. Otherwise, if the
argument does not match a pointer earlier returned by the calloc, malloc or realloc
function, or if the space has been deallocated by a call to free or realloc, the bahavior is
undefined.
<end quote>

And that's exactly what's happening with DJGPP v2.02: The behavior is undefined.
Well, that's somewhat inprecise, it has some defined behavior, but I couldn't find
out which...

I recently had such a bug in one of my programs (freeing memory twice).
The programm stopped somewhere and didn't return to DOS-prompt.
Pressing Ctrl-C killed the program (as expected).

Now I started debugging with gdb. 
I set some breakpoints etc. because I didn't yet know what's happening.
At some time the program stopped, but now it was impossible to return anywhere.
Especially I couldn't return to gdb. It simply hanged there with a blinking cursor.
The only chance was HARD RESET and rebooting. 
You might imagine that it is somewhat time comsuming to reboot every time 
for setting new breakpoints to debug your program ...

Finally I found the second call to free() which was causing this behavior.

I know that memory management must be fast and therefore you cannot make it
completely foolproof. But it might be an idea to add some checks when 
compiling/linking with debug info and/or make gdb detecting such holes easier.

Tony

- Raw text -