[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Gwenaël Casaccio
Subject: Re: [Help-smalltalk] Add shortcuts to the visualgst/debugger
Date: Thu, 03 Oct 2013 22:08:44 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0

On 03/10/2013 18:40, Paolo Bonzini wrote:
Il 30/09/2013 11:33, Holger Hans Peter Freyther ha scritto:
On Mon, Sep 30, 2013 at 10:47:31AM +0200, Holger Hans Peter Freyther wrote:


and one more information:

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
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 (
SystemExceptions.IndexOutOfRange class>>signalOn:withIndex: (
String(Object)>>checkIndexableBounds: (
String>>at: (
String>>replaceFrom:to:with:startingAt: (
String(ArrayedCollection)>>copyFrom:to: (
ReadStream(PositionableStream)>>copyFrom:to: (
STInST.RBParser>>errorLine (
STInST.RBParser>>parserError: (
STInST.RBParser>>parseExpression (
STInST.RBParser class>>parseExpression:onError: 
STInST.RBParser class>>parseExpression: (
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 ();

in the vm, like in gst_interpret?

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.


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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]