[Rd] core Matrix package segfaulted on R CMD check --use-gct

[Martin Maechler]

>>>>> "HL" == Hin-Tak Leung <htl10 at users.sourceforge.net>
>>>>>     on Thu, 07 Apr 2011 19:31:35 +0100 writes:

    HL> Martin Maechler wrote:
    >>>>>>> Martin Maechler <maechler at stat.math.ethz.ch> on Thu,
    >>>>>>> 7 Apr 2011 12:24:32 +0200 writes:
    >> 
    >>>>>>> "HL" == Hin-Tak Leung <htl10 at users.sourceforge.net>
    >>>>>>> on Thu, 7 Apr 2011 07:51:44 +0100 writes:
    >> 
    HL> Douglas Bates wrote:
    >> >>> I isolated the problem and tested then committed a
    >> fix. I am >>> going to ask Martin to upload the new
    >> release as I have gotten >>> out of sync with some of his
    >> recent changes and he will, I >>> hope, reconcile the
    >> branches and trunk.  If you need the fixed >>> version
    >> immediately, say for testing, the changes are in the >>>
    >> file Matrix/src/chm_common.c You can visit the SVN
    >> archive for >>> the project,
    >> https://r-forge.r-project.org/scm/?group_id=61, >>> click
    >> on the link to Browse Subversion Repository and go to >>>
    >> pkg/Matrix/src/chm_common.c
    >> >>> 
    >> >>> I made the mistake that I chastised others for
    >> making, >>> performing an operation on the result of a
    >> call to install and >>> another value that may have
    >> required allocation of memory.  >>> The first time
    >> install is called on a particular string it >>> allocates
    >> and SEXPREC, which may cause a garbage collection.
    >> 
    HL> Matrix-for-R-2.13 at 2659 (0.999375-49) has the problem at
    HL> a different place:
    >> 
    >> Are you sure that you really took 0.999375-49 and not its
    >> predecessor ???

    HL> The two errors look similiar but different (the previous
    HL> one was about a REALSXP), and both are fairly
    HL> reproducible.

well, in my experience such problems typically don't show
exactly at the same place, and so the exact instance at which
an unprotected object is GC'ed also changes, and
hence I guesed it could be a REALSXP once and an INTSXP next
time.

    HL> As much as I can be sure, I guess. I overwrote
    HL> src/library/Recommended and library/Matrix to be sure.

???  But  the prerelease version of R-2.13.0 *contains* already
Matrix_0.999375-49  the one you claim has the bug.

[[and you still haven't told use the exact R version you were using]]

    >> I haven't been able to reproduce the problem (on 32-bit
    >> Linux, R-2.13.0 RC, after running your code snippet below
    >> for a couple of hours, I got the prompt back, and things
    >> continued working..)  and Doug Bates has had a strong
    >> suspicion that the error message below looks like the
    >> problem that he fixed just between *-48 and *-49.
    >> 
    >> >>> pkgname <- "Matrix" >>>
    >> source(file.path(R.home("share"), "R",
    >> "examples-header.R")) >>> gctorture(TRUE) >>>
    >> options(warn = 1) >>> options(error=dump.frames) >>>
    >> library('Matrix')
    >> 
    HL> Loading required package: lattice Error in
    HL> regexpr("package:", envName, fixed = TRUE) : unprotected
    HL> object (0x2fe5818) encountered (was INTSXP) Error:
    HL> package/namespace load failed for 'Matrix'
    >> 
    >> Can you give more exact info about the platform ?

    HL> fedora 14 x86_64.

 > export DEFS='-DUSE_TYPE_CHECKING_STRICT -DR_MEMORY_PROFILING'
 > ./configure --enable-memory-profiling --enable-strict-barrier \
 >   --enable-byte-compiled-packages --with-valgrind-instrumentation=2

aah, ok.  Well of course that's not an R version I just have at
my disposal ... ... but I'm building it now 
(for R-2.13.0 "RC", i.e. the R-2-13-branch in R's subversion
tree, revision 55350), and start your test - with R's  own
(=CRAN's) "Matrix" before finishing for today.


    HL> Matrix-for-R-2.13 at 2659 was the one I was playing with.
    HL> I am currently testing Matrix trunk at 2666, since you
    HL> seems to have put something relevant in r2661.

That was really something else, also an important clean up step,
but entirely unrelated to protection and garbage collection...
and ... that version will definitely not make it into R-2.13.0
since it has too many changes compared with the one R-2.13.0
"RC" has been shipping with.

Martin