Re: Performance issue with new gtk 2.0 for win32
Harring Figueiredo <[email protected]>
| Newsgroups | gmane.comp.video.gimp.windows.devel |
|---|---|
| Message-ID | <[email protected]> |
Tor, Thanks for the reply. I actually trust people's code more than my own :(. So I guess I will have to go to my app and track malloc, g_strdup, and the like and do what you are proposing, i.e. match with a g_free. What I see in my app running on Windows is that the memory just keeps growing and growing and growing. I did notice something REALLY interesting today. The memory was up to 87MB and when I "stopped" (i.e. I have a timeout_func that I can start and stop with a button press) my application, it went back to 3MB. This leads me to think that : 1) Win NT Task MAnager is bogus (more likely) 2) Gtk/GDK/GLIB libs free up memory chunks when they age ???? (Unlikely huh?) This is driving me nuts.. Any sugestion as what it might be happening ? Thanks for the help. Harring. --- Tor Lillqvist <[email protected]> wrote: > Harring Figueiredo writes: > > What is the approach you guys use to track memory leak on windows > > when programming GTK. I use Valgrind on linux, but my app depends > > on another Windows app; therefore, I cannot trace it on linux > > alone. > > I guess Purify is good, but it's expensive. BoundsChecker too, > perhaps, but I have a feeling Purify's memory leak detection is > better. I have access to BoundsChecker (on Windows) and Purify (on > Unix) at work, but haven't used either for GTK+. > > Last time I really had to track down a memory leak in GTK+ (actually, > in pangowin32) I just added debugging printout to g_malloc and g_free, > run a loop in a test program that clearly leaked memory, did some > mangling on the output with Emacs keyboard macros to delete > corresponding allocations and deallocations, which left the printout > from the offending allocations that weren't being deallocated. Luckily > the number of bytes allocated in those leaks was the same all the > time, and unique (at least in the loop), so it was then just a matter > of setting a conditional breakpoint that fired when allocatiing this > number of bytes. > > --tml > > > __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com