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 377699 - realizing gtk.Progress() causes SEGV
realizing gtk.Progress() causes SEGV
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: Other
2.10.x
Other All
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2006-11-21 09:28 UTC by Dima Tisnek
Modified: 2008-11-17 09:52 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
Define GtkProgress as an abstract type (526 bytes, patch)
2008-09-08 09:32 UTC, Christian Dywan 		committed Details | Review

Description Dima Tisnek 2006-11-21 09:28:33 UTC 
>>> import gtk
>>> win = gtk.Window()
>>> win.add(gtk.Progress())
>>> win.show_all()
Segmentation fault

gtk.Progress, the base class for gtk.ProgressBar, can be added to a container without error, but when shown causes segmentation fault in gtk extentsion to python, here's the backtrace:

(gdb) bt

+ Trace 88195

  • #0 ??
  • #1 gtk_progress_get_type
    from /usr/lib/libgtk-x11-2.0.so.0
  • #2 g_closure_invoke
    from /usr/lib/libgobject-2.0.so.0
  • #3 g_signal_has_handler_pending
    from /usr/lib/libgobject-2.0.so.0
  • #4 g_signal_emit_valist
    from /usr/lib/libgobject-2.0.so.0
  • #5 g_signal_emit
    from /usr/lib/libgobject-2.0.so.0
  • #6 gtk_widget_realize
    from /usr/lib/libgtk-x11-2.0.so.0
  • #7 gtk_widget_map
    from /usr/lib/libgtk-x11-2.0.so.0
  • #8 gtk_window_reshow_with_initial_size
    from /usr/lib/libgtk-x11-2.0.so.0
  • #9 g_closure_invoke
    from /usr/lib/libgobject-2.0.so.0
  • #10 g_signal_has_handler_pending
    from /usr/lib/libgobject-2.0.so.0
  • #11 g_signal_emit_valist
    from /usr/lib/libgobject-2.0.so.0
  • #12 g_signal_emit
    from /usr/lib/libgobject-2.0.so.0
  • #13 gtk_widget_map
    from /usr/lib/libgtk-x11-2.0.so.0
  • #14 gtk_window_get_position
    from /usr/lib/libgtk-x11-2.0.so.0
  • #15 g_closure_invoke
    from /usr/lib/libgobject-2.0.so.0
  • #16 g_signal_has_handler_pending
    from /usr/lib/libgobject-2.0.so.0
  • #17 g_signal_emit_valist
    from /usr/lib/libgobject-2.0.so.0
  • #18 g_signal_emit
    from /usr/lib/libgobject-2.0.so.0
  • #19 gtk_widget_show
    from /usr/lib/libgtk-x11-2.0.so.0
  • #20 init_gtk
    from /usr/lib64/python2.4/site-packages/gtk-2.0/gtk/_gtk.so
  • #21 PyEval_EvalFrame
    from /usr/lib/libpython2.4.so.1.0
  • #22 PyEval_EvalCodeEx
    from /usr/lib/libpython2.4.so.1.0
  • #23 PyEval_EvalCode
    from /usr/lib/libpython2.4.so.1.0
  • #24 PyErr_Display
    from /usr/lib/libpython2.4.so.1.0
  • #25 PyRun_InteractiveOneFlags
    from /usr/lib/libpython2.4.so.1.0
  • #26 PyRun_InteractiveLoopFlags
    from /usr/lib/libpython2.4.so.1.0
  • #27 PyRun_AnyFileExFlags
    from /usr/lib/libpython2.4.so.1.0
  • #28 Py_Main
    from /usr/lib/libpython2.4.so.1.0
  • #29 __libc_start_main
    from /lib/libc.so.6
  • #30 _start 






Comment 1


Johan (not receiving bugmail) Dahlin





          2008-01-29 18:04:09 UTC
        



A bug in Gtk+, moving.






Comment 2


Gian Mario Tagliaretti





          2008-01-30 21:51:42 UTC
        



I don't know if this can be fixed using G_DEFINE_ABSTRACT_TYPE() instead of G_DEFINE_TYPE() without breaking things, if that's not possible we should override tp.new in the Python bindings and return the same error string as if gtk+ itself defines GtkProgress as an abstract type.






Comment 3


Emmanuele Bassi (:ebassi)





          2008-01-30 22:08:11 UTC
        



no, declaring it as an abstract type would not break anything: existing code should not be calling g_object_new (GTK_TYPE_PROGRESS, ...) anyway, and if it did it would be a programming error (the GtkProgress class is defined as abstract in the documentation. it's just possible that, when transitioning to the G_DEFINE_TYPE macro, the abstract flag got simply lost.






Comment 4


Christian Dywan





          2008-09-08 09:32:56 UTC
        



Created attachment 118286 [details] [review]
Define GtkProgress as an abstract type

Using the right macro seems most appropriate here. It won't change anything except that bogus code errors out earlier than before.






Comment 5


Michael Natterer





          2008-09-08 10:10:26 UTC
        



Tha abstract flag was not there before porting to G_DEFINE_TYPE(), but
declaring the class as abstract is IMHO the right thing to do anyway,
given it is deprecated and only kept around for compatibility.







Comment 6


Michael Natterer





          2008-09-08 10:25:28 UTC
        



borked attachment status






Comment 7


Tim Janik





          2008-11-14 16:57:11 UTC
        



(In reply to comment #4)
> Created an attachment (id=118286) [edit]
> Define GtkProgress as an abstract type
> 
> Using the right macro seems most appropriate here. It won't change anything
> except that bogus code errors out earlier than before.


Please go ahead and apply the fix.






Comment 8


Christian Dywan





          2008-11-17 09:52:02 UTC
        



2008-11-17  Christian Dywan  <christian@imendio.com>

	Bug 377699 – realizing gtk.Progress() causes SEGV

	* gtk/gtkprogress.c: Define GtkProgress as an abstract type