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 144420 - Segfault in libsigc++
Segfault in libsigc++
Status: RESOLVED FIXED
Product: glibmm
Classification: Bindings
Component: general
2.4.x
Other Linux
: Normal major
: ---
Assigned To: gtkmm-forge
gtkmm-forge
Depends on:
Blocks:
 
 
Reported: 2004-06-15 13:43 UTC by Morten Brix Pedersen
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
source-connection-node.patch: Move deletion of SourceConnectionNode object into destroy_notify_callback() exclusively (1.21 KB, patch)
2004-07-23 14:08 UTC, Martin Schulze
none Details | Review
source-connection-node-changelog.patch: Move deletion of SourceConnectionNode object into destroy_notify_callback() exclusively (1.82 KB, patch)
2004-07-23 14:14 UTC, Martin Schulze
none Details | Review

Description Morten Brix Pedersen 2004-06-15 13:43:07 UTC
My application has started to segfault with latest glibmm and libsigc++. A
backtrace with debug symbols from libraries looks like this:

Program received signal SIGSEGV, Segmentation fault.
0x082530da in ?? ()
(gdb) bt
  • #0 ??
  • #1 ~slot_base
    at slot_base.h line 87
  • #2 (anonymous namespace)::SourceConnectionNode::destroy_notify_callback
    at main.cc line 72
  • #3 g_source_set_callback_indirect
    from /usr/lib/libglib-2.0.so.0
  • #4 g_main_depth
    from /usr/lib/libglib-2.0.so.0
  • #5 g_main_context_dispatch
    from /usr/lib/libglib-2.0.so.0
  • #6 g_main_context_dispatch
    from /usr/lib/libglib-2.0.so.0
  • #7 g_main_loop_run
    from /usr/lib/libglib-2.0.so.0
  • #8 gtk_main
    from /usr/lib/libgtk-x11-2.0.so.0
  • #9 Gtk::Main::run_impl
    from /usr/lib/libgtkmm-2.4.so.1
  • #10 Gtk::Main::run
    from /usr/lib/libgtkmm-2.4.so.1
  • #11 main
    at main.cpp line 48

slot_base.h (libsigc++) line 87 gives me this:

  inline ~slot_rep()
    { if (detach_) (*detach_)(this); }

main.cc (glibmm) line 72 gives me this:

  if (self->source_)
  {
    GSource* s = self->source_;
    self->source_ = 0;
    g_source_destroy(s);

    delete self; // <-- line 72
  }

Unfortunately, I havn't had success in providing a simple reproducable example
of application code.
Comment 1 Murray Cumming 2004-06-28 07:29:46 UTC
I'm sorry, we probably can't do anything without a test case. I recommend
valgrind for solving these kinds of appplication problems.
Comment 2 Morten Brix Pedersen 2004-06-29 01:44:10 UTC
Ok, leave this bug open then. I will try to produce a test case.

Unfortunately I'm on vacation at the moment, so I probably won't be able to look at this before august.
Comment 3 Martin Schulze 2004-07-15 19:43:00 UTC
Can we rely on the fact that these critical two lines in the code:

  self->source_ = 0;
  g_source_destroy(s);

get executed in the right order? Or might there be come caching that prevent
self->source_ from actually being written into memory?
Comment 4 Murray Cumming 2004-07-16 15:07:36 UTC
I can't think why they would not be executed in the right order. If we get a
test case then we can run valgrind on it.
Comment 5 Murray Cumming 2004-07-17 13:27:37 UTC
Maybe we need to change the _destroy() and _notify() SourceConnectionNode
methods to match the changes that I recently made in the regular ConnectionNode.
Could you try that? I don't want to risk breaking it without a test case.
Comment 6 Martin Schulze 2004-07-23 14:08:35 UTC
Created attachment 29828 [details] [review]
source-connection-node.patch: Move deletion of SourceConnectionNode object into destroy_notify_callback() exclusively

Note that SourceConnectionNode is substantially different from ConnectionNode
in that it wraps a GSource object rather than a glib signal.

However, here is a patch that moves the deletion of the SourceConnectionNode
object into destroy_notify_callback() exclusively (like you did in the regular
ConnectionNode). Maybe this helps. Morten, you should try glibmm from cvs with
this patch applied before going through the efforts of creating a
simple-as-possible test case.
Comment 7 Martin Schulze 2004-07-23 14:14:44 UTC
Created attachment 29829 [details] [review]
source-connection-node-changelog.patch: Move deletion of SourceConnectionNode object into destroy_notify_callback() exclusively

Same as first patch but with ChangeLog entry ... just in case ;)
Comment 8 Morten Brix Pedersen 2004-07-30 17:56:00 UTC
I have just tried your patch against my glibmm, and it works flawlessly.

It is quite easy to reproduce the problem in my application; and clearly when a
copy of glibmm with your patch is installed on my system, the segmentation fault
stops to occur.

Thank you very much. I hope this patch will be in a glibmm release soon.
Comment 9 Murray Cumming 2004-07-31 09:20:54 UTC
OK, please commit. Thanks to both of you.

Morten, you really need to try valgrind out.
Comment 10 Martin Schulze 2004-08-01 16:17:54 UTC
Committed to cvs.