Re : GtkTreeView sorting triggered by cell renderer while, retaining row selection
I've already signaling the issue between selection and toggle cell : here is the answer by kris If the column is sorted, when one activates the toggle, the tree is re-sorted (normal) but the selected row is changed (unexpected). I investigated and I found that when clicking on a toggle cell renderer, the activate callback is send which update the treemodel. After re-ordering, the function gtk_tree_view_button_press is called. This function checks The function gtk_tree_view_button_press() is not called, but continued after re-ordering. The activate callback (and thus the re-ordering) are triggered from gtk_tree_view_button_press(). which row is under the cursor and selects it. I am looking for a way to trap this event to keep the selection on the activated row (like when one edits a text) Your main problem here is that the model is re-ordered before tree view will select the row under the cursor. When things change within a tree view callback, it is always a kind of a gray area. There are certain reasons why editable and activatable cell renders have to be handled before we update the cursor, so this is not something that can be easily changed. The most important difference with the case of editing text is that the model is updated (and possibly resorted) at a later point. I think your best chance is to set the cursor on the wished row manually, after the tree view has updated the cursor. From the rows-reordered callback emitted by the model set on the tree view, you can deduce how the rows are reordered. As soon as the tree view changes the cursor the cursor-changed signal is emitted on the tree view. Using these events, I think you should be able to work something out? Hope this helps. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Valgrind and GTK libraries
2010/1/1 Erik de Castro Lopo mle+...@mega-nerd.com: - How does one go about teasing out the difference between my memory leaks and GTK stuff I have no control over? Just a few thoughts Valgrind is an excellent product, and is designed for programmer use only. It shows where unreleased memory was allocated, so one can trace each chunk of memory to see if it should have been released, and take appropriate action it your code allocated it. If it was allocated elsewhere, chances are it is either correct or it is someone elses problem. Humans can make mistakes, but GTK is well tested. In my case, suspected errors in linux library code have always been errors in my own code which surface as Gnu libraries are improved. I should add that my suggested problem has always been resolved within a few hours (even at weekends) , by competent polite experts... A pleasant change from the mainstream monopoly suppliers that milk their user base 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: Valgrind and GTK libraries
On Sat, Jan 2, 2010 at 4:20 AM, jcup...@gmail.com wrote: 2010/1/1 Erik de Castro Lopo mle+...@mega-nerd.com: - How does one go about teasing out the difference between my memory leaks and GTK stuff I have no control over? I usually run my app twice: once with just startup/shutdown and once with startup/run for a while/shutdown. The diff between the two runs (with a little trimming) shows interesting memleaks. Also, with experience it becomes easy to spot the gtk things that aren't leaks. Anything related to type init is not really a leak, for example. Yeah. For comparison, you can see what suppressions are firing on Chromium's valgrind runs. See e.g. http://build.chromium.org/buildbot/waterfall/builders/Linux%20Tests%20(valgrind)(2)/builds/2588/steps/valgrind%20test:%20ui/logs/stdio which says how often the following six suppressions fire during our ui tests: 47 http://sources.redhat.com/bugzilla/show_bug.cgi?id=5171 59 glibc leak. See also http://sources.redhat.com/bugzilla/show_bug.cgi?id=2451 1176 pango_font_leak_todo 12161 Fontconfig leak? 12338 gtk developers don't like cleaning up one-time leaks. See http://mail.gnome.org/archives/gtk-devel-list/2004-April/msg00230.html 19086 dl-hack3-cond-1 Our suppressions file is at http://src.chromium.org/cgi-bin/gitweb.cgi?p=chromium.git;a=blob_plain;f=tools/valgrind/memcheck/suppressions.txt I imagine some of those would go away if we were able to update to the latest versions of things like glibc, fontconfig, gtk, and pango, but we have to live with whatever distro the test bot admins picked (which is probably hardy or something like that). - Dan ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Valgrind and GTK libraries
Bill C wrote: Valgrind is an excellent product, and is designed for programmer use only. It shows where unreleased memory was allocated, so one can trace each chunk of memory to see if it should have been released, and take appropriate action it your code allocated it. That is easy when when it obviously in client code. My particular issue is that I am absolutely sure the code I am working on (I didn't write it btw) is leaking GTK resources. Given this code leaks 2 blocks and the GTK helloworld (far, far simpler) leaks 8000, how do I know which of the 2 leaks I can fix. From this: http://www.mega-nerd.com/erikd/Blog/files/sweep-valgrind.txt.gz lets look at one specific leak record: ==12528== 27,300 bytes in 175 blocks are still reachable in loss record 11,194 of 11,196 ==12528==at 0x4024C1C: malloc (vg_replace_malloc.c:195) ==12528==by 0x4B342E3: g_malloc (gmem.c:131) ==12528==by 0x4B4A418: g_slice_alloc (gslice.c:824) ==12528==by 0x4B4A714: g_slice_alloc0 (gslice.c:833) ==12528==by 0x474F8F6: g_type_create_instance (gtype.c:1654) ==12528==by 0x4734747: g_object_constructor (gobject.c:1383) ==12528==by 0x4735707: g_object_newv (gobject.c:1171) ==12528==by 0x4736589: g_object_new_valist (gobject.c:1323) ==12528==by 0x473670D: g_object_new (gobject.c:1086) ==12528==by 0x4195924: ??? (in /usr/lib/libgtk-x11-2.0.so.0.1800.3) ==12528==by 0x4197833: ??? (in /usr/lib/libgtk-x11-2.0.so.0.1800.3) ==12528==by 0x4196787: gtk_menu_item_set_label (in /usr/lib/libgtk-x11-2.0.so.0.1800.3) ==12528==by 0x4735CE3: g_object_newv (gobject.c:968) ==12528==by 0x47365F0: g_object_new_valist (gobject.c:1364) ==12528==by 0x473670D: g_object_new (gobject.c:1086) ==12528==by 0x4197347: gtk_menu_item_new_with_label (in /usr/lib/libgtk-x11-2.0.so.0.1800.3) ==12528==by 0x808E8AA: create_proc_menu (view.c:175) ==12528==by 0x8096E2B: view_new (view.c:1167) ==12528==by 0x8097638: view_new_all (view.c:2562) ==12528==by 0x806713F: _sndfile_sample_load (file_sndfile1.c:712) ==12528==by 0x8064BAF: try_sample_load (file_dialogs.c:225) ==12528==by 0x8057FD2: initial_sample_load (main.c:73) ==12528==by 0x4B2A100: g_idle_dispatch (gmain.c:4065) ==12528==by 0x4B2BE87: g_main_context_dispatch (gmain.c:1960) ==12528==by 0x4B2F72F: g_main_context_iterate (gmain.c:2591) ==12528==by 0x4B2FB9E: g_main_loop_run (gmain.c:2799) ==12528==by 0x4185418: gtk_main (in /usr/lib/libgtk-x11-2.0.so.0.1800.3) ==12528==by 0x8057CAE: main (main.c:214) The code uses gtk_menu_item_new_with_label() to create a submenu which gets added to a menu which get attached to a top level window (one top level window per open file). I would expect that the submenu gets cleaned up when the top level window gets destroyed. Is that not the case? Humans can make mistakes, Yep, humans are completely hopeless :-). but GTK is well tested. I agree. The fact that GTK shows *zero* of the use-of/condition-jump on uninitialied memory errors shows that the GTK devs have spent a lot of time tracking down and killing all instances of that class of bugs. In my case, suspected errors in linux library code have always been errors in my own code which surface as Gnu libraries are improved. I am a library author myself and my goal in library design has always been to make the library difficult to mis-use. Above all I did this to reduce the amount of work I would have to do supporting my libraries. Admittedly my libraries are far smaller than GTK and have far simpler goals. However, I think all library designers should have Rusty Russel's guide on API design titled How Do I Make This Hard to Misuse? : http://ozlabs.org/ ̃rusty/index.cgi/tech/2008-03-30.html on hand whenever they are doing any API design work. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Valgrind and GTK libraries
Erik de Castro Lopo mle+...@mega-nerd.com wrote: ==12528== 27,300 bytes in 175 blocks are still reachable in loss record 11,194 of 11,196 ==12528== at 0x4024C1C: malloc (vg_replace_malloc.c:195) ==12528== by 0x4B342E3: g_malloc (gmem.c:131) ==12528== by 0x4B4A418: g_slice_alloc (gslice.c:824) ==12528== by 0x4B4A714: g_slice_alloc0 (gslice.c:833) ==12528== by 0x474F8F6: g_type_create_instance (gtype.c:1654) ==12528== by 0x4734747: g_object_constructor (gobject.c:1383) ==12528== by 0x4735707: g_object_newv (gobject.c:1171) ==12528== by 0x4736589: g_object_new_valist (gobject.c:1323) ==12528== by 0x473670D: g_object_new (gobject.c:1086) Say no more! We see that tons in chromium's valgrind runs, too. See http://crbug.com/16583 I added a suppression for it to http://src.chromium.org/cgi-bin/gitweb.cgi?p=chromium.git;a=blob_plain;f=tools/valgrind/memcheck/suppressions.txt some time ago. Searching the web finds a few other reports of this particular leak. - Dan ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Valgrind and GTK libraries
Dan Kegel wrote: Erik de Castro Lopo mle+...@mega-nerd.com wrote: ==12528== 27,300 bytes in 175 blocks are still reachable in loss record 11,194 of 11,196 ==12528== at 0x4024C1C: malloc (vg_replace_malloc.c:195) ==12528== by 0x4B342E3: g_malloc (gmem.c:131) ==12528== by 0x4B4A418: g_slice_alloc (gslice.c:824) ==12528== by 0x4B4A714: g_slice_alloc0 (gslice.c:833) ==12528== by 0x474F8F6: g_type_create_instance (gtype.c:1654) ==12528== by 0x4734747: g_object_constructor (gobject.c:1383) ==12528== by 0x4735707: g_object_newv (gobject.c:1171) ==12528== by 0x4736589: g_object_new_valist (gobject.c:1323) ==12528== by 0x473670D: g_object_new (gobject.c:1086) Say no more! We see that tons in chromium's valgrind runs, too. Well I consider this a *real* leak that needs to be fixed. The code I'm working on has multiple top level windows and the code path in the stack trace gets called for each window; thats 27300 bytes in 175 blocks for every window. In the normal usage of this app, its usual to have more than one window open at any time and to open and close more windows on-the-fly. Under these conditions, my app leaks memory due GTK+ and it seems there is nothing I can do in my code to prevent it. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Valgrind and GTK libraries
On Tue, Jan 05, 2010 at 09:39:48AM +1100, Erik de Castro Lopo wrote: ==12528== 27,300 bytes in 175 blocks are still reachable in loss record 11,194 of 11,196 ==12528==at 0x4024C1C: malloc (vg_replace_malloc.c:195) ==12528==by 0x4B342E3: g_malloc (gmem.c:131) ==12528==by 0x4B4A418: g_slice_alloc (gslice.c:824) ==12528==by 0x4B4A714: g_slice_alloc0 (gslice.c:833) ==12528==by 0x474F8F6: g_type_create_instance (gtype.c:1654) ==12528==by 0x4734747: g_object_constructor (gobject.c:1383) ==12528==by 0x4735707: g_object_newv (gobject.c:1171) ==12528==by 0x4736589: g_object_new_valist (gobject.c:1323) ==12528==by 0x473670D: g_object_new (gobject.c:1086) ==12528==by 0x4195924: ??? (in /usr/lib/libgtk-x11-2.0.so.0.1800.3) ==12528==by 0x4197833: ??? (in /usr/lib/libgtk-x11-2.0.so.0.1800.3) ==12528==by 0x4196787: gtk_menu_item_set_label (in /usr/lib/libgtk-x11-2.0.so.0.1800.3) ... The code uses gtk_menu_item_new_with_label() to create a submenu which gets added to a menu which get attached to a top level window (one top level window per open file). I would expect that the submenu gets cleaned up when the top level window gets destroyed. Is that not the case? If the leak is genuine, i.e. you can create arbitrary amount of leaked but reachable memory by repeating this, I'd say there's a circular reference between the accel label and the menu item that is not properly broken in dispose() -- be warned that this is from half-a-minute scan of the relevant code. Yeti ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Valgrind and GTK libraries
On Mon, Jan 04, 2010 at 02:56:44PM -0800, Dan Kegel wrote: Erik de Castro Lopo mle+...@mega-nerd.com wrote: ==12528== 27,300 bytes in 175 blocks are still reachable in loss record 11,194 of 11,196 ==12528== at 0x4024C1C: malloc (vg_replace_malloc.c:195) ==12528== by 0x4B342E3: g_malloc (gmem.c:131) ==12528== by 0x4B4A418: g_slice_alloc (gslice.c:824) ==12528== by 0x4B4A714: g_slice_alloc0 (gslice.c:833) ==12528== by 0x474F8F6: g_type_create_instance (gtype.c:1654) ==12528== by 0x4734747: g_object_constructor (gobject.c:1383) ==12528== by 0x4735707: g_object_newv (gobject.c:1171) ==12528== by 0x4736589: g_object_new_valist (gobject.c:1323) ==12528== by 0x473670D: g_object_new (gobject.c:1086) Say no more! We see that tons in chromium's valgrind runs, too. See http://crbug.com/16583 I added a suppression for it to http://src.chromium.org/cgi-bin/gitweb.cgi?p=chromium.git;a=blob_plain;f=tools/valgrind/memcheck/suppressions.txt some time ago. Searching the web finds a few other reports of this particular leak. Please note this is not a specific leak. Almost every GObject construction goes exactly the same code path (the exceptions are direct calls to g_object_newv() that won't show g_object_new_valist() and g_object_new()). So every time an object is leaked you get this trace. To really identify a specific leak you have to include more stack frames. Yeti ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
