Re: Memory leaks
> 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 can run on are pretty modern nowadays). But as someone we all know once said "premature optimization is the root of all evil". Those cases are definitely exceptions. Optimizing cleanup routines is definitely something I don't hear about much. > So, I agree it's a good idea to do (and as I mentioned, I've done it > myself in the past) but it's for sure not a case of adding one simple > line of O(1) code... I'm not sure about malloc()/free() implementations but I'm pretty sure they can use a (partial) lookup table bringing the complexity quite close to O(1). I would be appalled if I found modern implementations to be subpar. But, as I've said above, one should only consider looking at this from the efficiency point of view when you pin-point that part of the program as wasting too many cycles, especially compared to other parts of the program (how much does gtk_init() take, is that any kind of problem and could gtk_cleanup() take longer?). ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
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 end up in the codebase it's value > would be greater than the code bloat it would produce. A lot of people > are using GTK and some definitely want it. I'd like to add my support to that statement though arguably, it's of greater importance in gtkmm. There's a common assumption with object oriented code that it should clean up after itself, which is of course the assumption I'd made (wrongly, as it now seems) in my original example. Remember that it was gtkmm code in my example, not straight gtk+. That's why I assumed there shouldn't be so many leaks being reported. I can't agree with this though:- On 10 Feb 2011, at 00:43, Michael Torrie wrote: > The issue is whether a library intended for one-time loading should clean up > after > itself. Whether we're talking 64 KB or 4 GB, cleaning up every one-time > allocation is still a waste of time. Not really. *Something* needs to perform the cleanup operation so if the app did it on shutdown, the OS (presumably) would take correspondingly fewer cycles to unload the app. And remember, we're talking about OPTIONAL functionality here. NOT offering the option results in a far greater waste of programmer time. Remember this comment from a user of Valgrind:- 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've never used Valgrind but I can fully understand how frustrating that would be and how unproductive. Surely everybody agrees that tracking down genuine leaks in one's code is a good and desirable thing? And surely everybody agrees that having to jump through hoops like that in order to achieve it is an unproductive waste of the programmer's time? Full marks to Valgrind for providing the feature - but it shouldn't excuse sloppiness by other developers. I think there's a compelling case for some kind of optional gtk_end() or gtk_unload() type of function - especially given that gtk is now object oriented through the mechanism of gtkmm. In fact, in the case of gtkmm, Gtk::Main() could possibly just have an extra parameter to signify whether its d'tor should clean up or not. John ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
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 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. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
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 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. Why? 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. If your application had a larger heap than fit comfortably into main memory, every free() would bring in every page from disk in turn and swap out the earlier ones... and with the next free() the process would repeat... and then just a few million calls to free() could take many many minutes. But on exit() without doing a free, it's indeed O(1) because the OS just marks the pages as unused, without caring about the no-longer-relevant internal structure. These days things are much faster, but a very simple test program indicated that free() can be comparable in some cases in time overhead to malloc(). I'll attach the program; you can vary the constant N and also the amount allocated each time. Using a random amount would be a fairer simulation, and would also might make some implementations of malloc/free() run quite a bit slower. Whether it's better to add something to an API or to write a valgrind special-case file is another matter... consider code that creates a singleton factory,t hat would now have to add that factory to a linked list of items to destroy, together with (possibly new) code to destroy it... using a bit more memory, a bit more code space, more lines of code to maintain, slightly bigger API, documentation, translations... So, I agree it's a good idea to do (and as I mentioned, I've done it myself in the past) but it's for sure not a case of adding one simple line of O(1) code... Best, Liam -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
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 one. Why? Your link is simply not relevant to the discussion at hand. I thought I implied that your analogy was incorrect by stating that. I'm sorry you were not able to "make [that connection]." Your analogy is incorrect, I say. One last time for luck: Having a "gtk_cleanup()" has absolutely nothing to do with efficient use of memory. Whether gtk_cleanup() existed or not would have zero impact on the memory usage of your GTK program. Your program will still consume the same amount of RAM, allocated by one-time initializations of the library instance. Thus the argument as to whether GTK+ should be made fully reentrant is completely orthogonal to a pontification on efficient use of RAM. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
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 -- although it's slightly more awkward for GTK app developers who want to check for true leaks in our apps. If there were a gtk_cleanup() I'd probably use it, but I'm not going to fault the GTK guys for not providing such a function. I think they're doing a great job, and I'm OK with using a suppression file when I'm checking my app's memory use. Allin Cottrell ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
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 code bloat it would produce. A lot of people are using GTK and some definitely want it. Not only is it logical and pretty, it would help people as noted above. More clearly, I argue that if gtk_cleanup() existed in the codebase there would be no rationale to remove it. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
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. 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 one. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
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 case though.
On 9 February 2011 16:50, Michael Torrie wrote:
> 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 memory usage grows then GTK leaks. If it doesn't, there is no leak.
> ___
> gtk-app-devel-list mailing list
> gtk-app-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
>
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
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 memory usage grows then GTK leaks. If it doesn't, there is no leak.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
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 we're talking 64 KB or 4 GB, cleaning up every one-time allocation is still a waste of time. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
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-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
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
Re: Memory leaks
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 any good it will do the job just as efficiently or better. Allin Cottrell ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
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+ "leaks" (by your definition) or not, your program, while running, is still going to need the same amount of RAM whether it cleans up initial allocations on program end or not. So except in the case where you want to continually load and unload GTK+'s shared libraries, deleting these initializations on exit is a waste of time. And GTK+ is not designed to be unloaded (I don't know of very many UI libraries that are), I don't see what the problem is. Whether you have a very small amount of RAM or a lot does not matter in the least. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
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 your memory use isn't growing without bound over time then it's not leaking. Whether GTK+ frees it's own allocations or not, your program's memory use is going to be the same. > Works for me, but I rely on minimal third party software and compile > everything with debug enabled. Dont see any sign of leakage problems in > GTK, but I dont claim to use all its features; only the ones I need for > my GUI code. > > From time to time I use valgrind to check for leaks with GTK2+ programs > written in C and it is clear that there are no leaks. Have not tried > GTK3. Have not tried the C++ wrappers. I would bet that Qt "leaks" in a similar manner to GTK+. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
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 that tells you > something), but aside from that it's a pure waste of CPU cycles. 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. Jeff -- web: http://www.chaosphere.com Author of Genesys, a Free Universal Paper and Pencil RPG. http://www.chaosphere.com/genesys/ ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
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
Re: Memory leaks
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 Allin's argument here, if you still have access to the pointer is not a leak, I just don't agree with the "pure waste of CPU cycles" argument... But to go back to some of the earlier suggestions, maybe it would be beneficial to have some kind of unload() / finish() / cleanup() functionality that could be invoked by users who need it. That's what seems to be missing at present. You mean a OPTIONAL gtk_end () function, that could be added in the end, at the programmers's will, after a gtk_main (), to clean everything before going back to the OS? gtk_main (); gtk_end (); I completely agree. Being optional, I suppose both sides would be happy... Carlos John ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
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 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! ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list 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. Works for me, but I rely on minimal third party software and compile everything with debug enabled. Dont see any sign of leakage problems in GTK, but I dont claim to use all its features; only the ones I need for my GUI code. From time to time I use valgrind to check for leaks with GTK2+ programs written in C and it is clear that there are no leaks. Have not tried GTK3. Have not tried the C++ wrappers. Dont use an IDE. Maybe the problems you have are outside GTK. Rgds Bill C ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
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 just a question of plain laziness and bad programming > practises. The second case is much worse, it means the code is badly designed. > 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. But to go back to some of the earlier suggestions, maybe it would be beneficial to have some kind of unload() / finish() / cleanup() functionality that could be invoked by users who need it. That's what seems to be missing at present. John ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
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 practises. The second case is much worse, it means the code is badly designed. Carlos ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
> 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/listinfo/gtk-app-devel-list
Re: Memory leaks
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 to > > it, it ain't a leak, even if a dumb debugger says so. > > > But my original example looked like this:- > > Gtk::Main *app = new Gtk::Main (&argc, &argv); > > delete app; > > How could there possibly be valid pointers still lurking after > those operations? Sure, there'll be pointers and they'll be > pointing to some memory - but neither of them is valid any more. You initialized the GTK library stack. That involves lots of allocations that have nothing specifically to do with your program. The pointers are maintained at the level of the library code, not your app. 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 that tells you something), but aside from that it's a pure waste of CPU cycles. Allin Cottrell ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
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. > But my original example looked like this:- Gtk::Main *app = new Gtk::Main (&argc, &argv); delete app; How could there possibly be valid pointers still lurking after those operations? Sure, there'll be pointers and they'll be pointing to some memory - but neither of them is valid any more. I think what Tor meant (and this does admittedly have some validity) was that the un-released memory will eventually (in fact, soon) be released by the operating system anyway, so what purpose does it serve to release it specifically? My argument against that was that it makes it a lot easier for a leak detecting utility to do its job properly. But quite apart from that, there's bound to be a suspicion about whether the true reason for not fixing such leaks is really one of scale. Remember that just that one gtkmm call left me with literally hundreds of leaks. Supposing there'd only been six leaks. Would that have imbued more motivation to plug them? I suspect the answer is "yes". John ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtk 2.16.6 for win32 on gnome.org
On Wed, 9 Feb 2011, Tor Lillqvist wrote: > > Am I right in > > thinking that the "engines" that used to live in separate dlls > > (libpixmap and libwimp) are now folded into one of the main dlls > > -- presumably libgtk-win32-2.0-0.dll? > > No, that would not work (without changes to the engine-loading code to > look for built-in engines). They are where they should be, in > lib/gtk-2.0/2.10.0/engines . Sorry for the noise -- for some reason I didn't see them at first. Allin Cottrell ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtk 2.16.6 for win32 on gnome.org
> Am I right in > thinking that the "engines" that used to live in separate dlls > (libpixmap and libwimp) are now folded into one of the main dlls > -- presumably libgtk-win32-2.0-0.dll? No, that would not work (without changes to the engine-loading code to look for built-in engines). They are where they should be, in lib/gtk-2.0/2.10.0/engines . --tml ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
gtk 2.16.6 for win32 on gnome.org
Quick question on the current build of GTK 2.16.6 for win32 on gnome.org, that is, gtk+_2.16.6-3_win32.zip. Am I right in thinking that the "engines" that used to live in separate dlls (libpixmap and libwimp) are now folded into one of the main dlls -- presumably libgtk-win32-2.0-0.dll? Thanks. -- Allin Cottrell Department of Economics Wake Forest University ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
On Wed, 9 Feb 2011, Carlos Pereira wrote: > >P.S I will say though that in all my life I don't think I've ever written a > >program>where it was either impractical (or too difficult) to fix its leaks. > > IMHO ignoring>leaks is a bad habit to get into and one whose consequences > >usually get worse over time. > > I could not agree more with this. It seems obvious to me that the GTK > team should write code without mem leaks. It's a sad day we even need to > argue this. There is no such a thing as good and bad mem leaks, in the > 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 it, it ain't a leak, even if a dumb debugger says so. Allin Cottrell ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
P.S I will say though that in all my life I don't think I've ever written a program>where it was either impractical (or too difficult) to fix its leaks. IMHO ignoring>leaks is a bad habit to get into and one whose consequences usually get worse over time. I could not agree more with this. It seems obvious to me that the GTK team should write code without mem leaks. It's a sad day we even need to argue this. There is no such a thing as good and bad mem leaks, in the long-term they are all plain wrong and promoting buggy code. Carlos On 02/09/11 17:27, 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 think I'd agree with you if I'd ever used Valgrind but at least having the option of a suppressions file is better than not having it (as seems to be the case with VC++). It's a double edged sword of course because there's a danger that Valgrind's ability to work with a suppressions file might 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 say though that in all my life I don't think I've ever written a program where it was either impractical (or too difficult) to fix its leaks. IMHO ignoring leaks is a bad habit to get into and one whose consequences usually get worse over time. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Problems with drag and drop on Windows
Hi all, I'm using Gtk-2.22.0 and I have a problem using drag and drop on a GtkTreeView on Windows. I'd like to have a drag and drop functionality to move an item in the GtkTreeView from a top level position to a folder contained in the same treeView. My code is the following, and this code was functioning until I converted my project using GtkBuilder and Gtk 2.22.0 = gtk_tree_view_enable_model_drag_source(treeView, GDK_BUTTON1_MASK, targetentries, n_targets, (GdkDragAction) GDK_ACTION_MOVE); gtk_tree_view_enable_model_drag_dest(treeView, targetentries, n_targets, (GdkDragAction) GDK_ACTION_MOVE); g_signal_connect((GtkWidget*) treeView, "drag-data-received", G_CALLBACK (drag_data_received), this); = The only aim of this 3 line code is to call the drag_data_received callback, that will do all the changes in the tree. The callback on Windows systems is not more called, instead it continues to be called on Linux. It seems to me that is the API gtk_tree_view_enable_model_drag_dest that doesn't work right, but I'm not sure about this. Can anyone help me ? Thanks a lot. Paolo Le informazioni trasmesse possono contenere documenti confidenziali e/o materiale riservato; sono quindi da intendersi esclusivamente ad uso della persona e/o società a cui sono indirizzate. Qualsiasi modifica, inoltro, diffusione o altro utilizzo, relativo alle informazioni trasmesse, da parte di persone e/o società diversi dai destinatari indicati, è proibito ai sensi della legge 196/2003. Qualora questa mail fosse stata ricevuta per errore, si prega di contattare il mittente e cancellarne il contenuto. -- Privileged/Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer does not consent to Internet email for messages of this kind. Opinions, conclusions and other information in this message that do not relate to the official business of my firm shall be understood as neither given nor endorsed by it. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
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 think I'd agree with you if I'd ever used Valgrind but at least having the option of a suppressions file is better than not having it (as seems to be the case with VC++). It's a double edged sword of course because there's a danger that Valgrind's ability to work with a suppressions file might 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 say though that in all my life I don't think I've ever written a program where it was either impractical (or too difficult) to fix its leaks. IMHO ignoring leaks is a bad habit to get into and one whose consequences usually get worse over time. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
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.gnome.org/Valgrind 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 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! ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
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 ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
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 trying to debug in the first place is. Valgrind can generate suppressions, did you know? Anyway, if you can write your complete program in a few minutes then either you can code extermely fast compared to mere mortals such as me or the program is so simple that its correctness can be immediately verified by looking at the source code. The number of required suppressions varies between something like five to a couple of dozens, depending on the parts of Gtk+ and GLib used. Yeti ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
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 for GTK/GLIB. And creating a suppressions file is more work than actually writing the code of the program I'm trying to debug in the first place is. james. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
On 9 Feb 2011, at 11:13, Tor Lillqvist wrote: >> 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 not been released is a > "leak"? > In your program, you don't normally call _CrtDumpMemoryLeaks() at all (although it's available if you want to do so). Normally though, you leave this to the debugger which calls it when your program closes. In that way, it lists all the memory that got allocated (by the program) but not released (by the program). > Does it make sense for a library to spend significant amount of time > (potentially paging in pages that have otherwise 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 right tool there is no problem at all in finding such "true" > leaks. On Windows, I guess it could be Purify? > It's certainly worth trying but in my experience, third party analysis tools are rarely better than those built into my IDE (even though they might be more extensive). If there's an evaluation version though, I'll give it a try and see how it performs. Thanks for the suggestion. John ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
On Wed, Feb 9, 2011 at 12:54, John Emmas wrote: > > On 9 Feb 2011, at 08:44, Tor Lillqvist wrote: > >> A *true* leak, in my opinion, is if performing some code sequence over >> and over again (like what happens if you just do the same UI actions >> repeatedly) causes 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() results in 16 memory leaks but > when I re-tested it after reading your comment, I realised that 2 calls still > only produce 16 leaks. So by your definition Tor, g_warning() doesn't count > as code that leaks memory. I would say that it does leak memory because the > leak can happen anywhere in my program and won't happen at all a g_warning() > never gets issued. When it does leak though, it won't necessarily be > associated with the program being initialised so in my view, g_warning() is > definitely an example of leaking code. No, it just delayed initialization of the logging subsystem. -- Andrew W. Nosenko ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
> 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 not been released is a "leak"? Does it make sense for a library to spend significant amount of time (potentially paging in pages that have otherwise 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 as soon as the process finally gets to actually exiting, which it would have already, hadn't the library been spendign time trawling its data structures in order to "free" memory? > This creates a problem, inasmuch as if memory is leaking according to your >definition Tor, it's almost impossible to > find the leak among all the other leaks that wouldn't be classed as leaks by > your definition. With the right tool there is no problem at all in finding such "true" leaks. On Windows, I guess it could be Purify? --tml ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: EXTERNAL: Re: Memory leaks
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 http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
On 9 Feb 2011, at 08:44, Tor Lillqvist wrote: > A *true* leak, in my opinion, is if performing some code sequence over > and over again (like what happens if you just do the same UI actions > repeatedly) causes 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() results in 16 memory leaks but when I re-tested it after reading your comment, I realised that 2 calls still only produce 16 leaks. So by your definition Tor, g_warning() doesn't count as code that leaks memory. I would say that it does leak memory because the leak can happen anywhere in my program and won't happen at all a g_warning() never gets issued. When it does leak though, it won't necessarily be associated with the program being initialised so in my view, g_warning() is definitely an example of leaking code. > Can Visual Studio detect such leaks? Do you see any of > them? > Well, that's where things get difficult. AFAIK you can't tell Visual C++ to report some leaks but ignore others. Each time you call _CrtDumpMemoryLeaks() it dumps all the memory that's been allocated but not yet released. This creates a problem, inasmuch as if memory is leaking according to your definition Tor, it's almost impossible to find the leak among all the other leaks that wouldn't be classed as leaks by your definition. If 500 leaks are being reported, I've no easy way of finding the one leak that you'd describe as genuine. Maybe other leak detectors are more flexible? It would be interesting to find out. I've asked a few other devs if they can suggest a way for VC to ignore certain leaks so I'll let you know if I find anything.. > And anyway, this "OMG GTK+ leaks memory" discussion has been had > several times already over the years. This parrot is dead. > Well that's the reason I asked. I didn't want to waste my time tracking down these leaks if no-one else was bothered about them. However, it's good to see a couple of other people who can appreciate the value off nailing these leaks! If nothing else, they clearly make leak detection a very difficult task. Just my 2 cents. John ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
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 load dynamically, use a bit, and then > unload, and expect to free all their allocations upon unloading. > IMO there is a use-case for this (or at least a gtk_fini ();) especially in applications where the UI elements are controlled by loadable modules. Not unloading like this is extremely dangerous when those allocated objects and slots go stale and the application might try to re-load the module which initializes gtk again Kind Regards, Sam > A *true* leak, in my opinion, is if performing some code sequence over > and over again (like what happens if you just do the same UI actions > repeatedly) causes the amount of unreachable memory to grow > continuously. Can Visual Studio detect such leaks? Do you see any of > them? > > And anyway, this "OMG GTK+ leaks memory" discussion has been had > several times already over the years. This parrot is dead. > > --tml > ___ > gtk-app-devel-list mailing list > gtk-app-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list > -- Sam Spilsbury ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
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 -
not for normal use, because with modules etc there are too many
resurrection corner cases - but as a last call before exit() when
testing to make valgrind's life a little easier.
{shrug}
AfC
Sydney
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
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 free all their allocations upon unloading. A *true* leak, in my opinion, is if performing some code sequence over and over again (like what happens if you just do the same UI actions repeatedly) causes the amount of unreachable memory to grow continuously. Can Visual Studio detect such leaks? Do you see any of them? And anyway, this "OMG GTK+ leaks memory" discussion has been had several times already over the years. This parrot is dead. --tml ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
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, while I was
sipping my first coffee and still trying to wake up! During gtk_init() I
discovered a couple of places where g_strdup() gets used but the allocated
memory never gets freed. For example in gdk/gdkinternals.h, the memory
allocated to the variable '_gdk_display_arg_name' never gets properly freed (it
gets freed if it needs to get reallocated but otherwise, it just leaks). I
also discovered (although it wasn't relevant to my original post) that simply
calling g_warning() results in about 15 memory leaks, although I didn't have
enough time to find any of them.
I don't know what to do about this. I remember from about a year ago that a
guy was offering to track down memory leaks and if I could find some spare time
over the next few months I'd be happy to assist in finding them, a few at a
time if it would help - but even just that one line of code produces many
hundreds of leaks, so I don't want to be wasting my time if they're just an
inevitable part of the way gtk+ is structured. This seems like one of those
tasks that could soon turn into a can of worms!!
John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
