After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 619530 - Glade crash when adding GtkNotebook
Glade crash when adding GtkNotebook
Status: RESOLVED FIXED
Product: glade
Classification: Applications
Component: general
3.7.x
Other Linux
: Normal critical
: ---
Assigned To: Glade 3 Maintainers
Glade 3 Maintainers
: 622222 622253 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2010-05-24 16:16 UTC by Maël Lavault
Modified: 2012-02-22 10:03 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
glade3-notebook-2.patch (3.36 KB, patch)
2010-07-13 11:38 UTC, Martin Schlemmer
none Details | Review
Patch to fix some assertion issues (1.24 KB, patch)
2010-11-10 18:53 UTC, Johannes Schmid
committed Details | Review

Description Maël Lavault 2010-05-24 16:16:33 UTC
Hi,

I just tested the 3.7.1 release of glade and i cant do anything since it crash everytime i want to add a notebook in my window. 

Just create a new window and add a gtknotebook, it's the same when i create a new window, add a vertical box and then add a notebook.

Thanks.
Comment 1 Maël Lavault 2010-05-24 16:18:57 UTC
It seems to happen with a lot of ui component, the toolbar and menubar for example.

I got this error : GladeUI:ERROR:glade-project.c:4354:glade_project_model_get_path: assertion failed: (child != NULL)
Comment 2 Tristan Van Berkom 2010-05-24 16:21:30 UTC
Right, I'm quite sure this is fixed in master but it needs to be verified...

(git master has a fix in the order of recursively adding objects to 
the project, a bug that sneaked in with the GladeProject implementing
GtkTreeModel stuff).
Comment 3 Fabio Durán Verdugo 2010-06-21 02:49:18 UTC
*** Bug 622222 has been marked as a duplicate of this bug. ***
Comment 4 James Liggett 2010-06-22 02:24:33 UTC
(In reply to comment #2)
> Right, I'm quite sure this is fixed in master but it needs to be verified...
> 
> (git master has a fix in the order of recursively adding objects to 
> the project, a bug that sneaked in with the GladeProject implementing
> GtkTreeModel stuff).

It's only fixed for some widgets. With master, frames work again, but notebooks still don't. When I add a notebook to a project with master I get this:


GladeUI:ERROR:glade-project.c:4358:glade_project_model_get_path: assertion failed: (child != NULL)
Comment 5 James Liggett 2010-06-22 02:26:16 UTC
*** Bug 622253 has been marked as a duplicate of this bug. ***
Comment 6 Martin Schlemmer 2010-06-24 16:00:33 UTC
(In reply to comment #4)
> (In reply to comment #2)
> > Right, I'm quite sure this is fixed in master but it needs to be verified...
> > 
> > (git master has a fix in the order of recursively adding objects to 
> > the project, a bug that sneaked in with the GladeProject implementing
> > GtkTreeModel stuff).
> 
> It's only fixed for some widgets. With master, frames work again, but notebooks
> still don't. When I add a notebook to a project with master I get this:
> 
> 
> GladeUI:ERROR:glade-project.c:4358:glade_project_model_get_path: assertion
> failed: (child != NULL)

I can confirm this:

Breakpoint 4, glade_project_model_get_path (model=0x313ebe0, iter=0x27f474)
    at glade-project.c:4358
4358                    g_assert (child != NULL);
(gdb) bt
  • #0 glade_project_model_get_path
    at glade-project.c line 4358
  • #1 gtk_tree_model_get_path
    at gtktreemodel.c line 1118
  • #2 glade_project_add_object
    at glade-project.c line 2719
  • #3 glade_gtk_notebook_set_n_pages
    at glade-gtk.c line 3909
  • #4 glade_gtk_notebook_set_property
    at glade-gtk.c line 3960
  • #5 glade_widget_adaptor_set_property
    at glade-widget-adaptor.c line 2735
  • #6 glade_widget_object_set_property
    at glade-widget.c line 3216
  • #7 glade_property_sync_impl
    at glade-property.c line 384
  • #8 glade_property_sync
    at glade-property.c line 984
  • #9 glade_widget_sync_custom_props
    at glade-widget.c line 670
  • #10 glade_widget_constructor
    at glade-widget.c line 782
  • #11 g_object_newv
    at gobject.c line 1261
  • #12 g_object_new_valist
    at gobject.c line 1377
  • #13 glade_widget_adaptor_create_widget_real
    at glade-widget-adaptor.c line 2388
  • #14 glade_command_create
    at glade-command.c line 1729
  • #15 glade_placeholder_button_press
    at glade-placeholder.c line 372
  • #16 _gtk_marshal_BOOLEAN__BOXED
    at gtkmarshalers.c line 84
  • #17 g_type_class_meta_marshal
    at gclosure.c line 878
  • #18 g_closure_invoke
    at gclosure.c line 767
  • #19 signal_emit_unlocked_R
    at gsignal.c line 3286
  • #20 g_signal_emit_valist
    at gsignal.c line 2991
  • #21 g_signal_emit
    at gsignal.c line 3038
  • #22 gtk_widget_event_internal
    at gtkwidget.c line 4943
  • #23 gtk_widget_event
    at gtkwidget.c line 4740
  • #24 gtk_propagate_event
    at gtkmain.c line 2442
  • #25 gtk_main_do_event
    at gtkmain.c line 1608
  • #26 gdk_event_dispatch
    at gdkevents-win32.c line 3378
  • #27 g_main_dispatch
    at gmain.c line 1960
  • #28 g_main_context_dispatch
    at gmain.c line 2513
  • #29 g_main_context_iterate
    at gmain.c line 2591
  • #30 g_main_loop_run
    at gmain.c line 2799
  • #31 gtk_main
    at gtkmain.c line 1219
  • #32 main
    at main.c line 186
$36 = (GList *) 0x0
(gdb) print children
$37 = (GList *) 0x0
(gdb) print parent->name
$38 = (gchar *) 0x30d12e0 "notebook1"
(gdb) print widget->name
$39 = (gchar *) 0x3c61520 "label1"
(gdb) print widget->parent
$40 = (GladeWidget *) 0x3c2bee0
(gdb)

The widget "label1" has "notebook1" as parent, but "notebook1" have no children at the time.

I can try to fix it, but some pointers would be appreciated.
Comment 7 Tristan Van Berkom 2010-06-24 16:36:09 UTC
The fix wont be so easy; the problem is as such:

Because we went from GladeProject bits cached inside a GtkTreeStore
to display in the inspector... to a GladeProject that actually implements
the GtkTreeModel (cleaner/better design), the order in which objects
are added to the project suddenly has an impact on the core.

So an advance warning, fixing this bug means to continue work refactoring
started by Johannes Schmid (as this is our future core, a patch here will
undergo a thorough review)

The solution can be:
  a.) Making the GladeProject more vigorous about how it updates
      when a child appears in the model before the parent.
  b.) Trying to make the glade-gtk.c plugin code never call
      glade_project_add_object() and leave that entirely
      to the glade-command.c code (undo/redo controller where
      most of that is done already).
     
'b' would be better and more generally important, only
the GladeCommand module should be allowed to add/remove
objects from the project anyway (cases where the plugin
add objects to the project are mostly redundant anyway).
Comment 8 Martin Schlemmer 2010-06-24 17:23:41 UTC
Thanks, will have a look as soon as possible.
Comment 9 Johannes Schmid 2010-07-08 11:39:14 UTC
From the tree model implementation (at least the way I did it) I think it is rather impossible to add a child before it parents as this doesn't make sense in a tree.

So, b) would be the way to go. Are there other widgets besides notebooks that have that problem?
Comment 10 Tristan Van Berkom 2010-07-08 14:39:44 UTC
Yes, searching through plugins/gtk+/glade-gtk.c for the text
glade_command_create() and glade_project_add_object() you should find
the cases where widgets are manually created by the plugin, some off the top
of my head:
  - The GtkExpander label is manually created
  - The GtkFrame's added alignment/label
  - The GtkMenuBar subhierarchy hierarchy created along with a menubar


Another probable bug comes to mind along the same lines:

Its also a good idea to look at glade_widget_rebuild() code, this
code (this is used whenever changing a construct-only property):
  - removes a widget from it's parent
  - removes all children from the widget
  - frees the widget instance and builds a replacement 
  - re-adds the children with all their recorded packing properties
  - re-adds the widget to its parent

As I recall, there's a reason why this above code also touches
the widget's 'project'...
Comment 11 Martin Schlemmer 2010-07-08 23:41:13 UTC
Sorry, started to look at this, then away for holidays, box troubles, etc.

Anyhow, removing glade_project_add_object() "fixes" the crash, and the label is visible in the design area, but not added to the 'project' - the reason that you wanted to recall :)  I will look at it maybe this weekend, or latest next week, but the other's are already fixed, I just did not really have a good look at how to try and migrate the fix, but will look at your suggestions, thanks.


There is also some tab cleanup code there that I do not get - as the tab objects never seem to exist as GladeWidgets, but I'll mention that again when I get there.
Comment 12 Martin Schlemmer 2010-07-13 11:38:12 UTC
Created attachment 165790 [details] [review]
glade3-notebook-2.patch

GtkExpander seems to be ok.
GtkFrame shows 2 label objects in the project list, with console output like:

-----
(glade-3.exe:8848): GladeUI-CRITICAL **: glade_widget_get_from_gobject: assertion `G_IS_OBJECT
(object)' failed

(glade-3.exe:8848): GladeUI-CRITICAL **: glade_widget_get_children: assertion `GLADE_IS_WIDGET
(widget)' failed

(glade-3.exe:8848): GLib-GObject-CRITICAL **: g_object_set_property: assertion `G_IS_VALUE (value)' failed

(glade-3.exe:8848): GLib-GObject-CRITICAL **: g_value_unset: assertion `G_IS_VALUE (value)' failed
-----

Attached patch is one version of various ways I tried to fix it.  It relatively works in that:
- project loading is fine
- you can add and remove tabs without problem

Issues:
- labels of newly added tabs do not show up in the project list, and the handlers are not active

This however is fixed if you change the naming policy, so not sure if this is a problem higher up?

I tried to fix the duplicate label issue for GtkFrame, and this works for the first frame added, but not the second add.  Either way, changing the naming policy it is fixed again.


So it seems like there might be another issue higher up with the project code?
Comment 13 Johannes Schmid 2010-11-10 18:53:09 UTC
Created attachment 174210 [details] [review]
Patch to fix some assertion issues

This patch removes an assertion and fails more gratefully. This doesn't seem to harm in the tree view so I guess it's ok.
Comment 15 Kristofer Wempa 2012-02-21 21:48:19 UTC
Which release(s) was this fixed in ?  I checked the release notes for 3.7.2 and 3.7.3, but didn't see this bug listed.
Comment 16 Johannes Schmid 2012-02-21 22:00:50 UTC
According to git it was fixed in 3.7.3 but who generally cares, it's fixed in any of the stable version (3.8.x and 3.10.x).
Comment 17 Kristofer Wempa 2012-02-21 22:02:57 UTC
Thank you.  We can't move up to 3.8.X (GTK dependency issue) so I needed to know specifically for 3.7.X.
Comment 18 Martin Schlemmer 2012-02-22 10:03:10 UTC
The patch from comment #14 was applied to 3.7.3 (just verified it, did  not verify if the crash do not happen - I do not have a build with 3.7.3 handy right now, sorry).