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 673569 - core dump in gtk_builder_connect_signals_full
core dump in gtk_builder_connect_signals_full
Status: RESOLVED INVALID
Product: accerciser
Classification: Applications
Component: core
3.5.x
Other NetBSD
: Normal normal
: ---
Assigned To: Accerciser Developers
Accerciser Developers
Depends on:
Blocks:
 
 
Reported: 2012-04-05 13:28 UTC by Patrick Welche
Modified: 2012-08-03 18:21 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Patrick Welche 2012-04-05 13:28:21 UTC
Just checked if I still saw this with the new tarballs for (at-spi2-core, at-spi2-atk, pyatspi) all version 2.4 and accerciser 3.4.0, and unfortunately I still get a repeatable core dump when starting accerciser:


Program terminated with signal 11, Segmentation fault.
  • #0 ??
  • #0 ??
  • #1 gtk_builder_connect_signals_full
    at gtkbuilder.c line 1337
  • #1 gtk_builder_connect_signals_full
    builder=0x7f7ff37baad0, func=0x7f7ff3b768c0, user_data=0x7f7ff3315b70)
    at gtkbuilder.c:1337
1337          func (builder, object, signal->name, signal->handler, 
(gdb) print *signal
$1 = {tag = {name = 0x7f7ff37c4580 ""}, 
  object_name = 0x7f7ff37ef620 "cellrenderertoggle1", 
  name = 0x7f7ff5303e88 "toggled", handler = 0x7f7ff37f2da0 "_onToggled", 
  flags = 0, connect_object_name = 0x0}


The relevant bit of plugins/event_monitor.ui is:
          <object class="GtkCellRendererToggle" id="cellrenderertoggle1">
             <signal name="toggled" handler="_onToggled"/>
          </object>
which looks fine, and _onToggled is defined in plugins/event_monitor.py.
"toggled" is also not the first signal in the .ui file. It is the only one inside a GtkTreeView.

In other words, I don't see what is wrong - thoughts?
Comment 1 Javier Hernández 2012-05-26 22:20:59 UTC
Hey Patrick, thanks for the report!

Anyway, I can't reproduce this bug, and, I'm wondering if you tested with a newer pygobject release. Are you still getting this issue? If yes, could you provide your pygobject version and/or your distribution details?

I think this information could help a bit here :]

Best regards!
Comment 2 Patrick Welche 2012-07-31 16:30:16 UTC
I did some serious upgrading, and the coredump persists, in the same place.

I now have installed:

glib 2.32.4
python 2.6
pygobject 3.2.2
at-spi2*/pyatspi 2.5.4
gobject-introspection 1.32.1
libffi 3.0.9
gtk 3.4.4
accerciser 3.5.3 with the .IN -> .IN_ commit reverted

All I have to do is run accerciser, and:

  • #0 ??
  • #1 gtk_builder_connect_signals_full
    at gtkbuilder.c line 1490
  • #2 ffi_call_unix64
    at src/x86/unix64.S line 75
  • #3 ffi_call
    at src/x86/ffi64.c line 484
  • #4 g_callable_info_invoke
    at girepository/gicallableinfo.c line 610
  • #5 g_function_info_invoke
    at girepository/gifunctioninfo.c line 274
  • #1 gtk_builder_connect_signals_full
    builder=0x7f7fefb49c00, func=0x7f7fefb6d7c0, user_data=0x7f7fefb4a000)
    at gtkbuilder.c:1490
1490          func (builder, object, signal->name, signal->handler, 
(gdb) print *signal
$1 = {tag = {name = 0x0}, object_name = 0x0, 
  name = 0x109 <Address 0x109 out of bounds>, handler = 0x0, flags = 390, 
  connect_object_name = 0x1 <Address 0x1 out of bounds>}
Comment 3 Patrick Welche 2012-08-03 18:21:14 UTC
Reproduced crash with trivial python program => moving to pygobject as Bug 681157.