[Rd] load/unload segfault puzzle
Duncan Murdoch
murdoch.duncan at gmail.com
Wed Jun 12 20:36:29 CEST 2013
On 13-06-12 1:47 PM, Ben Bolker wrote:
> Ben Bolker <bbolker <at> gmail.com> writes:
>
>>
>>
>> Dear r-devel readers,
>>
>> I have a pretty deep problem with package loading and unloading in
>> the development version of the lme4 package
>> <https://github.com/lme4/lme4>; it's not boiled down to a properly
>> minimal example yet (this has been difficult), but I am posting anyway
>> in the hopes that someone has ideas about how to proceed farther,
>> since I'm nearly stumped. Apologies in advance for the long post.
>>
>> EXECUTIVE SUMMARY: after one cycle of loading, testing (e.g. by
>> running example(lmer)) and unloading lme4, then loading and unloading
>> the nlme package, re-loading and exercising lme4 becomes very
>> unstable, leading eventually to a segmentation fault. More detail is
>> available at <https://github.com/lme4/lme4/issues/35> . Because it's
>> a segmentation fault, exactly _where_ the crash happens varies a bit
>> according to platform and precise incantation, but it seems I can
>> always get a segfault eventually.
>>
>
> [snip]
>
> UPDATE: after some useful advice off-list, I tried with a
> fully valgrind-instrumented version of R. No suspicious memory
> accesses occurred until the very end, right before the crash:
>
> Attempt #1
> loading lme4
> loaded DLLs: Rcpp RcppEigen minqa lme4
> detaching lme4
>
>
> ==18150== Jump to the invalid address stated on the next line
> ==18150== at 0x9E46D00: ???
> ==18150== by 0x410AB8A: RunFinalizers (memory.c:1357)
> ==18150== by 0x410D314: R_gc_internal (memory.c:2709)
> ==18150== by 0x410E73C: Rf_allocVector (memory.c:2421)
> ==18150== by 0x4153D30: ReadItem (serialize.c:1685)
> ==18150== by 0x4152D6D: ReadBC1 (serialize.c:1825)
> ==18150== by 0x4153983: ReadItem (serialize.c:1851)
> ==18150== by 0x41531C0: ReadItem (serialize.c:1601)
> ==18150== by 0x41531A1: ReadItem (serialize.c:1599)
> ==18150== by 0x41531C0: ReadItem (serialize.c:1601)
> ==18150== by 0x41531C0: ReadItem (serialize.c:1601)
> ==18150== by 0x41531C0: ReadItem (serialize.c:1601)
> ==18150== Address 0x9e46d00 is not stack'd, malloc'd or (recently) free'd
> ==18150==
>
> Does this suggest anything to anyone, or is it just the
> final symptom of a mysterious problem that occurred earlier ... ?
Have you registered a finalizer on any of your objects? The trace
indicates that the garbage collector was trying to run one, and the
registered address was invalid. If your R version is the same as the
current R-devel or R-patched memory.c, this is on a line that is running
R_WeakRefFinalizer, but the message doesn't look exactly right for that:
it looks as though it is asking for an indirect jump to 0x9E46D00, and
the current line memory.c:1357 doesn't do that.
Duncan Murdoch
More information about the R-devel
mailing list