Re: [Help-smalltalk] Add shortcuts to the visualgst/debugger

[Holger Hans Peter Freyther]

On Mon, Sep 30, 2013 at 05:52:03AM +0200, Holger Hans Peter Freyther wrote:

Hi again,

> Active process: <Proc 0x4048fdd8 prio: 1 next 0x40428800 context 0x4048ffb8>
>   Priority 1: First 0x4048fdd8 last 0x4048fdd8 
>     <Proc 0x4048fdd8 prio: 1 context 0x4048ffb8> 

this is the idle task...

> #1  0xb759983b in poll () at ../sysdeps/unix/syscall-template.S:81
> #2  0xa69ed778 in main_loop_poll (ms=-1) at gst-glib.c:192
> #3  main_loop_poll (ms=-1) at gst-glib.c:156
> #4  0xb7749812 in poll_events (blockingOOP=0x40428808) at events.c:259
> #5  0xb7749916 in _gst_idle (blocking=(unknown: 1078102024)) at events.c:300

and besides the -1.. it is called and called again. This is because the
fd==4 is triggering I think this is the unix domain socket for the X
connection.

poll([{fd=5, events=POLLIN}, {fd=4, events=POLLIN}, {fd=9, events=POLLIN}, 
{fd=10, events=POLLIN}], 4, 0) = 1 ([{fd=4, revents=POLLIN}])

I'm traveling and don't have gtk/glib sources available but I think
something is 'blocking' gtk to process events.


> #6  0xb7745d64 in VMpr_Processor_pause (id=0, numArgs=1) at prims.def:2987
> #7  0xb773998d in execute_primitive_operation (numArgs=<optimized out>, 
> primitive=135)
>     at interp.c:2732
> #8  _gst_send_message_internal (sendSelector=0x404793a0, sendArgs=1, 
> receiver=0x40428820, 
>     method_class=0x40429460) at interp-bc.inl:276
> #9  0xb773fc3c in _gst_interpret (processOOP=0x408052e8) at vm.def:645
> #10 0xb7746a09 in _gst_nvmsg_send (receiver=0x40810208, 
> sendSelector=0x405d2100, 
>     args=0xbf9e43d0, sendArgs=0) at interp.c:2312
> #11 0xb76e7fe5 in gst_nvmsg_send (receiver=0x40810208, selector=0x405d2100, 
>     address@hidden, address@hidden) at gstpub.c:199
> #12 0xa69e711d in invoke_smalltalk_closure (closure=0x9f46750, 
> return_value=0x0, 
>     n_param_values=0, param_values=0xbf9e4590, invocation_hint=0xbf9e453c, 
> marshal_data=0x0)
>     at gst-gobject.c:440


GtkDebugger>>#stepOver is invoked is here in #12


> #13 0xa65fcc56 in g_closure_invoke () from 
> /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
...
> #15 0xa66170db in g_signal_emit_valist () from 
> /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
> #24 0xa59204f6 in gtk_window_activate_key () from 
> /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0
...
> #36 0xa6536333 in g_main_context_dispatch () from 
> /lib/i386-linux-gnu/libglib-2.0.so.0
> #37 0xa69ed22a in main_loop_dispatch () at gst-glib.c:151
> #38 0xb774989b in _gst_dispatch_events () at events.c:285
> #39 0xb7746f65 in VMpr_Processor_dispatchEvents (id=0, numArgs=0) at 
> prims.def:2961
> 
> Smells a bit like the list of processes gets corrupted here. :}


So I think what is happening is the following:

* We are in the glib mainloop
* We get an event (F7.. keyboard)
* We use gst_nvmsg_send which will create a new Process (call-in)
* We dispatch GtkDebugger>>#stepOver
* We want to step/resume another process..
* We wait on a semaphore..
* The debugged process doesn't run (for whatever reason)
* The call-in is waiting on a Semaphore as well
* Only the timer process can run
* It polls.. and the X11 socket is readable
* The eventloop is not ran though.

Any ideas how to resolve that? There are appear to be several
issues here? So somehow we should gurantee that we always return
into the C-callback?!