From ripley at stats.ox.ac.uk  Tue Aug 24 16:40:55 2004
From: ripley at stats.ox.ac.uk (Prof Brian Ripley)
Date: Tue Aug 24 16:40:58 2004
Subject: [Rd] Need help debugging R.
In-Reply-To: <644D9337A02FC24689647BF9E48EC39E08ABB87B@drm556>
Message-ID: <Pine.LNX.4.44.0408241536590.2117-100000@gannet.stats>

You need one of

1) gctorture(TRUE)

2) Run under valgrind to look for memory overruns.

and patience.  If it segfaults under gctorture you will probably see the 
real culprit via gdb.

I would try under R-devel, as quite a few memory problems have been 
plugged there.  Or at least under R-patched (ditto, but not quite all 
those in R-devel).

On Tue, 24 Aug 2004, Samuelson, Frank* wrote:

> 
> I originally posted this to R-help, but here is probably a better place.
> 
> I have a rather complex routine which works great in R.
> Then I bootstrap it.  After running a few minutes it typically segfaults,
> though it happens very randomly.
> This happens w/ 1.9.0 and 1.9.1 on Fedora1 and a Scyld (RH7.3) system.
> Traces always point back to routines in src/main/memory.c, though often
> not the same routines.
> 
> Now for the strangeness:
> It's never the same routines that appear in the trace.  
> The trace gives sequential routine names that aren't called 
> by previous routines.  Almost none of the variable names print in gdb.
> 
> I've even tried turning optimizations all the way off
> and setting -g3 and I get the same problems.
>  
> Are there any important things I should know about debugging R
> that I'm not doing?  Is this just total memory corruption? 
> 
> 
> For what it's worth a sample trace below:
> (gdb) where
> #0  0x00a22096 in _int_free () from /lib/tls/libc.so.6
> #1  0x00a2101b in free () from /lib/tls/libc.so.6
> #2  0x080d632a in R_SetPPSize ()
> #3  0x080d7d13 in do_regFinaliz ()
> #4  0x080d9503 in do_gctime ()
> #5  0x080d8fcb in Rf_allocVector ()
> #6  0x080a9f7f in Rf_duplicate ()
> #7  0x080aa18c in Rf_duplicate ()
> #8  0x080b7b28 in R_execMethod ()
> #9  0x080b8a0f in do_function ()
> #10 0x080b8bf9 in do_function ()
> #11 0x080b70b7 in Rf_eval ()
> #12 0x080b87a5 in do_begin ()
> #13 0x080b70b7 in Rf_eval ()
> #14 0x080b80b1 in do_for ()
> #15 0x080b70b7 in Rf_eval ()
> #16 0x080b87a5 in do_begin ()
> #17 0x080b70b7 in Rf_eval ()
> #18 0x080b70b7 in Rf_eval ()
> #19 0x080b87a5 in do_begin ()
> #20 0x080b70b7 in Rf_eval ()
> #21 0x080b73c3 in Rf_applyClosure ()
> #22 0x080e03b4 in do_internal ()
> #23 0x080e0b37 in Rf_usemethod ()
> #24 0x080b9f34 in Rf_DispatchOrEval ()
> #25 0x0813b48b in do_subset ()
> #26 0x09fe39f0 in ?? ()
> #27 0x081d620b in _length_code ()
> #28 0x0be7aa5c in ?? ()
> #29 0x0c05a050 in ?? ()
> #30 0xbff046a8 in ?? ()
> 
> ______________________________________________
> R-devel@stat.math.ethz.ch mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
> 
> 

-- 
Brian D. Ripley,                  ripley@stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595


[Rd] Need help debugging R.
Prof Brian Ripley