[gambit-list] Remote debugger problem

Marc Feeley feeley at iro.umontreal.ca
Thu Jul 2 12:10:56 EDT 2009


On 1-Jul-09, at 12:07 AM, James Long wrote:

> Hey Marc (and other Gambit folks, I realized this would be good for
> the gambit list too),
>
> Your remote debugger is awesome.  However, it travels further into the
> land of Gambit IO than I know.  I'm having one problem with it (I got
> the latest version of it).
>
> I found a rather concise example of the problem.  It seems that when
> two errors happen close enough in time, one remote debugger pops open
> with the correct error, and another pops open with this error:
>
> *** ERROR IN rdi-open-client,
> "Users/james/projects/scheme/gambit-iphone-example/lib/util/remote- 
> debugger/rdi.scm"@108.5
> -- Broken pipe
> (force-output '#<input-output-port #3 (tcp-client "localhost" 20000)>)
>>
>
> You can get it to do this by just doing this in the debugee:
>
> (thread-start!
> (make-thread
>  (lambda ()
>    (/ 1 0))))
>
> (thread-start!
> (make-thread
>  (lambda ()
>    (/ 1 0))))
>
> Would you mind looking at it?

I couldn't reproduce this on Mac OS X.  It looks like a race condition.

>
> As a separate subject, as I was integrating the remote debugger with
> my iphone app, I realized I can not only have access to the debugger
> from the iphone, but I can also fire up a main REPL and interactively
> develop from my main computer on the iphone!  That is very cool.
>

It puts the "remote" in "remote debugger"!

> Now, I can't call (##repl-debug-main) in the primordial thread, as
> your proof of concept does, because the main thread is the program
> which needs to continue executing.  So, my first attempt fired up the
> REPL from a child thread instead:
>
> (thread-start!
> (make-thread
>  (lambda () (##repl-debug-main))))
>
> Do you see any problems with this?  This seems to work fine (a real
> Gambit REPL pops open in an xterm when the app start in the iphone
> simulator).  This got me thinking too: what is the relationship
> between stdin and stdout and the main REPL?  It seems that standard
> output is somehow redirected to this REPL.  Rather, if I call DISPLAY
> on any other thread it somehow appears in my above REPL.  How is that
> so?

There are several ports that have a similarity with the concepts of  
"standard input" and "standard output".  Here is a breakdown:

##stdin-port           actual standard input of the process
##stdout-port          actual standard output of the process
(current-input-port)   current input port
(current-output-port)  current output port
(repl-input-port)      this thread's REPL input port
(repl-output-port)     this thread's REPL output port
(console-port)         the console's bidirectional port

The REPL input/output ports are normally connected to the console (/ 
dev/tty on Unix, a Windows console on Windows, etc).  When a thread  
calls (##repl-debug-main) the parameter objects current-input-port and  
current-output-port are dynamically bound to the REPL input/output  
ports, for the duration of the REPL.  This explains why a (display  
"foo") will output to the console (because the port parameter of  
display defaults to (current-output-port) as requested by the Scheme  
standard).  Note that when a thread is created with make-thread it  
inherits the current-input-port and current-output-port bindings of  
the parent thread, that's why display's output will go to the REPL of  
the thread that called ##repl-debug-main, if the thread is a  
descendant of that thread.

Note that the default port for "pp" is the repl-output-port.  This is  
consistent with pp's debugging purpose.  So I suggest you try to limit  
yourself to using pp, or explicitly pass (repl-output-port) to the  
output procedure you are using when debugging.

Marc




More information about the Gambit-list mailing list