[gambit-list] Tracking Down a Segfault

Mikael More mikael.more at gmail.com
Thu Sep 4 17:34:42 EDT 2008


2008/9/4 Joel J. Adamson <adamsonj at email.unc.edu> <adamsonj at email.unc.edu>

> Dear Gambit-List,
>
> I've been accumulating a library of functions for simulating population
> processes (called "genxic"), and I'm running into some pesky errors.
> This code includes quite a lot of foreign functions, interfacing with
> the GNU Scientific Library.
>
> 1)  When running numerically intense simulations, I'll get a segfault:
>
> ,----
> | Process scheme segmentation fault
> `----
>
> This might be after 50 iterations of a simulation when I'd planned to do
> 1152.
>
> Where do I go from there?  I've tried running gsc and gsi in GDB, but
> pretty often I can't get a backtrace after the segfault.  The conditions
> under which the segfault occurs varies.  Sometimes I get it after
> loading the library.


Recompile Gambit with debug options flipped on:

Unpack the Gambit sources.

Run ./configure --enable-single-host

(Should we flip on --enable-debug here also ?? )

Replace the two occurrences -O1 in Makefile with -O0 -g (more important than
-O0 is -g, I heard a rumor that debugging info may be better if you do -O1
-g but have no idea).

make; make install

Ensure your sourcecode is compiled with (declare (safe)) (that's the default
setting). I don't remember if the -O0 -g will be reflected to gcc/g++ when
you do compile-file from within your app, so consider adding this to cc-opts
of compile-file.


>
>
> 2)  I've gotten this bizarre error from one of my procedures, and would
> like to know where to go to debug it:
>
> ,----
> | *** ERROR IN | genxic.o1#31| -- (Argument 1) F64VECTOR expected
> | (f64vector-ref
> |  '#u16(47806 51966 47806 51966 47806 51966 47806 51966 47806 51966 47806
> 519...
> |  1)
> `----
>
> I am not initializing any u16 vectors (that I know of), so how can I
> tell where this comes from, and how do I investigate, or find what
> procedure genxic.o1#31 is?  I tried repeating the compilation, and this
> is what I got
>
> Dumping:
>  #<primitive | genxic.o2|>
>  #<primitive | genxic.o2#0|>
>  #<primitive | genxic.o2#1|>
>  #<primitive | genxic.o2#2|>
>  #<primitive | genxic.o2#3|>
> ...
>  #<primitive | genxic.o2#30|>
>  #<primitive | genxic.o2#31|>
>  #<procedure 1+>
>  #<procedure 1->
>  #<procedure atom?>
>  #<procedure xcons>
>  #<procedure make-list>...
>
> How are these procedures labeled, and how do I figure out which one it
> is?


Using the instructions above, this should be fixed.

In order to track down the source of your bugs, it may be important for you
to note that

 - Throwing exceptions with no handler/catcher may sigsegv your app.

 - You should presuppose that ___argXX variables inside Scheme-to-C calls
are trashed after C-to-Scheme calls. I.e.: If you have declared a c-define
or c-lambda that takes parameters, these will appear as ___arg0, ___arg1
etc. in the C code of the c-define / c-lambda. These will have correct
contents all until you invoke Scheme functions from the C code. not
afterwards. So back them up to the stack if you do.

 - Ensure you didn't call the version of any Gambit-internal function with
broken parameters. The names of them start with ##. Very simple example:

>(cadr 4)
*** ERROR IN (console)@3.1 -- (Argument 1) PAIR expected
(cadr 4)
1>
>(##cadr 4)
/usr/local/bin/gsc: line 5: 17999 Segmentation fault

If your problems persist, ask the list further.

M
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.iro.umontreal.ca/pipermail/gambit-list/attachments/20080904/bc5a09f6/attachment.htm>


More information about the Gambit-list mailing list