yeah, i was just wondering why doing a free() on the last example (the char* stuff...) decreased the used mem by 'a.out' _immediately_ and on my first example (source attached in 1st mail) _not_ (nothing happened after free; only the os cleaned up after exit). i tried that several times and got the same behaviour as mentioned, so i thought there might be a bug in my source.... another fact would proof my assumption.... during programming (on that source) i first cleaned up my mem recursively... which ended up in segfault when allocating more than (e.g.) 1.5gig over the time, so a stack overflow might occur. instead of traversing my built tree recursively, i thought about putting the lists with nodes (my 'parts' of the tree) into a linked list to solve this issue. but i'm wondering about the following fact... freeing recursivly made a visible decrease of my used mem in 'htop' while freeing with my iterative variant made no decrease at all... so i thought about a bug in my program... (but cannot find it....) 2009/4/28 Bert Wesarg <bert.wesarg@xxxxxxxxxxxxxx>: > On Tue, Apr 28, 2009 at 11:20, leo mueller <llug.dan@xxxxxxxxxxxxxx> wrote: >> hi all, >> >> i got a little problem with free() ... i am allocating mem for a >> special struct and putting it afterwards >> into a linked list. allocating works fine, but freeing not. i'm >> tracking the program with htop. after >> allocating, the percentage of mem usage stays constant ... > Can you at least describe what do you expect to happen, and what does > not work with freeing? > > bert >> >> the test-file is attached. >> >> any help is appreciated. big thanks :) >> > -- To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html