From bates at stat.wisc.edu  Wed Mar 30 22:03:34 2011
From: bates at stat.wisc.edu (Douglas Bates)
Date: Wed, 30 Mar 2011 15:03:34 -0500
Subject: [Rd] core Matrix package segfaulted on R CMD check --use-gct
In-Reply-To: <AANLkTimuxb199-32D+043u9fNp7VsDjf5QD2qX3_Zjof@mail.gmail.com>
References: <255683.81856.qm@web29515.mail.ird.yahoo.com>
	<AANLkTimDJbJ-u3wXOyvPB0EePf98AZ-R5duKVr+Guh-v@mail.gmail.com>
	<19856.40809.236979.731769@stat.math.ethz.ch>
	<4D91B5CC.1040500@users.sourceforge.net>
	<AANLkTimuxb199-32D+043u9fNp7VsDjf5QD2qX3_Zjof@mail.gmail.com>
Message-ID: <AANLkTi=Tjjq9JtuzYp8x4Pp=gtg2eGT7C6RoaXehmX_W@mail.gmail.com>

On Tue, Mar 29, 2011 at 2:17 PM, Douglas Bates <bates at stat.wisc.edu> wrote:
> On Tue, Mar 29, 2011 at 5:34 AM, Hin-Tak Leung
> <htl10 at users.sourceforge.net> wrote:
>> Martin Maechler wrote:
>>>>>>>>
>>>>>>>> Douglas Bates <bates at stat.wisc.edu>
>>>>>>>> ? ?on Mon, 28 Mar 2011 09:24:39 -0500 writes:
>>>
>>> ? ?> 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
>>
>> 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
>
> Thanks for the information. ?I can replicate the problem on a Red Hat
> EL 5 64-bit system and will start to debug now.

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.
>>>>>>>> Douglas Bates <bates at stat.wisc.edu>
>>>>>>>> ? ?on Mon, 28 Mar 2011 09:24:39 -0500 writes:
>>>
>>> ? ?> 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.
>>> ? ?>> ? ? >>
>>
>



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