[racket] Debugging a seg fault

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 <calbers at neomantic.com>  
wrote:

> 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 at 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