The following code spawns a window --
if (connect_build_object != NULL) {
g_object_unref (G_OBJECT ( connect_build_object ));
object = NULL;
}
connect_build_object = gtk_builder_new();
gtk_builder_add_from_file ( connect_build_object,
main_window.glade, NULL );
On 05/09/2011 01:36 PM, Gabriele Greco wrote:
just a note on your example code: use the GPOINTER_TO_INT and
GINT_TO_POINTER macro's to avoid 64bit portability problems:
gboolean mycbk(gpointer data)
{
gint val = GPOINTER_TO_INT(data);
char buffer[16];
sprintf(buffer, %09d,
If I use g_idle_add to send to my main thread that does the GTK rendering
some notifications I have to free the source handle that the function
returns to me every time or not to avoid a memory leak?
Here is a simple code example, that seems not to leak on linux (ps gives
constant resource
FWIW I tracked sown the mechanism for suppressing leak detections in MSVC.
Basically, you can set checkpoints and only display the leaks between two
specified points. It might not be as flexible as the method used in Valgrind
but it's one helluva lot easier. Here's how I modified my original
On 13/02/11 04:43, John Emmas wrote:
FWIW I tracked sown the mechanism for suppressing leak detections in MSVC.
Basically, you can set checkpoints and only display the leaks between two
specified points. It might not be as flexible as the method used in Valgrind
but it's one helluva lot
I posted this the last time this subject came up (twice last year, I
think), but I made this valgrind suppression file for my project:
http://www.vips.ecs.soton.ac.uk/development/nip2.supp
With this, I get no reported leaks in my huge (200,000 lines of C)
application on Ubuntu with current
Because malloc() implementations generally kept a linear linked list of
free space, and traversed the list on a free() in case they found
adjacent memory areas to the one you were freeing, which they could join
together and make into a single larger area.
I'm sorry, I now understand what you
Hi All
On 10/02/11 18:26, John Emmas wrote:
On 9 Feb 2011, at 17:01, James Morris wrote:
Not only do we have to write our own code, we have to put work into
making other peoples code ignore the errors in other peoples code so
we can see the errors in our own code. It's a bloody outrage!
From: Carlos Pereira [jose.carlos.pere...@ist.utl.pt], Date: 10/02/2011 09:10:
something), but aside from that it's a pure waste of CPU cycles.
I am sorry, I totally disagree.
I can only see two cases. Either fixing these hundreds and hundreds of
mem leaks is easy or difficult.
In the first
The basic idea that one must understand about programming is that of
paradigms and concepts. They are really stressed for C++ and higher
level stuff (scripting languages notwithstanding ofcourse). But if
you're gonna use C you're gonna write paradigms and concepts that
you'll really have to be
On 10/02/11 19:50, Costin Chirvasuta wrote:
I'm sorry, I now understand what you mean. If what you say is true
(which I don't doubt) it's a really boneheaded mechanism in my
opinion. Defragmenting memory in realtime is a performance nightmare.
But that's irrelevant. Your point is well taken.
+. However, I've
come to realise that the rewards of working with gtk+ are well worth
persevering with the steep (and sometimes not very intuitive) learning curve.
I'd have to say though that the difficulty of tracking my memory leaks is the
first thing that's seriously made me question my move
To describe the standard mechanism of garbage collection as a boneheaded
idea shows a total lack of awareness of first year Computer Science course
principles. That garbage collection has been refined and highly optimised
over the years is true; however it is a very necessary thing with
On 02/10/2011 12:19 AM, Costin Chirvasuta wrote:
I find not cleaning up explicitly quite ugly. I shudder at the thought
and maybe I'm not the only one. Not only that, but cleaning up
explicitly is obviously useful for some people.
I guess we're at an impasse then. The discussion has now moved
On 10 Feb 2011, at 17:48, Michael Torrie wrote:
I guess we're at an impasse then. The discussion has now moved from the
definition of leak to some personal idea of what beauty is.
In which case, maybe we should agree to use the word leak for the simple
purpose of identifying the
On Thu, Feb 10, 2011 at 07:28:40PM +, John Emmas wrote:
To me, the debate has become something very simple when a program
needs to allocate a block of memory only once, does the programmer
necessarily have to release it programmatically or can he defer it to
the OS? Remember we
On Thu, 2011-02-10 at 10:50 +0200, Costin Chirvasuta wrote:
Because malloc() implementations generally kept a linear linked list of
free space, and traversed the list on a free() in case they found
adjacent memory areas to the one you were freeing, which they could join
together and make
On 11/02/11 09:13, David Nečas wrote:
While I agree having a clean-up function could be useful in some cases
(dynamical modules with GUI) this ‘widespread expectation in C++’ stuff
is just rubbish.
Yeti
___
gtk-app-devel-list mailing list
On 10 Feb 2011, at 22:13, David Nečas wrote:
And others, Gtk+ devs probably including, consider this a useful
optimisation – and in many cases a necessity. You still do not seem to
accept even the existence of this point of view.
I would say quite the reverse. Every single person here
On 8 Feb 2011, at 09:36, John Emmas wrote:
int main (int argc, char *argv[])
{
Gtk::Main *app = new Gtk::Main (argc, argv);
delete app;
return 0;
}
The above code causes hundreds of memory leaks.
I spent a few minutes on this (literally just a few) this morning
It's just a question of definition. Many people, me included, don't
consider once-only allocations of memory that stays accessible and
aren't freed before the program exits leaks. GTK+ and GLib isn't the
kind of libraries that you could load dynamically, use a bit, and then
unload, and expect to
On Wed, 2011-02-09 at 10:44 +0200, Tor Lillqvist wrote:
And anyway, this OMG GTK+ leaks memory discussion has been had
several times already over the years. This parrot is dead.
True.
But it is a shame that there isn't a
gtk_unload_no_I_mean_really_unload_honest() function that we could use -
On Wed, Feb 9, 2011 at 4:44 PM, Tor Lillqvist t...@iki.fi wrote:
It's just a question of definition. Many people, me included, don't
consider once-only allocations of memory that stays accessible and
aren't freed before the program exits leaks. GTK+ and GLib isn't the
kind of libraries that
and I could (almost) agree with it if we were
referring specifically to program initialisation - but let me cite my earlier
example of g_warning(). A call to g_warning() results in 16 memory leaks but
when I re-tested it after reading your comment, I realised that 2 calls still
only produce 16
On 2/9/2011 3:44 AM, Tor Lillqvist wrote:
several times already over the years. This parrot is dead.
No he isn't, he's pining for the fjords...
Sorry, couldn't resist
Damon Register
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
Each time you call _CrtDumpMemoryLeaks() it dumps all the memory that's been
allocated but not yet released.
So it doesn't take into consideration at all whether the memory in
question is / can be used or not, i.e. whether there is any pointer to
it in local variables, etc. All memory that has
of unreachable memory to grow
continuously.
It's an interesting argument and I could (almost) agree with it if we were
referring specifically to program initialisation - but let me cite my earlier
example of g_warning(). A call to g_warning() results in 16 memory leaks but
when I re-tested
to free memory, that
will be truly freed by the OS anyway
If there's a benefit, yes. In this case the benefit is that it would make it
easier to find genuine memory leaks.
With the right tool there is no problem at all in finding such true
leaks. On Windows, I guess it could be Purify?
It's
On 9 February 2011 11:13, Tor Lillqvist t...@iki.fi wrote:
With the right tool there is no problem at all in finding such true
leaks.
How does one gain this mysterious tool for Linux?
I have used Valgrind but as mentioned by numerous souls at numerous
times in the past, a suppressions file is
On Wed, Feb 09, 2011 at 04:02:01PM +, James Morris wrote:
I have used Valgrind but as mentioned by numerous souls at numerous
times in the past, a suppressions file is needed for GTK/GLIB. And
creating a suppressions file is more work than actually writing the
code of the program I'm
James Morris wrote:
How does one gain this mysterious tool for Linux?
It's called Google. There's a web page[1] that details how to setup
valgrind to debug gtk/glib apps and even a preliminary suppression file.
[1] http://live.gnome.org/Valgrind
On 9 February 2011 16:10, Michael Cronenworth m...@cchtml.com wrote:
James Morris wrote:
How does one gain this mysterious tool for Linux?
It's called Google. There's a web page[1] that details how to setup valgrind
to debug gtk/glib apps and even a preliminary suppression file.
[1]
blanche for them to delay fixing their memory leaks
or even not to bother fixing them at all, or (as we have here) to reclassify
them as not being genuine leaks.
Which brings us neatly back to where we all started off.
John
P.S I will say though that in all my life I don't think I've ever
for
them to delay fixing their memory leaks or even not to bother fixing them at all, or (as
we have here) to reclassify them as not being genuine leaks.
Which brings us neatly back to where we all started off.
John
P.S I will say though that in all my life I don't think I've ever written
missing Tor's point. Yes, all memory leaks are bad, but
most (all?) of the instances of not-explicitly-released memory
in the GTK stack are _not_ leaks. If you still have a pointer to
it, it ain't a leak, even if a dumb debugger says so.
Allin Cottrell
On 9 Feb 2011, at 20:06, Allin Cottrell wrote:
You're missing Tor's point. Yes, all memory leaks are bad, but
most (all?) of the instances of not-explicitly-released memory
in the GTK stack are _not_ leaks. If you still have a pointer to
it, it ain't a leak, even if a dumb debugger says so
On Wed, 9 Feb 2011, John Emmas wrote:
On 9 Feb 2011, at 20:06, Allin Cottrell wrote:
You're missing Tor's point. Yes, all memory leaks are bad, but
most (all?) of the instances of not-explicitly-released memory
in the GTK stack are _not_ leaks. If you still have a pointer
but aside from that it's a pure waste of CPU cycles.
I hate to throw fuel in the fire but this is just absurd!
How complex is freeing 200 pointers? O(1)?
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
something), but aside from that it's a pure waste of CPU cycles.
Dear Allin,
I am sorry, I totally disagree.
I can only see two cases. Either fixing these hundreds and hundreds of
mem leaks is easy or difficult.
In the first case, is just a question of plain laziness and bad
programming
On 9 Feb 2011, at 23:41, Carlos Pereira wrote:
something), but aside from that it's a pure waste of CPU cycles.
Dear Allin,
I am sorry, I totally disagree.
I can only see two cases. Either fixing these hundreds and hundreds of mem
leaks is easy or difficult.
In the first case, is
On 10/02/11 04:01, James Morris wrote:
On 9 February 2011 16:10, Michael Cronenworthm...@cchtml.com wrote:
That's called patronising. I have been there already. What good is a
work in progress when the progress stopped over two years ago?
Not only do we have to write our own code, we have to
I think Allin's point is that even though I deleted the object in my example
app, the gtk shared library code is still technically available to be used by
some other part of my program (without needing to be re-initialized). In my
example, I just happened to not use it.
Yes, I accept
There is already gtk_init(). It's only logical it should have a counterpart.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
On Wed, 2011-02-09 at 17:22 -0500, Allin Cottrell wrote:
I'm afraid you're talking through your hat here. Have your ever
worked through the code for even a simple shared library that
saves state? Freeing all memory on exit can be useful as a
debugging exercise (e.g. if you get a segfault
On 02/09/2011 04:39 PM, Bill C wrote:
My experience with valgrind and GTK is that it is easy to fix leaks.
Simply look for leaked memory that you allocated. Then determine where
you should have released it. If it was not allocated by you its not
your problem so ignore it.
Right. And if
On 02/09/2011 05:05 PM, Jeff Clough wrote:
And the fact that so many shared library hackers have this view is the
reason modern desktops need to ship with four gigs of RAM minimum and
still can't stay up for more than a week.
Rubbish. What an absurd and fallacious argument. Whether GTK+
On Wed, 9 Feb 2011, Carlos Pereira wrote:
something), but aside from that it's a pure waste of CPU cycles.
Dear Allin,
I am sorry, I totally disagree.
I can only see two cases. Either fixing these hundreds and hundreds of
mem leaks is easy or difficult.
Easy or difficult, if the OS is
How times have changed:
http://www.folklore.org/StoryView.py?story=Were_Not_Hackers!.txt
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Some people really don't get this but it's a fact that people like to
work with a Bill Atkinson. Not so much with hackers (if you read the
above link).
Childish? Maybe. Just hope some people get my point.
___
gtk-app-devel-list mailing list
On 02/09/2011 05:34 PM, Costin Chirvasuta wrote:
How times have changed:
http://www.folklore.org/StoryView.py?story=Were_Not_Hackers!.txt
Nothing to do with the issue at hand. Nothing at all. The issue is
whether a library intended for one-time loading should clean up after
itself. Whether
I think it's worth pointing out that these normally harmless leaks would
become a problem if gtk was repeatedly loaded and unloaded with
dlopen()+dlclose(). Each dlopen() results in a fresh state, so Gtk would
allocate new instances of these global structures each time.
Not exactly a prominent
So it's better to use suppresion with Valgrind then to add a
gtk_cleanup() counterpart to gtk_init()?
It's better to print something to the display and then put electrical
tape over it?
Tip: (regarding whether or not that link is relevant) Intelligence
means analogy. Being able to make
I'm not saying this is really important and it should be done soon.
I'm merely stating that the value of having gtk_cleanup() would be
greater than zero. That is, regardless of how much trouble it would be
for someone to write, if it would end up in the codebase it's value
would be greater than
On Thu, 10 Feb 2011, Costin Chirvasuta wrote:
So it's better to use suppresion with Valgrind then to add a
gtk_cleanup() counterpart to gtk_init()?
That's debatable, of course, but Yes, it's more efficient for the
ordinary use case of the GTK stack -- let the OS reclaim memory on
exit --
On 02/09/2011 06:08 PM, Costin Chirvasuta wrote:
Tip: (regarding whether or not that link is relevant) Intelligence
means analogy. Being able to make connections. If you understood my
meaning and thought it wrong you should have said You analogy is
incorrect. Not point out that you didn't find
On Thu, 2011-02-10 at 00:43 +0200, Costin Chirvasuta wrote:
but aside from that it's a pure waste of CPU cycles.
I hate to throw fuel in the fire but this is just absurd!
How complex is freeing 200 pointers? O(1)?
Years ago my text retrieval package had an option to call free() for all
the
My analogy had nothing to do with memory use. It had something to do
with code beauty which was all that Bill Atkinson was about. It was
all that article was about. You got it exactly the other way around.
Efficient use of memory at the expense of ugliness was the thing to
avoid in that article.
On 10 Feb 2011, at 01:19, Costin Chirvasuta wrote:
I'm not saying this is really important and it should be done soon.
I'm merely stating that the value of having gtk_cleanup() would be
greater than zero. That is, regardless of how much trouble it would be
for someone to write, if it would
Hello,
I have tested Deleaker tool (www.deleaker.com) for my application and I have
seen some problems with Gdi objects and user objects.
My actual version of GTK is gtk+-bundle_2.16.0-20090317_win32.
Gdi objects :
0x97011704 (Device context)
GDI32.dll!CreateDCA
Please file a bug report at bugzilla.gnome.org and attach a *minimal*
and *complete* sample program (as a single source file, in C or
Python) that reproduces the leak. (I.e., a program which shows a
continuously growing amount of GDI resources consumed without any
clear reason.)
--tml
Ok, I am sorry.
I report the bug as soon as possible.
Cyril
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Hi,
I am working on a gtk application which when used continuously exhibits
memory leak. I have verified this by top output which shows continuous
increase in memory used by it. After analysing the problem with
valgrind, memprof and mpatrol, a couple of observations have been made:
1- program
I tried it with the debug info packages and malloc, and now there are
only a few X/gtk errors. Anyone have suggestions on how to approach
those? Maybe someone on the gtk-app-devel-list?
Thanks,
David
Julian Seward wrote:
Maybe you should set G_SLICE=always-malloc in the environment in
Hello,
Could anyone offer help or advice on debugging mysterious gtk-related memory
leaks and errors reported by valgrind when checking a threaded GTK+
program? The primary potential leak seems to be a sizeable chunk in
g_thread_init, and there are quite a few errors from various unknown
contexts
On Sun, 2006-08-20 at 05:48 -0400, David Ellis wrote:
Hello,
Could anyone offer help or advice on debugging mysterious gtk-related memory
leaks and errors reported by valgrind when checking a threaded GTK+
program? The primary potential leak seems to be a sizeable chunk in
g_thread_init
Maybe you should set G_SLICE=always-malloc in the environment in order
to make valgrind more useful:
http://developer.gnome.org/doc/API/2.0/glib/glib-running.html
I agree; from a guess I'd say that glib is using a private allocator,
which confuses the issue.
Unrelatedly ..
It looks like
Valgrind http://valgrind.org
On 1/18/06, Juan Pablo [EMAIL PROTECTED] wrote:
Hi list!
I've made some progress on my program and now i would like to check for
memory leaks.
Do you recommend any way or program in special for doing this?
Thanks all.
Saludos, Juan Pablo
I've made some progress on my program and now i would like to check
formemory leaks. Do you recommend any way or program in special for
doing this?
Something I've sometimes found useful, was to write a little chunk of code that
throws up a small window that holds a list view, into which I
68 matches
Mail list logo
