Request for new function in glib (was: how can I trust glib when it has so manymemleaks?)
- From: Ionutz Borcoman <borco borco-ei eng hokudai ac jp>
- To: gtk <gtk-list redhat com>
- Subject: Request for new function in glib (was: how can I trust glib when it has so manymemleaks?)
- Date: Fri, 19 Mar 1999 14:01:20 +0900
People are complaining that this topic is too much discussed and it
returns so often on the list. I don't understand them, because:
a. the documentation is almost ZERO.
b. not everybody is an expert to read the code from all the libs he/she
uses (I'm not).
c. traditional tools of checking for memleaks reports leaks.
So here my proposals:
1. as this discussion is so often back, it should be transformed in FAQ.
2. Unfortunately, I have seen only assuarances from some people that
glib knows what it does. Ok. I believe them. But they didn't give me a
way to check that what I am doing is ok. And I can't check this as glib
makes things unreadable. What I need is a function like:
A simple functions that will call free() on all the memory glib manages.
Put glib memory pool in the same state as when I started the program.
Nobody should be required to call it, of course. But those who want to
profile their programs will have a way to use traditional tools for this
task. If after this call my mem checker program still reports leaks,
then those are real leaks (mine or of glib). I understand that Win32
port already have such a function.
Maybe the g_mem_profile() should also give a more detailed report (as
sugested already, a report of individual freed bytes, not grand total
would be nice).
These are functions which are not for dayly usage, but for profiling and
debuging. Performance impact on the programs should not be an insue
here. When you know your program is OK, you can just comment them (or
put them in #ifdef #endif block).
] [Thread Prev