[racket] Debugging a seg fault

[Chad Albers]

I working on a small test program using Jay McCarthy's zmq FFI bindings.

I'm getting a segfault with this message:

SIGSEGV MAPERR si_code 1 fault on addr 0x285

Is there any guidance on how to spot the cause? Here's what I have done so far
run racket with gdb - as gdb racket

In the gdb console...

handle SIGSEGV nostop
handle SIGSEGV noprint

(those last two seem to be necessary for my script to run at all)

And finally I run my racket file in gdb as follows
run -tm example.rkt

I then get this message, after my code actually starts:

SIGSEGV MAPERR si_code 1 fault on addr 0x285

Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffe77fe700 (LWP 20186)]
0x00007ffff713e1e5 in __GI_raise (sig=sig@entry=6)
at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.


The nice thing about this problem is that it is consistently reproducible.

Any advice?

Chad
____________________
Racket Users list:
http://lists.racket-lang.org/users

[Tobias Hammer]

My normal workflow for this (preferring post-mortem analysis because no
special flags for gdb required)

enable core dumps
> ulimit -c unlimited

> cat segv.rkt
#lang racket
(require ffi/unsafe)
(define _strlen (get-ffi-obj "strlen" #f (_fun _pointer -> _int)))
(_strlen #f)

> racket segv.rkt
SIGSEGV MAPERR si_code 1 fault on addr (nil)
Aborted (core dumped)

> gdb racket core

show backtrace
> bt

look for entries between "ffi_call_SYSV" and "<signal handler called>",
especially the first one after ffi_call_SYSV.
Use debug version of lib for exact infos (files, lines, arguments...)

Tobias


On Thu, 24 Oct 2013 09:54:05 +0200, Chad Albers <cal...@neomantic.com>
wrote: