Skip to content

core Matrix package segfaulted on R CMD check --use-gct

6 messages · Hin-Tak Leung, Martin Maechler, Douglas Bates

Original
Hin-Tak Leung
# 
Current core/Recommended Matrix package (0.999375-48) has been segfaulting against R 2.13-alpha/2.14-trunk for the last week or so (since R-2.13 was branched, when I started trying) when "run with R CMD check --use-gct":

--------------
Loading required package: lattice
Error : .onLoad failed in loadNamespace() for 'Matrix', details:
  call: fun(...)
  error: unprotected object (0x2768b18) encountered (was REALSXP)
Error: package/namespace load failed for 'Matrix'
Execution halted
---------------

I traced to this because "R CMD check --use-gct snpStats" (both 1.1.13 and 1.1.12) segfaults with the same message, and before that, the snpMatrix 1.15.8.4 which includes some of David's newly written ld() ( which depends on Matrix.)

If the Matrix package segfaults, David's new ld() isn't useable.
1 day later
Douglas Bates
# 
Can you provide the output from

sessionInfo()

so we can know the platform?  Also, did you configure R with
--enable-strict-barrier or set the C compilation flag
-DTESTING_WRITE_BARRIER?  I think that run-time error message can only
be thrown under those circumstances (not that it isn't an error, it's
just not checked for in other circumstances).
On Sat, Mar 26, 2011 at 5:21 PM, Hin-Tak Leung <hintak_leung at yahoo.co.uk> wrote:
Martin Maechler
# 
> Can you provide the output from sessionInfo()

    > so we can know the platform?  Also, did you configure R
    > with --enable-strict-barrier or set the C compilation flag
    > -DTESTING_WRITE_BARRIER?  I think that run-time error
    > message can only be thrown under those circumstances (not
    > that it isn't an error, it's just not checked for in other
    > circumstances).

interesting.

In the mean time, I *did* run --- for several hours! ---
your code example below,
and it did *not* segfault for me (64-bit, Linux Fedora 13).

Martin
> Can you provide the output from
    > sessionInfo()

    > so we can know the platform?  Also, did you configure R with
    > --enable-strict-barrier or set the C compilation flag
    > -DTESTING_WRITE_BARRIER?  I think that run-time error message can only
    > be thrown under those circumstances (not that it isn't an error, it's
    > just not checked for in other circumstances).
> On Sat, Mar 26, 2011 at 5:21 PM, Hin-Tak Leung <hintak_leung at yahoo.co.uk> wrote:
>> Current core/Recommended Matrix package (0.999375-48) has been segfaulting against R 2.13-alpha/2.14-trunk for the last week or so (since R-2.13 was branched, when I started trying) when "run with R CMD check --use-gct":
    >> 
    >> --------------
    >>> pkgname <- "Matrix"
    >>> source(file.path(R.home("share"), "R", "examples-header.R"))
    >>> gctorture(TRUE)
    >>> options(warn = 1)
    >>> library('Matrix')
    >> Loading required package: lattice
    >> Error : .onLoad failed in loadNamespace() for 'Matrix', details:
    >> ?call: fun(...)
    >> ?error: unprotected object (0x2768b18) encountered (was REALSXP)
    >> Error: package/namespace load failed for 'Matrix'
    >> Execution halted
    >> ---------------
    >> 
    >> I traced to this because "R CMD check --use-gct snpStats" (both 1.1.13 and 1.1.12) segfaults with the same message, and before that, the snpMatrix 1.15.8.4 which includes some of David's newly written ld() ( which depends on Matrix.)
    >> 
    >> If the Matrix package segfaults, David's new ld() isn't useable.
    >> 
    >>
Hin-Tak Leung
#
Martin Maechler wrote:
64-bit fedora 14. For building R svn (and checking soon-to-be-released R 
packages, rather than daily R-related work), I also have these, and indeed have 
"--enable-strict-barrier":

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

 > sessionInfo()
R version 2.14.0 Under development (unstable) (--)
Platform: x86_64-unknown-linux-gnu (64-bit)

locale:
  [1] LC_CTYPE=en_GB.UTF-8       LC_NUMERIC=C
  [3] LC_TIME=en_GB.UTF-8        LC_COLLATE=en_GB.UTF-8
  [5] LC_MONETARY=C              LC_MESSAGES=en_GB.UTF-8
  [7] LC_PAPER=en_GB.UTF-8       LC_NAME=C
  [9] LC_ADDRESS=C               LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_GB.UTF-8 LC_IDENTIFICATION=C

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base
 >
Douglas Bates
# 
On Tue, Mar 29, 2011 at 5:34 AM, Hin-Tak Leung
<htl10 at users.sourceforge.net> wrote:
Thanks for the information.  I can replicate the problem on a Red Hat
EL 5 64-bit system and will start to debug now.
1 day later
Douglas Bates
#
On Tue, Mar 29, 2011 at 2:17 PM, Douglas Bates <bates at stat.wisc.edu> 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.