Subject: Re: malloc question

From: Nils Lohner <[email-masked]>
Date: Thu, 14 Dec 2000 10:28:00 +0100

cc'ing fvwm-workers list for comments... I've had a few ideas this 
morning.  I should stay in bed longer more often... :)

In message <[email-masked]>, Dan Espen 
writes:
>"Nils Lohner" <[email-masked]> writes:
>> Final comment: there's only one window creation call:
>>     *ptmp_win = (FvwmWindow *)safemalloc(sizeof(FvwmWindow));
>> can we track that pointer (and all others) in a list and call a 
>> different free function that allows us to track when a window is freed? 
>>  That info could go into a fvwm_msg() call...
>
>Well, tracking the mallocs and frees was the first thought that
>came to me, but I'm not sure its going to help...let me try to
>work this out.
>
>Lets say there is 1 malloc and 5 frees.  If the code prints where it
>is and the address being malloced, we'd see:
>
>malloc FvwmWindow addr 0x12341234
>malloc FvwmWindow addr 0x11110000
>malloc FvwmWindow addr 0x22222222
>malloc FvwmWindow addr 0x88888888
>...
>free fvwmWindow on Notify addr 0x22222222
>free fvwmWindow on event x addr 0x88888888
>...
>
>After that, if you got a core dump and it was the window structure at
>0x22222222, then I guess you would know that the free at "Notify" was
>no good.
>
>So I guess that could work, so my idea was to find all the FvwmWindow
>mallocs and frees and print the memory addresses, and then try to tie
>that back to the core file address.
>

Well, there's a simpler idea that may cause the fault to happen more 
quickly.

0. add a --enable-clean-mem configure option to enable all of the stuff 
below

1. in safemalloc() initialize the allocated memory via
   memset(ptr, '\0' length);
   so that you see immediately if something's freshly initialized.  
That way a free'd space that's reallocated is blank instead of 
(potentially) containing most of a window information structure.

2. in safemalloc() track every pointer that is allocated in a separate 
linked list structure (via malloc, so you don't recursively do this :) 
containing the pointer, the size, and maybe type (pass type via a 
string i.e. "FvwmWindow"... this would need to get added everywhere, 
but there aren't that many safemalloc calls...) and timestamp.

3. write a cleanfree() call that checks the linked list for the pointer 
and size, and wipes the memory before freeing it with another 
memset(ptr, '\0' length);  That way the pointers should be NULL and get 
spotted by regular idiot checks in the code right away (hopefully).

4. do what you proposed above since that's the logical next step of 
this (with the "PointerType" string in the linked list this could be a 
useful general debugging tool as well to track any specific type of 
pointers...

How does this sound?  If all mallocd and freed memory is NULLed out, 
then the crash should happen sooner or warning bells should go off in 
FVWM.

If it doesn't point us to the problem it should at least get us a good 
bit closer.

Regards,
Nils.

--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Nils Lohner <[email-masked]>
Date: Thu, 14 Dec 2000 12:40:45 +0100

In message <[email-masked]>, Nils Lohner 
writes:
....
>useful general debugging tool as well to track any specific type of 

Also:
5. At FVWM's exit, check the pointers that have not been freed.  This could turn up a few nice errors as well...

Well, here's the amount of work needed to implement this... I've got the code for the linked lists to track the pointers done, so all that's left is to change all of the safemalloc calls to pass a pointer name/type in a char[] and to put a wrapper around free with the cleanfree(ptr, const char* ptrname)

/mnt/build/fvwmdevel/fvwm-2.3.25 > grep safemalloc fvwm/*c | wc
     90     578    6301
/mnt/build/fvwmdevel/fvwm-2.3.25 > grep safemalloc libs/*c | wc
     30     187    1880
/mnt/build/fvwmdevel/fvwm-2.3.25 > grep free libs/*c | wc
     89     638    5274
/mnt/build/fvwmdevel/fvwm-2.3.25 > grep free fvwm/*c | wc
    411    1589   18317
/mnt/build/fvwmdevel/fvwm-2.3.25 > 

Where should I send the code when I have it working?  To the list, to Dan, to Dominik?

Nils.

---

From: "Paul D. Smith" <[email-masked]>
Date: 14 Dec 2000 10:41:45 -0500

The very _first_ thing you should do is go get a malloc debug tool like
dmalloc, etc.

These kinds of gross pointer problems have been around for years, and
the methods of tracking them down are likewise well known--no need to
reinvent the wheel here.  There are a number of free software tools like
dmalloc which replace the system malloc with versions that do the sorts
of things you've been discussing:

They will:

 1) initialize allocated memory to a special sentinel value
 2) initialize freed memory to a different special sentinel value
 3) check, in various system functions, that you aren't using memory
    that has been allocated but not initialized, or been freed, etc.

Although without very advanced (and non-free) tools like Insure++ and
Purify you won't get exact details, these sorts of tools should get you
crashing a lot closer to where the actual problem is, rather than a long
time afterwards.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <[email-masked]>    HASMAT--HA Software Methods & Tools
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Olivier Chapuis <[email-masked]>
Date: Thu, 14 Dec 2000 22:16:33 +0100

> The very _first_ thing you should do is go get a malloc debug tool like

Yes, there are a lot of such stuff:

http://www.cbmamiga.demon.co.uk/mpatrol/mpatrol_62.html#SEC62

Olivier