OK, time to call in the debugging cavalry... please recompile your Gambit like this:
% cp gsc/gsc non-debugged-gsc % ./configure CC="gcc -D___DEBUG_HOST_CHANGES" --enable-debug % make mostlyclean % make % cp non-debugged-gsc gsc/gsc # to avoid having a Gambit compiler with tracing
The combination of -D___DEBUG_HOST_CHANGES and --enable-debug will cause the runtime system to write a very detailed trace of the execution to the file "console" when a program linked with the runtime is run (including gsi/gsi).
Now recompile your program with gsc/gsc and execute your program (the important thing is to link with the new runtime in lib/libgambc.a, or to use the interpreter gsi/gsi to load your .o1 files). In a separate xterm do:
% cd your-working-directory % tail -f console
In this xterm you will see a detailed trace of what your program is doing. All the control transfers between Scheme procedures will be traced. Here's a sample output:
*** Entering ##write-char *** Entering ##write-substring (subprocedure 3) *** Entering ##kernel-handlers (subprocedure 2) *** Entering ##interrupt-handler *** Entering ##thread-heartbeat! *** Entering ##thread-check-devices! *** Entering ##os-condvar-select! *** Entering ##thread-check-devices! (subprocedure 1) *** Entering ##thread-heartbeat! (subprocedure 1) *** Entering ##thread-check-timeouts! *** Entering ##get-current-time! *** Entering ##thread-check-timeouts! (subprocedure 1) *** Entering ##thread-heartbeat! (subprocedure 2) *** Entering ##thread-yield!
This means that ##write-char was jumped to (probably a function call), and then ##write-substring was jumped to (probably a function return because it is a "subprocedure"), etc.
By looking at the tail of the trace you may get a better idea of what the Scheme code was doing when your problem occurs. Note that the extensive tracing slows down the program dramatically, so it may take a while for your program to reach the point where the problem occurs.
Happy debugging!
Marc
On 25-Sep-08, at 3:47 PM, Joel J. Adamson wrote:
"MF" == Marc Feeley feeley@iro.umontreal.ca writes:
MF> On 22-Sep-08, at 3:26 PM, Joel J. Adamson wrote:
Getting the code ================
The code is available for public download from svn at
MF> The following code is rather odd
This is exactly why I'm offering my code for review ;)
MF> What are you trying to accomplish?
My thinking was that the exception that causes the exception should be a noncontinuable exception and that I would want to enter the debugger at that point. I hope your question isn't asking me to defend my code ;) I'm learning this by trial-and-error and kind-review-by-people-who-know-way-more-than-me. I would much prefer that you tell me I'm dead wrong and doing it all wrong.
MF> I suggest you use this instead, to determine if it is causing MF> your problem:
MF> (define (mem-handler exc) (display-exception exc) (exit 1))
The problem happens regardless of whether the exception catcher is in effect.
Thanks, Joel -- Joel J. Adamson University of North Carolina at Chapel Hill CB #3280, Coker Hall Chapel Hill, NC 27599-3280
Before you reply to this email, please read http://www.unc.edu/~adamsonj/email-howto.html