From murdoch.duncan at gmail.com  Wed Jun 12 20:36:29 2013
From: murdoch.duncan at gmail.com (Duncan Murdoch)
Date: Wed, 12 Jun 2013 14:36:29 -0400
Subject: [Rd] load/unload segfault puzzle
In-Reply-To: <loom.20130612T194521-603@post.gmane.org>
References: <51B68579.6070505@mcmaster.ca>
	<loom.20130612T194521-603@post.gmane.org>
Message-ID: <51B8BFAD.3040604@gmail.com>

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



[Rd] load/unload segfault puzzle
Duncan Murdoch