enabling core dumps

not really answering your question, but I find it more useful to

R -d gdb

or

R -d gdb -f test.R

where test.R reproduces the bug in some minimal code. A variant is

R -d valgrind -f test.R

if the memory problem is not easy to spot.

Thanks for your reply Martin

Yes, I have used that route before, I have also been playing with  
the emacs "M-x
gdb" option as describe in the R FAQ. But having no first hand  
expertience with
core dumps I am curious why you prefer the -d flag route. Perhaps  
I'm wrong but
I thought examining a core dump enables you to backtrace from the  
moment things
went wrong, this seems to be a useful trick to have...

.. this is the same with gdb - the core dump just saves the same state  
that you have at the point where gdb comes in. The only practical  
difference (I'm aware of) is that with core dump you can repeatedly re- 
start your analysis back to the point of crash without running all the  
code that has lead to it at the cost of storing the entire memory  
content (which can be huge these days so often using gdb is sufficient  
and faster...).

... if you manage to enable the core dump option that is.

ulimit -c unlimited
is the right way, but you a) have to have rights to do than and b) the  
kernel must have core dumps enabled. On Debian I have no issue:

urbanek at corrino:~$ ulimit -c unlimited
urbanek at corrino:~$ R --slave < segfault.R

  *** caught segfault ***
address 0x3, cause 'memory not mapped'

Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
Selection: 1
aborting ...
Segmentation fault (core dumped)

Note the "core dumped" in the last line. Also some systems put core  
dumps in a dedicated directory, not in the current one. If in doubt,  
google for core dumps and your distro - this is not really an R  
issue ...

Cheers,
Simon