[gambit-list] Help With Memory

Marc Feeley 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
   % 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!


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
>>> http://chondestes.bio.unc.edu/svn/models/agjones
>    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

More information about the Gambit-list mailing list