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 163765 - Glib::Dispatcher crash
Glib::Dispatcher crash
Status: RESOLVED INVALID
Product: glibmm
Classification: Bindings
Component: threads
2.4.x
Other All
: Normal normal
: ---
Assigned To: gtkmm-forge
gtkmm-forge
Depends on:
Blocks:
 
 
Reported: 2005-01-12 06:07 UTC by Robert Quattlebaum, Jr.
Modified: 2005-03-14 17:45 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Robert Quattlebaum, Jr. 2005-01-12 06:07:22 UTC 
If Glib::Dispatcher::emit() is called and then that Glib::Dispatcher object is deleted before the signal is 
"dispatched" by the main loop, a crash occurs--even if the sigc::connection for that signal has been 
disconnected.

In my code, emit() is being called from a thread. The Glib::Dispatcher is being deleted from the main 
process.

Not that it would make any difference, but this bug appears both under Linux and Win32.

Here is a backtrace:

+ Trace 54415

  • #0 std::list<sigc::slot_base, std::allocator<sigc::slot_base> >::empty() const
    at stl_list.h line 628
  • #1 sigc::internal::signal_emit0<void, sigc::nil>::emit(sigc::internal::signal_impl*)
    at signal.h line 510
  • #2 Glib::DispatchNotifier::pipe_io_handler(Glib::IOCondition)
    at signal.h line 1584
  • #3 sigc::internal::slot_call1<sigc::bound_mem_functor1<bool, Glib::DispatchNotifier, Glib::IOCondition>, bool, Glib::IOCondition>::call_it(sigc::internal::slot_rep*, Glib::IOCondition const&)
    at mem_fun.h line 1838
  • #4 Glib::IOSource::dispatch(sigc::slot_base*)
  • #5 Glib::Source::dispatch_vfunc(_GSource*, int (*)(void*), void*)
  • #6 g_main_depth
    from /usr/lib/libglib-2.0.so.0
  • #7 g_main_context_dispatch
    from /usr/lib/libglib-2.0.so.0
  • #8 g_main_context_dispatch
    from /usr/lib/libglib-2.0.so.0
  • #9 g_main_loop_run
    from /usr/lib/libglib-2.0.so.0
  • #10 gtk_main
    from /usr/lib/libgtk-x11-2.0.so.0
  • #11 Gtk::Main::run_impl()
    at main.cc line 470
  • #12 Gtk::Main::run()
    at main.cc line 417
  • #13 main
    at main.cpp line 83
  • #14 __libc_start_main
    from /lib/libc.so.6 






Comment 1


Robert Quattlebaum, Jr.





          2005-01-12 06:39:04 UTC
        



A suitable work-around is to use Glib::signal_timeout() with a timeout value of zero, and binding the 
return value of the slot to "false".

This seems to work rather well in my code.






Comment 2


Murray Cumming





          2005-01-21 07:57:16 UTC
        



We really need a test case for this, as simple as possible, and compileable.






Comment 3


Murray Cumming





          2005-02-01 17:00:47 UTC
        



Could you create that test case, please?






Comment 4


Robert Quattlebaum, Jr.





          2005-02-01 23:19:22 UTC
        



I apologize, my life got kinda crazy all of the sudden. I will try to get that together over the next day or 
so.






Comment 5


Murray Cumming





          2005-03-14 15:35:52 UTC
        



I'm about to close this bug as invalid.






Comment 6


Robert Quattlebaum, Jr.





          2005-03-14 17:45:10 UTC
        



It does not look like I will be able to get around to making that test case in a
timely manner. I should have done that when I was knee-deep in the problem
months ago. The work-around worked so well that it became a non-issue in our
codebase.

I'll go ahead and mark this bug as invalid. I believe that this is a real bug,
but seeing that my subconscious seems to be unable to motivate me to make a test
case, there it little point in leaving this bug laying around.