[Gtkradiant] [Bug 99] GDI leak in GTK console text and entity properties text

[gtkradiant@zerowing.idsoftware.com]

http://zerowing.idsoftware.com/bugzilla/show_bug.cgi?id=99

ttimo@idsoftware.com changed:

           What    |Old Value                   |New Value
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Platform|                            |All



------- Additional Comments From ttimo@idsoftware.com  2001-06-22 04:56 -------
I started looking into it. I can confirm that 2 new GDI objects are created 
somewhere below:

qe3.cpp - line 1731 - extern "C" void Sys_FPrintf (int level, const char 
*text, ...)
gtk_text_insert (GTK_TEXT (g_qeglobals.d_edit), NULL, color, NULL, buf, -1);

After compiling the gtk libraries as debug (no boundcheckers instrumentation), 
BC detects several resource leaks, but they are general resource leaks to the 
application. It didn't show anything particular by comparing a flat run and a 
run with basic manip to print stuff in the console.

It would be handy to single step into the debug gtk dlls, but taskmanager 
doesn't see the new GDI objects until you get out of the debugging. I tried 
various resources, for example 
http://msdn.microsoft.com/msdnmag/issues/01/03/leaks/leaks.asp
Which comes with a GDI counter. But it has the same problem, it will see the 
new GDI objects only when it gets out of the loop.

I haven't found a way to retrieve the handles of the new GDI objects and get 
more information about them (such as GDI type etc.). This would help but it 
doesn't look possible on win2k (the article states that it is possible with 
win98).

Several tracks to explore from there:

1) It may be the gnu-intl or iconv libraries. We use binary versions for them, 
we never recompiled them. First test would be to grab newer binaries if 
possible and try to reproduce the problem. Then compile them as debug versions 
and test them against BC.

2) Maybe it's not leaking? The GDI object count goes up but they are still 
referenced. That would explain why BC doesn't see anything. This would also 
mean that the behaviour would have to be changed in the text widget somewhere.