Hi, I'm not a Racket expert, but I have a little experience with
core dumps.
If you compiled the interpreter yourself, no one else will be able to
do much with the core. But that's not the end of the world.
Do you have the source/debug info option turned on when compiling?
If not, recompile with that option turned on.
Next, do a "bt" command (backtrace) and send the result here.
If the stack is huge, as you suggest below, it could be a standard
stack overflow. A core won't be much help there, except to hint
at what arguments to the infinitely recurring function might be
producing it.
If this is random, also as you suggest, this is ugly. It is usually
reading unitialized memory somehow, possibly via a double free.
The best approach is using a tool like bounds checker or purify
or similar - they'll identify issues like this. I don't know if
Racket is set up to use any of these, but it would be a worthwhile
investment.
Finally, I would suggest resending to dev - they'll have more
familiarity with the underlying code.
John
On 5/2/2013 12:42 PM, Matthew Eric Bassett wrote:
Hi all,
It might be better to send this to dev@racket-lang. Then again, it
might be completely useless to them.
So we have a job scheduler program written in racket that handles
various places and tcp clients. This program sporadically and
inconsistently terminates with the following error message:
SIGSEGV MAPERR si_code 1 fault on addr 0x7fffb044ef48
We've caught the error at various different point of execution, but
can't consistently reproduce it (yet). We do have a core dump of the
program running and terminating from the racket repl (loaded with
"enter!") v 5.3.3. I've made it available via dropbox at
https://www.dropbox.com/s/rkd6pl511acll2r/core.12346.gz.
I don't have much experience reading core dumps, but it looks to me like
racket is hitting a stackoverflow in scheme_uncopy_stack in setjmpup.c.
In particular, at the first time scheme_uncopy_stack appears in the
stack with args scheme_uncopy_stack (ok=0, b=0x7f857b2b3510,
prev=0x7fffb044f5e0) we have:
(gdb) p prev
$1 = (intptr_t *) 0x7fffb044f5e0
(gdb) p *prev
$2 = 0
(gdb) p b
$3 = (Scheme_Jumpup_Buf *) 0x7f857b2b3510
(gdb) p *b
$4 = {stack_from = 0x0, stack_copy = 0x0, stack_size = 0, stack_max_size
= 0, cont = 0x0, buf = {jb = {{jb = {{
__jmpbuf = {0, 0, 0, 0, 0, 0, 0, 0}, __mask_was_saved = 0,
__saved_mask = {__val = {
0 <repeats 16 times>}}}}, stack_frame = 0}}, gcvs = 0,
gcvs_cnt = 0}, gc_var_stack = 0x0,
external_stack = 0x0}
scheme_uncopy_stack remains in the stack for several thousand frames.
The racket interpreter was compiled from source (so I don't know if
others can even read that coredump!) on a linux kernel
3.4.37-40.44.amzn1.x86_64 #1 SMP Thu Mar 21 01:17:08 UTC 2013 x86_64
x86_64 x86_64 GNU/Linux with glibc/-devel glibc-2.12-1.107.43.amzn1.x86_64.
I was able to capture the same error running from the MacOSX binaries
5.3.3 from racket-lang.org. That core dump is available at
https://www.dropbox.com/s/jfneqr4zlkmkjhh/core.41166.gz.
Is this an error in racket? IF not, do you have any suggestions on how
I can proceed in debugging this (I'm at a loss?) or even to figure out
which bits of my racket code to look at? (I've tried doing "info
locals" from gdb at various points in the stack, but I've not reached
enlightenment. Again, I have little experience with reading core dumps).
I've not included any of our racket code, as we don't know which part is
causing the problem.
Thanks for reading,
--
Matthew Eric Bassett | http://mebassett.info
____________________
Racket Users list:
http://lists.racket-lang.org/users
____________________
Racket Users list:
http://lists.racket-lang.org/users
