[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