[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