plindsey@alpha.luc.ac.be writes:
> I just had a memory crash with R-0.64.1.
> I am running under intel pentium 200mhz under slackware linux 2.0.30.
>
> 1/home/plindsey >gdb /usr/local/src/R/bin/R.binary core
> GDB is free software and you are welcome to distribute copies of it
> under certain conditions; type "show copying" to see the
conditions.
> There is absolutely no warranty for GDB; type "show warranty" for
details.
> GDB 4.16 (i486-slackware-linux), Copyright 1996 Free Software Foundation,
Inc...
> Core was generated by `/usr/local/src/R-0.64.1/bin/R.binary --no-save
--no-restore --vsize 8000000 --nsob'.
> Program terminated with signal 11, Segmentation fault.
> Reading symbols from /usr/X11R6/lib/libSM.so.6...done.
> Reading symbols from /usr/X11R6/lib/libICE.so.6...done.
> Reading symbols from /usr/X11R6/lib/libX11.so.6...done.
> Reading symbols from /lib/libdl.so.1...done.
> Reading symbols from /lib/libncurses.so.3.0...done.
> Reading symbols from /lib/libm.so.5...done.
> Reading symbols from /lib/libc.so.5...done.
> Reading symbols from /lib/ld-linux.so.1...done.
> Reading symbols from
/usr/local/src/R-0.64.1/library/rmutil/libs/rmutil.so...done.
> Reading symbols from
/usr/local/src/R-0.64.1/library/mmdc33/libs/mmdc33.so...done.
> Reading symbols from
/usr/local/src/R-0.64.1/library/gnlm/libs/gnlm.so...done.
> #0 compactPhase () at memory.c:599
> 599 switch (TYPEOF(s)) { /* get size in bytes */
> (gdb) quit
Thanks for reporting, Pat, but reports like the above are essentially
useless because the memory corruption could be *anywhere*.
At the very least, we'd need a backtrace ('bt' command in gdb) to
see
what functions was involved. Even then, it may be difficult, because
the true damage may have been done by the *previous* garbage
collection.
The best thing would a simple example showing up the effect. This can
be difficult to create because things depend on the GC getting call at
the exact wrong moment. Turning on gctorture() can help with that by
forcing GC on any allocation, although it slows everything by three
orders of magnitude or so.
Another (even better) option would be if you could debug it yourself.
What I would do is to find the location of the "s" pointer which is
apparently getting overwritten and set a hardware watchpoint on it,
possibly conditionalised on the number of garbage collections.
However, that requires quite some knowledge of gdb.
--
O__ ---- Peter Dalgaard Blegdamsvej 3
c/ /'_ --- Dept. of Biostatistics 2200 Cph. N
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !) To:
r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._