From pleydell at supagro.inra.fr  Fri Sep  4 18:48:06 2009
From: pleydell at supagro.inra.fr (pleydell at supagro.inra.fr)
Date: Fri, 04 Sep 2009 18:48:06 +0200
Subject: [Rd] enabling core dumps
In-Reply-To: <4AA14290.1060401@fhcrc.org>
References: <20090904173944.et305vc9gon4480c@web.supagro.inra.fr>
	<20090904174842.rj5qh6kk93k8wg0k@web.supagro.inra.fr>
	<20090904181122.15h3os7s249w0o04@web.supagro.inra.fr>
	<4AA14290.1060401@fhcrc.org>
Message-ID: <20090904184806.lawwbqgs31n48wgw@web.supagro.inra.fr>

> usually what happens is (# meant to be a comment char)
>
>  % R -d gdb -f test.R
>  gdb> run
>  ...segfault happens, breaks into gdb
>  gdb> bt # print the backtrace
>  gdb> up # move up the stack, to get to 'your' frame
>  gdb> l # show source listing, use -O0 compiler flag, see gdb> help dir
>  gdb> print some_suspect_variable
>  gdb> call Rf_PrintValue(some_suspect_sexp)
>  gdb> break suspect_function
>  gdb> run # restart script, but break at suspect_function
>
> and so on, i.e., you've got all the info you need. A neat trick is to
> leave gdb running, repair and R CMD SHLIB your C code, return to gdb and
>
>  gdb> run
>
> to restart the same script but using the new shared lib (possibly
> preserving breakpoints and other debugging info you'd used in previous
> sessions).
>
> I'm a heavy emacs user but find it easier to stick with gdb from the
> shell -- one less layer to get in the way, when I'm confused enough as
> it is.

Wow! Thanks for the detailed reply, your approach makes perfect sense...

... especially given that my core file was for some unknown reason 0 
bytes which
gdb didn't find too funny.

cheers
David



[Rd] enabling core dumps
pleydell at supagro.inra.fr