Hello, first off, thanks for all of the previous help; hopefully someone
will have some insight on this question. I am attempting to track down a
segmentation fault which occurs only after a detach(2) is called in the
code (I have replaced the detach(2) with detach(package:DSA) and that
fails as well (furthermore, I have removed the detach calls and it does
not segfault)). It has proved difficult to track down (at least for me)
because it does not happen when the call is made, detach returns and
then some seconds (~ 30 seconds - 1 minute) later a segmentation fault
occurrs. I have run it in the debugger and the backtrace is below. When
I step through the code of do_detach it does not appear to be happening
at any consistent location. I assume this means that some worker thread
is involved, but the bactrace is not helpful (at least to me).
1.) Can I improve the backtrace message after the segfault to increase
message potential.
2.) Can I set some breakpoints elsewhere which might be more instructive
as I do not see much going on in do_detach? suggestions?
The library I am working with is in C and uses Nag, it uses the
registration facilities, although I have the problem when I do not use
the registration facilities. Specifically, I have defined the method:
void R_init_DSA(DllInfo *info). However, as I said if I comment this out
it appears to behave identically.
Also, I have run the whole test case using valgrind to see if I could
track down the problem there (I assume I am trashing some of R's memory)
however, the only messages I get from valgrind are below - all related
to the registration code. It does not appear to seg fault when I run it
in valgrind, but I have no idea why this would be the case as I am
*very* new to valgrind.
I am a little out of my league here so any help would be greatly
appreciated. OS and R version information is below. Thanks as always for
all of the help.
thanks, jim
> R.version
platform i686-pc-linux-gnu
arch i686
os linux-gnu
system i686, linux-gnu
status
major 2
minor 2.0
year 2005
month 10
day 06
svn rev 35749
language R
(gdb) backtrace
#0 0xb71655d0 in ?? ()
#1 0x0872fc70 in ?? ()
#2 0x0872fc58 in ?? ()
#3 0xb69b7ab8 in ?? ()
#4 0xb71654d5 in ?? ()
#5 0x00000000 in ?? ()
#6 0x00000000 in ?? ()
#7 0x4399ca09 in ?? ()
#8 0x00000000 in ?? ()
#9 0x00000000 in ?? ()
#10 0x00000000 in ?? ()
#11 0x0872fc18 in ?? ()
#12 0x08ee0fe0 in ?? ()
#13 0x00000000 in ?? ()
#14 0xb69c5c30 in __JCR_LIST__ () from /lib/tls/i686/cmov/libpthread.so.0
#15 0xb69b7b4c in ?? ()
#16 0xb69bcae0 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#17 0xb69bcae0 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#18 0xb7d09c9a in clone () from /lib/tls/i686/cmov/libc.so.6
-------------------------------------------------------------------------------------------------------------------------------------------
------------------------- valgrind output, after detach(.) is called
---------------------------------------------
-------------------------------------------------------------------------------------------------------------------------------------------
==20262== Conditional jump or move depends on uninitialised value(s)
==20262== at 0x1B92D888: R_getDLLRegisteredSymbol (Rdynload.c:665)
==20262== by 0x1B92D9C5: R_dlsym (Rdynload.c:735)
==20262== by 0x1B92D0BD: R_callDLLUnload (Rdynload.c:412)
==20262== by 0x1B92D15B: DeleteDLL (Rdynload.c:439)
==20262===20262== Conditional jump or move depends on uninitialised value(s)
==20262== at 0x1B92D8D2: R_getDLLRegisteredSymbol (Rdynload.c:681)
==20262== by 0x1B92D9C5: R_dlsym (Rdynload.c:735)
==20262== by 0x1B92D0BD: R_callDLLUnload (Rdynload.c:412)
==20262== by 0x1B92D15B: DeleteDLL (Rdynload.c:439)
==20262===20262== Conditional jump or move depends on uninitialised value(s)
==20262== at 0x1B92D8D7: R_getDLLRegisteredSymbol (Rdynload.c:681)
==20262== by 0x1B92D9C5: R_dlsym (Rdynload.c:735)
==20262== by 0x1B92D0BD: R_callDLLUnload (Rdynload.c:412)
==20262== by 0x1B92D15B: DeleteDLL (Rdynload.c:439)
==20262===20262== Conditional jump or move depends on uninitialised value(s)
==20262== at 0x1B92D8DB: R_getDLLRegisteredSymbol (Rdynload.c:696)
==20262== by 0x1B92D9C5: R_dlsym (Rdynload.c:735)
==20262== by 0x1B92D0BD: R_callDLLUnload (Rdynload.c:412)
==20262== by 0x1B92D15B: DeleteDLL (Rdynload.c:439)
==20262===20262== Conditional jump or move depends on uninitialised value(s)
==20262== at 0x1B92D8E0: R_getDLLRegisteredSymbol (Rdynload.c:696)
==20262== by 0x1B92D9C5: R_dlsym (Rdynload.c:735)
==20262== by 0x1B92D0BD: R_callDLLUnload (Rdynload.c:412)
==20262== by 0x1B92D15B: DeleteDLL (Rdynload.c:439)
==20262===20262== Conditional jump or move depends on uninitialised value(s)
==20262== at 0x1B92D8E4: R_getDLLRegisteredSymbol (Rdynload.c:711)
==20262== by 0x1B92D9C5: R_dlsym (Rdynload.c:735)
==20262== by 0x1B92D0BD: R_callDLLUnload (Rdynload.c:412)
==20262== by 0x1B92D15B: DeleteDLL (Rdynload.c:439)
==20262===20262== Conditional jump or move depends on uninitialised value(s)
==20262== at 0x1B92D8E9: R_getDLLRegisteredSymbol (Rdynload.c:711)
==20262== by 0x1B92D9C5: R_dlsym (Rdynload.c:735)
==20262== by 0x1B92D0BD: R_callDLLUnload (Rdynload.c:412)
==20262== by 0x1B92D15B: DeleteDLL (Rdynload.c:439)
==20262===20262== Conditional jump or move depends on uninitialised value(s)
==20262== at 0x1B92DA11: R_dlsym (Rdynload.c:749)
==20262== by 0x1B92D0BD: R_callDLLUnload (Rdynload.c:412)
==20262== by 0x1B92D15B: DeleteDLL (Rdynload.c:439)
==20262== by 0x1B92DD94: do_dynunload (Rdynload.c:863)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Jim, Can you send me a copy of the package and an R script that causes the problem and I'll take a look at it. D. James Bullard wrote:> Hello, first off, thanks for all of the previous help; hopefully someone > will have some insight on this question. I am attempting to track down a > segmentation fault which occurs only after a detach(2) is called in the > code (I have replaced the detach(2) with detach(package:DSA) and that > fails as well (furthermore, I have removed the detach calls and it does > not segfault)). It has proved difficult to track down (at least for me) > because it does not happen when the call is made, detach returns and > then some seconds (~ 30 seconds - 1 minute) later a segmentation fault > occurrs. I have run it in the debugger and the backtrace is below. When > I step through the code of do_detach it does not appear to be happening > at any consistent location. I assume this means that some worker thread > is involved, but the bactrace is not helpful (at least to me). > > 1.) Can I improve the backtrace message after the segfault to increase > message potential. > 2.) Can I set some breakpoints elsewhere which might be more instructive > as I do not see much going on in do_detach? suggestions? > > The library I am working with is in C and uses Nag, it uses the > registration facilities, although I have the problem when I do not use > the registration facilities. Specifically, I have defined the method: > void R_init_DSA(DllInfo *info). However, as I said if I comment this out > it appears to behave identically. > > Also, I have run the whole test case using valgrind to see if I could > track down the problem there (I assume I am trashing some of R's memory) > however, the only messages I get from valgrind are below - all related > to the registration code. It does not appear to seg fault when I run it > in valgrind, but I have no idea why this would be the case as I am > *very* new to valgrind. > > I am a little out of my league here so any help would be greatly > appreciated. OS and R version information is below. Thanks as always for > all of the help. > > thanks, jim > > > R.version > > platform i686-pc-linux-gnu > arch i686 > os linux-gnu > system i686, linux-gnu > status > major 2 > minor 2.0 > year 2005 > month 10 > day 06 > svn rev 35749 > language R > > > (gdb) backtrace > #0 0xb71655d0 in ?? () > #1 0x0872fc70 in ?? () > #2 0x0872fc58 in ?? () > #3 0xb69b7ab8 in ?? () > #4 0xb71654d5 in ?? () > #5 0x00000000 in ?? () > #6 0x00000000 in ?? () > #7 0x4399ca09 in ?? () > #8 0x00000000 in ?? () > #9 0x00000000 in ?? () > #10 0x00000000 in ?? () > #11 0x0872fc18 in ?? () > #12 0x08ee0fe0 in ?? () > #13 0x00000000 in ?? () > #14 0xb69c5c30 in __JCR_LIST__ () from /lib/tls/i686/cmov/libpthread.so.0 > #15 0xb69b7b4c in ?? () > #16 0xb69bcae0 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 > #17 0xb69bcae0 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 > #18 0xb7d09c9a in clone () from /lib/tls/i686/cmov/libc.so.6 > > ------------------------------------------------------------------------------------------------------------------------------------------- > ------------------------- valgrind output, after detach(.) is called > --------------------------------------------- > ------------------------------------------------------------------------------------------------------------------------------------------- > ==20262== Conditional jump or move depends on uninitialised value(s) > ==20262== at 0x1B92D888: R_getDLLRegisteredSymbol (Rdynload.c:665) > ==20262== by 0x1B92D9C5: R_dlsym (Rdynload.c:735) > ==20262== by 0x1B92D0BD: R_callDLLUnload (Rdynload.c:412) > ==20262== by 0x1B92D15B: DeleteDLL (Rdynload.c:439) > ==20262=> ==20262== Conditional jump or move depends on uninitialised value(s) > ==20262== at 0x1B92D8D2: R_getDLLRegisteredSymbol (Rdynload.c:681) > ==20262== by 0x1B92D9C5: R_dlsym (Rdynload.c:735) > ==20262== by 0x1B92D0BD: R_callDLLUnload (Rdynload.c:412) > ==20262== by 0x1B92D15B: DeleteDLL (Rdynload.c:439) > ==20262=> ==20262== Conditional jump or move depends on uninitialised value(s) > ==20262== at 0x1B92D8D7: R_getDLLRegisteredSymbol (Rdynload.c:681) > ==20262== by 0x1B92D9C5: R_dlsym (Rdynload.c:735) > ==20262== by 0x1B92D0BD: R_callDLLUnload (Rdynload.c:412) > ==20262== by 0x1B92D15B: DeleteDLL (Rdynload.c:439) > ==20262=> ==20262== Conditional jump or move depends on uninitialised value(s) > ==20262== at 0x1B92D8DB: R_getDLLRegisteredSymbol (Rdynload.c:696) > ==20262== by 0x1B92D9C5: R_dlsym (Rdynload.c:735) > ==20262== by 0x1B92D0BD: R_callDLLUnload (Rdynload.c:412) > ==20262== by 0x1B92D15B: DeleteDLL (Rdynload.c:439) > ==20262=> ==20262== Conditional jump or move depends on uninitialised value(s) > ==20262== at 0x1B92D8E0: R_getDLLRegisteredSymbol (Rdynload.c:696) > ==20262== by 0x1B92D9C5: R_dlsym (Rdynload.c:735) > ==20262== by 0x1B92D0BD: R_callDLLUnload (Rdynload.c:412) > ==20262== by 0x1B92D15B: DeleteDLL (Rdynload.c:439) > ==20262=> ==20262== Conditional jump or move depends on uninitialised value(s) > ==20262== at 0x1B92D8E4: R_getDLLRegisteredSymbol (Rdynload.c:711) > ==20262== by 0x1B92D9C5: R_dlsym (Rdynload.c:735) > ==20262== by 0x1B92D0BD: R_callDLLUnload (Rdynload.c:412) > ==20262== by 0x1B92D15B: DeleteDLL (Rdynload.c:439) > ==20262=> ==20262== Conditional jump or move depends on uninitialised value(s) > ==20262== at 0x1B92D8E9: R_getDLLRegisteredSymbol (Rdynload.c:711) > ==20262== by 0x1B92D9C5: R_dlsym (Rdynload.c:735) > ==20262== by 0x1B92D0BD: R_callDLLUnload (Rdynload.c:412) > ==20262== by 0x1B92D15B: DeleteDLL (Rdynload.c:439) > ==20262=> ==20262== Conditional jump or move depends on uninitialised value(s) > ==20262== at 0x1B92DA11: R_dlsym (Rdynload.c:749) > ==20262== by 0x1B92D0BD: R_callDLLUnload (Rdynload.c:412) > ==20262== by 0x1B92D15B: DeleteDLL (Rdynload.c:439) > ==20262== by 0x1B92DD94: do_dynunload (Rdynload.c:863) > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel- -- Duncan Temple Lang duncan at wald.ucdavis.edu Department of Statistics work: (530) 752-4782 371 Kerr Hall fax: (530) 752-7099 One Shields Ave. University of California at Davis Davis, CA 95616, USA -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (Darwin) iD8DBQFDmd1Z9p/Jzwa2QP4RAlsUAJ9C2NyYwUPQW3WkRf4TpRANoKhv0ACfSMxi TKpfiZg0JFYhFOPqvc67Bc4=5eTz -----END PGP SIGNATURE-----
Jim:
This reminds me of problems I've had before, but usually they occur when I
quit R
i.e. q(), because when testing and developing I can't remember actually
detaching
a package. I can however think of countless times I get a segmentation fault
upon
quiting R. Usually this boils down to a hidden return argumen that is given an
insufficient allocation of memory. For example
"foo" <- function(x, y, z){
nx <- length(x)
ny <- length(y)
nz <- length(z)
ans <- .C("bar",
x = as.double(x),
y = as.double(y),
z = as.double(z),
res1 = as.double(rep(0, nx)),
res2 = as.double(rep(0, nx*ny)),
PACKAGE = "FooBar")
list(result = asn$res1)
}
Notice that only ans$res1 is returned so that it is easy to forget about
ans$res2,
as I have often done! Now suppose that the C routine actually needs nx*ny*nz
space
(say) for the pointer to double at the position indicated by res2 instead of
just
the nx*ny provided. Although you would expect a segmentation fault at runtime,
it
is my experience that sometimes the function completes and the segmentation
fault
doesn't happen until I quit R.
I hope that these comments are helpful,
Grant Izmirlian,
NCI