I'm doing some work in C with the R_ExternalPointer interface, and having some seg fault problems. I expect the crash is my fault, bad pointer in my code causing a fault later etc, but I'm curious about the point of failure. R almost always falls over in a call to unzReadCurrentFile following a burst of disk activity. I'm definitely not doing anything that would call that explicitly, and I don't notice the bursts of disk activity in similar work without using my package. Any idea what might be causing a compressed file read? Something to do with lazy loading, maybe? I've tried disabling it in the package description without success. This is R 2.0.0 on NetBSD/i386. Mark <><
Extension provokes crash in unzReadCurrentFile
4 messages · Mark White, Brian Ripley, Peter Dalgaard
On Mon, 8 Nov 2004, Mark White wrote:
I'm doing some work in C with the R_ExternalPointer interface, and having some seg fault problems. I expect the crash is my fault, bad pointer in my code causing a fault later etc, but I'm curious about the point of failure. R almost always falls over in a call to unzReadCurrentFile following a burst of disk activity. I'm definitely not doing anything that would call that explicitly, and I don't notice the bursts of disk activity in similar work without using my package. Any idea what might be causing a compressed file read?
It's not a compressed file read, but rather from the interface for unz() connections to zip files. That is very unlikely to be used on a non-Windows system, so if that really is being called this looks like considerable internal corruption.
Something to do with lazy loading, maybe? I've tried disabling it in the package description without success. This is R 2.0.0 on NetBSD/i386.
Brian D. Ripley, ripley at 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
Prof Brian Ripley <ripley at stats.ox.ac.uk> writes:
On Mon, 8 Nov 2004, Mark White wrote:
I'm doing some work in C with the R_ExternalPointer interface, and having some seg fault problems. I expect the crash is my fault, bad pointer in my code causing a fault later etc, but I'm curious about the point of failure. R almost always falls over in a call to unzReadCurrentFile following a burst of disk activity. I'm definitely not doing anything that would call that explicitly, and I don't notice the bursts of disk activity in similar work without using my package. Any idea what might be causing a compressed file read?
It's not a compressed file read, but rather from the interface for unz() connections to zip files. That is very unlikely to be used on a non-Windows system, so if that really is being called this looks like considerable internal corruption.
Something to do with lazy loading, maybe? I've tried disabling it in the package description without success. This is R 2.0.0 on NetBSD/i386.
In any case, since you're obviously running a more than half-decent
operating system, and you seem to know how to operate the debugger
(gdb?), could you please tell us what the backtrace ("bt", if gdb)
says at the point of crash.
This can be very enlightening. Sometimes it requires more work because
things have been corrupted beyond recognition, in which case you need
to use breakpoints and stuff.
O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk) FAX: (+45) 35327907
On Mon, 8 Nov 2004, Mark White wrote:
Any idea what might be causing a compressed file read?
Prof Brian Ripley writes:
It's not a compressed file read, but rather from the interface for unz() connections to zip files. That is very unlikely to be used on a non-Windows system, so if that really is being called this looks like considerable internal corruption.
Peter Dalgaard writes:
In any case, since you're obviously running a more than half-decent
operating system, and you seem to know how to operate the debugger
(gdb?), could you please tell us what the backtrace ("bt", if gdb)
says at the point of crash.
Sure -- trace from a (fairly typical) core dump below.
However, I tentatively think I've found the problem now:
hearing that this func shouldn't be called at all gave me a
few other ideas. Changing the length of a large test vector
completely changed the top few functions in the trace, and I
then found an R_MakeExternalPtr with the wrong protection
argument, causing the GC to sometimes clear away the vector
before it was next accessed.
Haven't seen a crash since then, some hopefully that was it.
Thanks for your help.
Mark <><
--------------------------------------------------
(gdb) where
#0 0x80697c8 in do_attributesgets (call=0x1737d000, op=0x81fc5f0, args=0x0,
env=0x48371736) at attrib.c:744
#1 0x48371758 in ?? ()
#2 0x48371dd1 in ?? ()
#3 0x809c471 in unzReadCurrentFile (file=0x8ce4e7c, buf=0x8225d9c,
len=141386072) at dounzip.c:1248
#4 0x80acf7d in bcEval (body=0x8ce4e7c, rho=0x86d6e7c) at eval.c:2811
#5 0x80af0b9 in bcEval (body=0x8ce4e0c, rho=0x86d6e7c) at eval.c:3061
#6 0x80ae553 in bcEval (body=0x8ce4df0, rho=0x81fc040) at eval.c:3055
#7 0x80acdd7 in bcEval (body=0x8ce4df0, rho=0x86d6e7c) at eval.c:2808
#8 0x80ae518 in bcEval (body=0x8ce4f78, rho=0x81fd9c8) at eval.c:3055
#9 0x80acdd7 in bcEval (body=0x8ce4f78, rho=0x86d6e7c) at eval.c:2808
#10 0x80ad39e in bcEval (body=0x86d6ae0, rho=0x8de5f24) at eval.c:2884
#11 0x80d5b66 in nmmin (n=141388512, Bvec=0x8de5f24, X=0x86d6904,
Fmin=0x8dab894, fminfn=0x86d6894, fail=0x81fc7b0,
abstol=6.9523080897444509e-270, intol=5.8871398777326369e-266,
ex=0x86d6894, alpha=4.4536092707482937e-268, bet=8.1937066744817333e-267,
gamm=1.5190943468362191e-309, trace=2, fncount=0xbfbfc03c,
maxit=-1077951856) at optim.c:795
#12 0x80d6434 in lbfgsb (n=136004430, m=149385256, x=0x8b0e8b0, l=0x86d6904,
u=0x8dab894, nbd=0x8dab894, Fmin=0x81fc7b0, fminfn=0xbfbfc348,
fmingr=0x8dab894, fail=0x81fd8b0, ex=0x8b0e8b0,
factr=-NaN(0xffffa1bfb9000), pgtol=6.9650001374865742e-174,
fncount=0x8128faf, grcount=0x2, maxit=0, msg=0x8e77028 "??",
trace=-1077950876, nREPORT=20) at optim.c:1025
#13 0x80afb55 in bcEval (body=0x8b0e8b0, rho=0x81fd8b0) at eval.c:3063
#14 0x8129c6e in Rf_initialize_R (ac=145811632, av=0x81fd8b0) at system.c:170
#15 0x80acdd7 in bcEval (body=0x8b0e8b0, rho=0x8dab894) at eval.c:2808
#16 0x80aecad in bcEval (body=0x8b0e904, rho=0x81fdac4) at eval.c:3060
#17 0x80acdd7 in bcEval (body=0x8b0e904, rho=0x8dab894) at eval.c:2808
#18 0x80ae518 in bcEval (body=0x8b0e93c, rho=0x81fd9c8) at eval.c:3055
#19 0x80acdd7 in bcEval (body=0x8b0e93c, rho=0x8dab894) at eval.c:2808
#20 0x80ae0e4 in bcEval (body=0x8b0ea00, rho=0x81fc190) at eval.c:3052
#21 0x80acdd7 in bcEval (body=0x8b0ea00, rho=0x8dab894) at eval.c:2808
#22 0x80ae518 in bcEval (body=0x8b0e564, rho=0x81fd9c8) at eval.c:3055
#23 0x80acdd7 in bcEval (body=0x8b0e564, rho=0x8dab894) at eval.c:2808
#24 0x80ad39e in bcEval (body=0x8dac75c, rho=0x8b0e59c) at eval.c:2884
#25 0x80acff6 in bcEval (body=0x8dac75c, rho=0x822cae0) at eval.c:2812
#26 0x80ae518 in bcEval (body=0x8dac778, rho=0x81fd9c8) at eval.c:3055
#27 0x80acdd7 in bcEval (body=0x8dac778, rho=0x822cae0) at eval.c:2808
#28 0x80ae271 in bcEval (body=0x8dab824, rho=0x81fc1e4) at eval.c:3053
#29 0x80acdd7 in bcEval (body=0x8dab824, rho=0x822cae0) at eval.c:2808
#30 0x80c9a7d in Rf_allocVector (type=136497888, length=0) at memory.c:1787
#31 0x80c9bc7 in Rf_allocVector (type=136497888, length=0) at memory.c:1820
#32 0x80ca402 in Rf_protect (s=0x3001f) at memory.c:2074
#33 0x80ca41c in Rf_unprotect (l=0) at memory.c:2082
#34 0x805c3ad in do_getRtoCConverterDescriptions (call=0x1, op=0xbfbfd220,
args=0xbfbfd228, env=0x246) at CConverters.c:244
#35 0x805c1a0 in R_addToCConverter (matcher=0x1, converter=0xbfbfd220,
reverse=0xbfbfd228, userData=0x481c0bc0, desc=0x481cd200 "z??P??\001")
at CConverters.c:80
(gdb)