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 Subject: debugging free() problems Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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 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. 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