[gambit-list] Help With Memory
feeley at iro.umontreal.ca
Thu Sep 25 18:40:33 EDT 2008
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
% cp non-debugged-gsc gsc/gsc # to avoid having a Gambit compiler
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
% 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.
On 25-Sep-08, at 3:47 PM, Joel J. Adamson wrote:
>>>>>> "MF" == Marc Feeley <feeley at 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
> 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
> 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
More information about the Gambit-list