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 );
gtk_builder
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 occup
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 easi
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
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 gtk+.
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 h
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
gtk-app-dev
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
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 ar
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 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 mov
> 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 m
ns claim to have mastered gtk+. 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 t
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.
T
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 ensu
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
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!
I'v
> 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 y
> Years ago my text retrieval package had an option to call free() for all
> the data structures on exit, basically just for debugging. It made the
> programs often go really slow when they exited - adding tens of seconds
> wasn't uncommon.
Maybe there are corner cases (although the platforms GTK
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 woul
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.
I
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
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
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 -- alth
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 the
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 connections
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 use
On 02/09/2011 02:29 PM, John Emmas wrote:
> But my original example looked like this:-
>
>
> Gtk::Main *app = new Gtk::Main (&argc, &argv);
>
> delete app;
Change it to this and then look at memory use:
for (;;) {
Gtk::Main *app = new Gtk::Main (&argc, &argv);
delete app;
}
If
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
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
gtk-app-devel
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
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
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+ "l
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. An
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
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
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 All
On 10/02/11 04:01, James Morris wrote:
On 9 February 2011 16:10, Michael Cronenworth 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 put work into
mak
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
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
> 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
http://mail.gnome.org/mailman/lis
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_ lea
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, e
long-term they are all plain wrong and promoting buggy code.
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
be seen by those other programmers as carte 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 s
en by those
other programmers as carte 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 t
On 9 February 2011 16:10, Michael Cronenworth 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] http://live.
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 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 tr
On 9 February 2011 11:13, Tor Lillqvist 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 needed
therwise been stale for ages)
> when the using process is about to exit, just 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
s the amount 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() result
> 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 ha
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
htt
x27;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 it after reading your comment, I realised that 2 calls
On Wed, Feb 9, 2011 at 4:44 PM, Tor Lillqvist 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 you could
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
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 fr
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
situation down to the following
minimal code sample:-
#include
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'd be happy to try and trace
them but I
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
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
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
libgdk-win32-2.0-0.dll!gdk_keymap
On Mon, 2007-08-06 at 12:01 +0530, Anurag Chaudhary wrote:
> Hi,
> I am using gtk+ 2.4.13.
you are using an ancient version of GTK+. please, upgrade.
> Is there any chance of any gtk api function
> creating a reference to an object which the caller has the
> responsibility to clear? If yes, is
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 hea
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 orde
> 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 l
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
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 vario
> 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
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?
>
On Wed, Jan 18, 2006 at 04:22:09PM -0300, Juan Pablo wrote:
> 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?
Valgrind (http://valgrind.org/).
Yeti
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.
___
74 matches
Mail list logo
