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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.