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 170105 - crash on "window.get_toolbar()"
crash on "window.get_toolbar()"
Status: RESOLVED FIXED
Product: epiphany
Classification: Core
Component: General
git master
Other Linux
: High blocker
: 1.8
Assigned To: Epiphany Maintainers
Marco Pesenti Gritti
Depends on:
Blocks:
 
 
Reported: 2005-03-12 22:23 UTC by Christian Persch
Modified: 2005-07-31 20:27 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Christian Persch 2005-03-12 22:23:03 UTC
Program received signal SIGSEGV, Segmentation fault.

Thread 16384 (LWP 1291)

  • #0 initgobject
    from /usr/lib/python2.4/site-packages/gtk-2.0/gobject.so
  • #1 initepiphany
    from /usr/lib/python2.4/site-packages/gtk-2.0/epiphany.so
  • #2 PyEval_GetFuncDesc
    from /usr/lib/libpython2.4.so.1.0
  • #3 ??
  • #4 PyEphyTab_Type
    from /usr/lib/python2.4/site-packages/gtk-2.0/epiphany.so
  • #5 ??
    from /usr/lib/libpython2.4.so.1.0
  • #6 ??
  • #7 PyEphyTab_Type
    from /usr/lib/python2.4/site-packages/gtk-2.0/epiphany.so
  • #8 ??
  • #9 PyObject_GetAttr
    from /usr/lib/libpython2.4.so.1.0

Unfortunately there's no debug libpython for ubuntu, so I cannot get a better
trace :(
Comment 1 Christian Persch 2005-03-12 22:27:18 UTC
Here's a trace from self-compiled pyphany with symbols. Looks like it crashes in
_wrap_ephy_window_get_toolbar with self=0x0 !

  • #0 initgobject
    from /usr/lib/python2.4/site-packages/gtk-2.0/gobject.so
  • #1 _wrap_ephy_window_get_toolbar
    at epiphany.c line 3387
  • #2 PyEval_GetFuncDesc
    from /usr/lib/libpython2.4.so.1.0
  • #3 ??
  • #4 _PyEphyWindow_methods
    from /opt/gnome-2.12/lib/python2.4/site-packages/gtk-2.0/epiphany.so
  • #5 ??
    from /usr/lib/libpython2.4.so.1.0
  • #6 ??
  • #7 _PyEphyWindow_methods
    from /opt/gnome-2.12/lib/python2.4/site-packages/gtk-2.0/epiphany.so
  • #8 ??
  • #9 PyObject_GetAttr
    from /usr/lib/libpython2.4.so.1.0

Comment 2 Christian Persch 2005-03-13 12:54:29 UTC
Ok, here's a trace with a debug build of python2.4:

  • #0 initgobject
    from /usr/lib/python2.4/site-packages/gtk-2.0/gobject.so
  • #1 _wrap_ephy_window_get_toolbar
    at epiphany.c line 3402
  • #2 call_function
    at ../Python/ceval.c line 3531
  • #3 PyEval_EvalFrame
    at ../Python/ceval.c line 2163
  • #4 PyEval_EvalCodeEx
    at ../Python/ceval.c line 2730
  • #5 PyEval_EvalCode
    at ../Python/ceval.c line 484
  • #6 run_node
    at ../Python/pythonrun.c line 1264
  • #7 builtin_eval
    at ../Python/bltinmodule.c line 516
  • #8 PyCFunction_Call
    at ../Objects/methodobject.c line 108
  • #9 call_function
    at ../Python/ceval.c line 3547
  • #10 PyEval_EvalFrame
    at ../Python/ceval.c line 2163
  • #11 PyEval_EvalCodeEx
    at ../Python/ceval.c line 2730
  • #12 fast_function
    at ../Python/ceval.c line 3640
  • #13 call_function
    at ../Python/ceval.c line 3568
  • #14 PyEval_EvalFrame
    at ../Python/ceval.c line 2163
  • #15 fast_function
    at ../Python/ceval.c line 3629
  • #16 call_function
    at ../Python/ceval.c line 3568
  • #17 PyEval_EvalFrame
    at ../Python/ceval.c line 2163
  • #18 PyEval_EvalCodeEx
    at ../Python/ceval.c line 2730
  • #19 function_call
    at ../Objects/funcobject.c line 550
  • #20 PyObject_Call
    at ../Objects/abstract.c line 1751
  • #21 instancemethod_call
    at ../Objects/classobject.c line 2431
  • #22 PyObject_Call
    at ../Objects/abstract.c line 1751
  • #23 PyEval_CallObjectWithKeywords
    at ../Python/ceval.c line 3419
  • #24 PyObject_CallObject
    at ../Objects/abstract.c line 1742
  • #25 initgobject
    from /usr/lib/python2.4/site-packages/gtk-2.0/gobject.so
  • #26 g_closure_invoke
    from /usr/lib/libgobject-2.0.so.0
  • #27 g_signal_emit_by_name
    from /usr/lib/libgobject-2.0.so.0
  • #28 g_signal_emit_valist
    from /usr/lib/libgobject-2.0.so.0
  • #29 g_signal_emit
    from /usr/lib/libgobject-2.0.so.0
  • #30 gtk_widget_event_internal
    at gtkwidget.c line 3631
  • #31 IA__gtk_window_propagate_key_event
    at gtkwindow.c line 4429
  • #32 gtk_window_key_press_event
    at gtkwindow.c line 4459
  • #33 _gtk_marshal_BOOLEAN__BOXED
    at gtkmarshalers.c line 83
  • #34 g_cclosure_new_swap
    from /usr/lib/libgobject-2.0.so.0
  • #35 g_closure_invoke
    from /usr/lib/libgobject-2.0.so.0
  • #36 g_signal_emit_by_name
    from /usr/lib/libgobject-2.0.so.0
  • #37 g_signal_emit_valist
    from /usr/lib/libgobject-2.0.so.0
  • #38 g_signal_emit
    from /usr/lib/libgobject-2.0.so.0
  • #39 gtk_widget_event_internal
    at gtkwidget.c line 3631
  • #40 IA__gtk_propagate_event
    at gtkmain.c line 2119
  • #41 IA__gtk_main_do_event
    at gtkmain.c line 1383
  • #42 gdk_event_dispatch
    at gdkevents-x11.c line 2220
  • #43 g_main_depth
    from /usr/lib/libglib-2.0.so.0
  • #44 g_main_context_dispatch
    from /usr/lib/libglib-2.0.so.0
  • #45 g_main_context_dispatch
    from /usr/lib/libglib-2.0.so.0
  • #46 g_main_loop_run
    from /usr/lib/libglib-2.0.so.0
  • #47 IA__gtk_main
    at gtkmain.c line 963
  • #48 main
    at ../../src/ephy-main.c line 313

Comment 3 Jean-François Rameau 2005-03-22 20:18:54 UTC
It seems that the crash occurs because EphyToolbar type has no wrapper (this is
the same for EphyBookmarksBar which crashes Epiphany too,
EphyWindow.get_bookmarksbar). Both are Epiphany's internals but are accessibles
from a public interface (EphyWindow).
We can create wrappers but we need then to expose some more internal stuff
(EggEditableToolbar).
An other solution is atm to force a generic wrapper like this:

(define-object Toolbar
  (in-module "Ephy")
  (parent "GtkVBox")                    <- the real topmost parent
  (c-name "EphyToolbar")
  (gtype-id "EPHY_TYPE_TOOLBAR")
)

Comment 4 Adam Hooper 2005-03-23 02:36:43 UTC
There's not really much point in the get_toolbar() and get_bookmarksbar()
functions at the moment, since they're private classes. But at some point we'll
want to have public ones of some sort, right?

I agree with the vbox idea, but I'm slightly worried that people will think it's
a bug in Pyphany, rather than a design decision. The only alternative solutions
I can think of are to return None or to omit the functions entirely, and I don't
think either of those is better than returning a vbox.
Comment 5 Christian Persch 2005-05-21 20:45:30 UTC
-> Epiphany
Comment 6 Christian Persch 2005-07-31 20:26:56 UTC
Fixed in cvs.