[Rd] segfault following a detach
Duncan Temple Lang
duncan at wald.ucdavis.edu
Fri Dec 9 20:39:05 CET 2005
-----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-----
More information about the R-devel
mailing list