segfault debugging

On 12-12-01 6:56 AM, Donatella Quagli wrote:

Thank you so far. Here is an excerpt from the gdb session after a crash:
   Program received signal SIGSEGV, Segmentation fault.

   0xb7509a6b in Rf_allocVector () from /usr/lib/R/lib/libR.so
   (gdb) backtrace
   #0  0xb7509a6b in Rf_allocVector () from /usr/lib/R/lib/libR.so
   #1  0xb744b64c in ?? () from /usr/lib/R/lib/libR.so
   #2  0xb74c58bf in ?? () from /usr/lib/R/lib/libR.so
   #3  0xb74c9c62 in Rf_eval () from /usr/lib/R/lib/libR.so
   #4  0xb74ce60f in Rf_applyClosure () from /usr/lib/R/lib/libR.so
   #5  0xb74c9f29 in Rf_eval () from /usr/lib/R/lib/libR.so
   #6  0xb7503002 in Rf_ReplIteration () from /usr/lib/R/lib/libR.so
   #7  0xb7503298 in ?? () from /usr/lib/R/lib/libR.so
   #8  0xb7503812 in run_Rmainloop () from /usr/lib/R/lib/libR.so
   #9  0xb7503839 in Rf_mainloop () from /usr/lib/R/lib/libR.so
   #10 0x08048768 in main ()
   #11 0xb728de46 in __libc_start_main (main=0x8048730 <main>, argc=8,
ubp_av=0xbfdb7824, init=0x80488a0 <__libc_csu_init>,
       fini=0x8048890 <__libc_csu_fini>, rtld_fini=0xb7784590,
stack_end=0xbfdb781c) at libc-start.c:228
   #12 0x08048791 in _start ()

It seems to me that the error is in frame #0. Does it mean that there is a bug
in libR.so?  What can I do next?

It means that the error was detected when trying to do a memory allocation.
That could be a bug in R, but more likely something else has damaged the memory
management system structures, e.g. a function writing to memory that it doesn't
own.

Bugs like this are hard to track down, because the damage could have occurred a
long time before it showed up, and small changes to your script could affect it.

I would try to narrow it down to a single statement in your script.  You might
be able to deduce that from the last line printed before the crash.  If you
don't have any printing, you could try adding some, but as I mentioned above,
that might make the bug behave differently.

Another approach is to cut off statements at the end of your script. That
probably won't affect the bug until you cut off the statement that actually
triggered it (but it might, which is why this kind of bug is so frustrating to
track down).

If you find the bad statement, then look at calls to external code in it, or
recently executed before it.  See if any of them look like they contain errors.
Common errors are to write to an array without allocating it, or to write beyond
the bounds of an array, or (in .Call() code) to allocate something and then fail
to protect it from garbage collection.

You could also figure out what the problem is that caused the seg fault in frame
0.  It might be because some particular variable contains a garbage value.  Then
in a new run, you can ask gdb to break when that memory location takes on the
garbage value.  This is usually effective if you really can identify the bad
value, but doing that can be hard, especially when you aren't familiar with how
things normally work.

Good luck!

Duncan Murdoch