Add shortcuts to the visualgst/debugger

Hi,

I've added some shortcuts to the visualgst debugger commands,
they are hard coded in a future that should use a preference
framework.

Gwen


_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

On Mon, Sep 16, 2013 at 10:59:38AM +0200, Gwenaël Casaccio wrote:
> Hi,
>
> I've added some shortcuts to the visualgst debugger commands,
> they are hard coded in a future that should use a preference
> framework.

lovely! i immediately found the next bug... use <F7> until you are
at the __terminate... and visualgst will hang. :)

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

On 16/09/2013 15:17, Holger Hans Peter Freyther wrote:
> On Mon, Sep 16, 2013 at 10:59:38AM +0200, Gwenaël Casaccio wrote:
>> Hi,
>>
>> I've added some shortcuts to the visualgst debugger commands,
>> they are hard coded in a future that should use a preference
>> framework.
> lovely! i immediately found the next bug... use <F7> until you are
> at the __terminate... and visualgst will hang. :)

I know but that's another story :-)

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

On Mon, Sep 16, 2013 at 04:06:04PM +0200, Gwenaël Casaccio wrote:
>
> I know but that's another story :-)

Do you think we can have a workaround?

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

On 29/09/2013 14:37, Holger Hans Peter Freyther wrote:
> On Mon, Sep 16, 2013 at 04:06:04PM +0200, Gwenaël Casaccio wrote:
>> I know but that's another story :-)
> Do you think we can have a workaround?

I've seen two problems:

  the first is the execution became very slow
  the second a vm crash

I need to investigate more in depth

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

On Sun, Sep 29, 2013 at 02:37:25PM +0200, Holger Hans Peter Freyther wrote:
> On Mon, Sep 16, 2013 at 04:06:04PM +0200, Gwenaël Casaccio wrote:
> >
> > I know but that's another story :-)
>
> Do you think we can have a workaround?

I tried to debug some of the Parser Problems with the current debugger
but I hit something that might look like a glib binding problem.

Debug this statement:
 STInST.RBParser parseExpression: '#(##(1/2) 1)'

Once in  STInST.RBParser class>>parseExpression:onError: use the
'F7'/Step method. VisualGST will freeze. I launched VisualGST by
hand from a running 'gst' process to see how much survived, then
I attached with gdb and tried to print the process list. It was
surprisingly empty (there should have been call-outs)


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

And in gdb I have this:

Program received signal SIGINT, Interrupt.
0xb779f424 in __kernel_vsyscall ()
(gdb) bt
#0  0xb779f424 in __kernel_vsyscall ()
#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
#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,
    args=args@entry=0xbf9e43d0, nargs=nargs@entry=0) 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
#13 0xa65fcc56 in g_closure_invoke () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
#14 0xa660eed7 in ?? () 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
#16 0xa66172b3 in g_signal_emit () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
#17 0xa5904e70 in ?? () from /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0
#18 0xa65fcc56 in g_closure_invoke () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
#19 0xa660eed7 in ?? () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
#20 0xa6616d73 in g_signal_emit_valist () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
#21 0xa66172b3 in g_signal_emit () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
#22 0xa56ee166 in gtk_accel_group_activate () from /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0
#23 0xa56ef539 in gtk_accel_groups_activate ()
   from /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0
#24 0xa59204f6 in gtk_window_activate_key () from /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0
#25 0xa592057e in ?? () from /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0
#26 0xa57ce722 in ?? () from /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0
#27 0xa65fbacd in ?? () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
#28 0xa65fcc56 in g_closure_invoke () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
#29 0xa660eb36 in ?? () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
#30 0xa6616d73 in g_signal_emit_valist () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
#31 0xa66172b3 in g_signal_emit () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
#32 0xa59065ab in ?? () from /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0
#33 0xa57cc8ec in gtk_propagate_event () from /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0
#34 0xa57ccbb0 in gtk_main_do_event () from /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0
#35 0xa5c579b8 in ?? () from /usr/lib/i386-linux-gnu/libgdk-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. :}

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

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.



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?!

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

On Mon, Sep 30, 2013 at 10:47:31AM +0200, Holger Hans Peter Freyther wrote:

Hi,

and one more information:

to make it worse.. the call-in will be suspended because it is
launching a debugger...

'Invalid index 13: index out of range'
SystemExceptions.IndexOutOfRange(Exception)>>signal (ExcHandling.st:254)
SystemExceptions.IndexOutOfRange class>>signalOn:withIndex: (SysExcept.st:665)
String(Object)>>checkIndexableBounds: (Object.st:798)
String>>at: (String.st:312)
String(SequenceableCollection)>>replaceFrom:to:with:startingAt: (SeqCollect.st:554)
String>>replaceFrom:to:with:startingAt: (String.st:296)
String(ArrayedCollection)>>copyFrom:to: (ArrayColl.st:236)
ReadStream(PositionableStream)>>copyFrom:to: (PosStream.st:156)
STInST.RBParser>>errorLine (Parser.star#VFS.ZipFile/RBParser.st:183)
STInST.RBParser>>parserError: (Parser.star#VFS.ZipFile/RBParser.st:207)
STInST.RBParser>>parseExpression (Parser.star#VFS.ZipFile/RBParser.st:153)
STInST.RBParser class>>parseExpression:onError: (Parser.star#VFS.ZipFile/RBParser.st:35)
STInST.RBParser class>>parseExpression: (Parser.star#VFS.ZipFile/RBParser.st:26)
UndefinedObject>>executeStatements (a String:1)
      6         ^self activateHandler: (onDoBlock isNil and: [ self isResumable ])

The question is.. is this a VisualGST issue or should the VM
be more robust against such deadlocks? I think we could have
a couple of

if (cur_state == STATE_DISPATCHING && blocking)  
    {
      event_loop_unlock ();
      return;
    }

in the vm, like in gst_interpret?

comments?

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

On Mon, Sep 30, 2013 at 11:33:24AM +0200, Holger Hans Peter Freyther wrote:

> to make it worse.. the call-in will be suspended because it is
> launching a debugger...

and one more issue..

(ip 10)[] in Debugger>>#stopInferior:
(ip 16)UnhandledException(Exception)>>#activateHandler:
(ip 24)ProcessTerminated(Exception)>>#resignalAs:
(ip 40)ProcessTerminated(Exception)>>#resignalAsUnhandled:
(ip 8)ProcessTerminated(Exception)>>#defaultAction
(ip 2)[] in Exception>>#instantiateDefaultHandler
(ip 16)ProcessTerminated(Exception)>>#activateHandler:
(ip 24)ProcessTerminated(Exception)>>#signal
(ip 14)ProcessTerminated class(InvalidValue class)>>#signalOn:
(ip 8)Process>>#resume
(ip 10)[] in Debugger>>#stopInferior:
(ip 16)MessageNotUnderstood(Exception)>>#activateHandler:
(ip 24)MessageNotUnderstood(Exception)>>#signal
(ip 20)UndefinedObject(Object)>>#doesNotUnderstand:
(ip 14)[] in Debugger>>#stopInferior:
(ip 12)<unwind> BlockClosure>>#on:do:
(ip 10)[] in Debugger>>#stopInferior:
(ip 48)[] in Process>>#onBlock:at:suspend:
(ip 12)<unwind> BlockClosure>>#on:do:
(ip 10)[] in Process>>#onBlock:at:suspend:
(ip 6)<unwind> BlockClosure>>#ensure:
(ip 6)[] in Process>>#onBlock:at:suspend:
(ip 42)[] in BlockClosure>>#asContext:
(ip 14)BlockContext class>>#fromClosure:parent:

so sometimes I manage to hit this kind of issue. I don't know how to
reproduce this yet. This time I was only using '1234' do: [:each | each ]
and debug it. down into the blockclosure. On the console the output is
looking like this:

Object: Process new "<0x40803de0>"Object: Process new "<0x40803de0>"Object: Process new "<0x40803de0>"Object: Process new "<0x40803de0>"Object: Process new "<0x40803de0>"Object: Process new "<0x40803de0>"Object: Process new....


_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

Il 30/09/2013 11:33, Holger Hans Peter Freyther ha scritto:
After some debugging with Holger, I think the problem is that VisualGST
is not handling the DebuggerReentered exception.

All invocations of #step, #finish: etc. should be wrapped with a
DebuggerReentered exception handler.  You can look at how MiniDebugger
does it.  MiniDebugger (and the Blox debugger too) creates a new
command-loop, but perhaps VisualGST can just change the window title or
something like that.

Paolo

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

On 03/10/2013 18:40, Paolo Bonzini wrote:
I've tried and it failed again but if I fork the debugger command

[ debugger next.
   self updateContext ] fork

and it grabs the exception without any problem

Gwen


_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

On Thu, Oct 03, 2013 at 06:40:21PM +0200, Paolo Bonzini wrote:

> All invocations of #step, #finish: etc. should be wrapped with a
> DebuggerReentered exception handler.  You can look at how MiniDebugger
> does it.  MiniDebugger (and the Blox debugger too) creates a new
> command-loop, but perhaps VisualGST can just change the window title or
> something like that.

It is certainly missing and will resolve the cascades of GtkDebugger's
popping up but it didn't fix the scheduling problem yet. I am not sure
what should happen with the call-in process (also just calling detach
on it didn't appear to fix it either).

I just tried STInST.RBParser parseExpression: '#(##(1/2) 1)' in blox
and clicked finish, it continues but ultimately ends in a segfault
too. :)

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk