Re: Event loop hangup when using TimeoutSource and IdleSource

[Jim Hodapp <james hodapp gmail com>]

Chris,

    I removed the inheritance statement from my Emsac class  
definition and things seemed more stable. Things remained stable until  
I moved the mouse over some widgets in the main window that will  
accept focus and very shortly after that the application segfaulted.  
The backtrace is as follows:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb6bbd720 (LWP 26118)]
0xb7c3b439 in Gtk::Label::set_text (this=0x0, str= 0xbfd5ad88) at  
label.cc:252
252     label.cc: No such file or directory.
        in label.cc
(gdb) bt
#0  0xb7c3b439 in Gtk::Label::set_text (this=0x0, str= 0xbfd5ad88) at  
label.cc:252
#1  0x0805382c in emsac::Emsac::getPrimaryPackCurrentCb  
(this=0x8738690, current=-2.75999999) at src/emsac.cpp:498
#2  0x0805a554 in sigc::bound_mem_functor1<bool, emsac::Emsac,  
float>::operator() (this=0x8738828, _A_a1= 0x8738834)
    at /usr/include/sigc++-2.0/sigc++/functors/mem_fun.h:1851
#3  0x0805a571 in sigc::adaptor_functor<sigc::bound_mem_functor1<bool,  
emsac::Emsac, float> >::operator()<float&> (this=0x8738824,
    _A_arg1= 0x8738834) at /usr/include/sigc++-2.0/sigc++/adaptors/ 
adaptor_trait.h:84
#4  0x0805a59c in sigc::bind_functor<-1,  
sigc::bound_mem_functor1<bool, emsac::Emsac, float>, float, sigc::nil,  
sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil>::operator()  
(this=0x8738820) at /usr/include/sigc++-2.0/sigc++/adaptors/bind.h:1110
#5  0x0805a5b8 in sigc::internal::slot_call0<sigc::bind_functor<-1,  
sigc::bound_mem_functor1<bool, emsac::Emsac, float>, float, sigc::nil,  
sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil>, bool>::call_it  
(rep=0x8738808)
    at /usr/include/sigc++-2.0/sigc++/functors/slot.h:103
#6  0xb755f90a in glibmm_source_callback (data=0xb7149848) at /usr/ 
include/sigc++-2.0/sigc++/functors/slot.h:440
#7  0xb7189c81 in g_idle_dispatch (source=0x8737bd8,  
callback=0x8737c1c, user_data=0x8732120)
    at /build/buildd/glib2.0-2.20.1/glib/gmain.c:3922
#8  0xb718bb88 in IA__g_main_context_dispatch (context=0x856de48) at / 
build/buildd/glib2.0-2.20.1/glib/gmain.c:1814
#9  0xb718f0eb in g_main_context_iterate (context=0x856de48, block=1,  
dispatch=1, self=0x858d140)
    at /build/buildd/glib2.0-2.20.1/glib/gmain.c:2448
#10 0xb718f5ba in IA__g_main_loop_run (loop=0x8554f30) at /build/ 
buildd/glib2.0-2.20.1/glib/gmain.c:2656
#11 0xb76fc7d9 in IA__gtk_main () at /build/buildd/gtk+2.0-2.16.1/gtk/ 
gtkmain.c:1205
#12 0xb7c403d7 in Gtk::Main::run_impl (this=0xbfd5b058) at main.cc:536
#13 0xb7c404fe in Gtk::Main::run (window= 0x85dc188) at main.cc:490
#14 0x0804cfd4 in main (argc=-1223387092, argv=0xb714986c) at src/ 
main.cpp:96

Also, the instance of Emsac that I am passing around is instantiated  
on the heap in the main function of my application. So it should be  
around until the GUI event loop exits and my application terminates  
and explicitly delete this instance.

The GUI thread talks to the library thread directly through API calls.  
I link the library into the GUI application and make direct calls.

Thanks,

Jim

On Sep 24, 2009, at 4:36 PM, Chris Vine wrote:

> On Thu, 24 Sep 2009 16:27:11 -0400
> Jim Hodapp <james hodapp gmail com> wrote:
> > Chris,
> >
> >     I am not setting up the Glib::signal_idle().connect() in a
> > separate thread from the main GUI thread. Only the library which
> > communicates with the device is in a separate thread. That library
> > is all C and doesn't touch gtkmm or glibmm at all. The backtrace made
> > me want to double check the scope on my instance of "this" that I'm
> > passing to the library, then the library passes to the callback
> > wrapper function in which the signal_idle connection uses to call
> > the final callback function that modifies the GUI widget(s). I
> > imagine if "this" went out of scope somehow that sigc and glibmm
> > wouldn't like that much when destroying the idle handler reference.
>
> Jim,
>
> If you are passing arguments to an idle handler it is best to have
> them on freestore and free them in the handler if they are not passed
> by value, as of course they need to be around until the point at which
> the main loop gets around to executing the slot. There is a separate
> issue of the target object method invoked by the handler remaining in
> existence, but you can get automatic slot disconnection with
> sigc::trackable.  You are probably well aware of this and it may well
> not be related to your problem.
>
> Just out of interest (as I am interested in such things), how does the
> device library thread communicate with the GUI thread?
>
> Chris