Hi All,
I found out the reason for leak. It was from GTK+ DirectFB backend and
not from DirectFB library. Functions which were responsible for
de-allocating memory in DirectFB were not called. This resulted in
accumulation of memory.
The functions for deallocating memory was under an
#if
On Thu, May 15, 2008 at 2:03 PM, [EMAIL PROTECTED] wrote:
2008/5/15 Harinandan S [EMAIL PROTECTED]:
On DirectFB backend i used DirectFB 1.1.1 with GTK+ 2.12.2. Is there
any issues with using these versions since i am able to observe huge
leaks on DirectFB backend. Is there any possibility
2008/5/19 Harinandan S [EMAIL PROTECTED]:
Anyway, I digged some more details about the leak. When i stepped
through the code i found that gdk_window_destroy_notify function in
gdkwindow-directfb.c which is called when the window is really gone is
not being called.
I also found a quite old
Hi All,
I observed continuous accumulation of memory while running GTK over
DirectFB on MontaVista linux on TI Davinci. I also observed
significant memory accumulation while running GTK-win32 on Windows XP.
But to my surprise there is no accumulation of memory
on GTK-X window running on RHEL 4 on
2008/5/14 Harinandan S [EMAIL PROTECTED]:
I observed continuous accumulation of memory while running GTK over
DirectFB on MontaVista linux on TI Davinci. I also observed
significant memory accumulation while running GTK-win32 on Windows XP.
But to my surprise there is no accumulation of
I also observed
significant memory accumulation while running GTK-win32 on Windows XP.
Try to reproduce with a minimal single source file program that you
can show us, then open a bug at bugzilla.gnome.org, and attach the
sample program's source file to that bug.
--tml
Hi,
I dont have any pixmaps or images in my sample application. I have
attached my program. Its a simple program having two windows. First
window has 2 buttons open and close. When open is clicked it opens
another widow which has a close button. When close button on second
window is pressed
2008/5/14 Harinandan S [EMAIL PROTECTED]:
I dont have any pixmaps or images in my sample application.
You don't directly, but the theme engine you are using might. I tried
your program under valgrind and it reports no leaks, so I imagine you
are OK. I don't have a directfb install or a windows
On Wed, May 14, 2008 at 4:46 PM, [EMAIL PROTECTED] wrote:
2008/5/14 Harinandan S [EMAIL PROTECTED]:
I dont have any pixmaps or images in my sample application.
You don't directly, but the theme engine you are using might. I tried
your program under valgrind and it reports no leaks, so I
Harinandan S wrote:
I looked at memory usage using 'top' and 'free' while running the
application and found that memory kept on increasing without decreasing when
i destroyed a window and finally application was terminated by MVL.
Meanwhile 'valgrind' is not supported on arm-linux platform so
Not sure if it will work but there is this project:
http://refdbg.sourceforge.net
Harinandan S wrote:
I looked at memory usage using 'top' and 'free' while running the
application and found that memory kept on increasing without decreasing
when i destroyed a window and finally application was
I looked at memory usage using 'top' and 'free' while running the
application and found that memory kept on increasing without decreasing when
i destroyed a window and finally application was terminated by MVL.
Meanwhile 'valgrind' is not supported on arm-linux platform so i am not
able to get
On Wed, 2008-05-07 at 19:53 +0530, Harinandan S wrote:
Hi All,
I have observed memory leak in GTK+ too. I have multiple windows
created when some buttons are pressed and destroyed later. I observed
that when i destroy a window memory allocated to it during its
creation is not freed and
Hi All,
I have observed memory leak in GTK+ too. I have multiple windows created
when some buttons are pressed and destroyed later. I observed that when i
destroy a window memory allocated to it during its creation is not freed and
memory consumed accumulates and application is killed by OS after
2008/5/2 Ionutz Borcoman [EMAIL PROTECTED]:
I'm trying to find a way to test for memory leaks in GTK+ apps. I've created
a
very simple HelloWorld app and profiled it with valgrind.
I have run valgrind as:
G_SLICE=always-malloc G_DEBUG=gc-friendly \
valgrind --tool=memcheck
On Friday 02 May 2008 11:34:29 am [EMAIL PROTECTED] wrote:
When I valgrind my app and check for leaks, I let it run for a while
before quitting, then check the output for repeated allocations. If I
see the same thing being allocated several times and not freed I know
I probably have a leak.
Hi,
Please have a look at my post Glib hashtable memory leak and let me know
if the recipe given there works for you as well.
Regards,
Ovidiu
On Fri, May 2, 2008 at 11:53 AM, Ionutz Borcoman [EMAIL PROTECTED] wrote:
On Friday 02 May 2008 11:34:29 am [EMAIL PROTECTED] wrote:
When I valgrind
Hi,
Thanx for the reply, but I fail to see what exactly you propose I do.
I've used the same valgrind flags as you've used from the beginning, still
there were memory leaks reported.
I've also tried mtrace and it gives tons of leaks (as you also said, mtrace is
not a solution).
Gtk
On Friday 02 May 2008 2:18:14 pm [EMAIL PROTECTED] wrote:
A useful trick is to run a gtk 'hello world' program under valgrind
with the --gen-suppressions flag. Assuming you don't have any leaks in
your gtk hello-world program (!!), the generated suppressions file
will then make valgrind remove
On Friday 02 May 2008 2:18:04 pm Ovidiu Gheorghies wrote:
Hi,
Could you post the full output of the following (use the -g flag when
compiling):
export MALLOC_TRACE=0.mtrace.log
export G_SLICE=always-malloc
export G_DEBUG=gc-friendly
gcc -g [more-compilation-options] helloworld.c -o
20 matches
Mail list logo
