Re: [Rd] repeatable segfault - on Mac
> David Winsemius
> on Tue, 6 Sep 2011 00:38:13 -0400 writes:
> I can reproduce:
> eigen(crossprod(matrix(1:2000, 50)) + (0+0i), T, T)
> *** caught segfault ***
> address 0x102d0e028, cause 'memory not mapped'
> Traceback:
> 1: .Call("La_rs_cmplx", x, only.values, PACKAGE = "base")
> 2: eigen(crossprod(matrix(1:2000, 50)) + (0 + (0+0i)), T, T)
> ## after restart
>> sessionInfo()
> R version 2.13.1 (2011-07-08)
> Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit)
> locale:
> [1] en_US.UTF-8/en_US.UTF-8/C/C/en_US.UTF-8/en_US.UTF-8
> attached base packages:
> [1] stats graphics grDevices utils datasets methods base
> With OSX 10.5.8
> Also happens with 32 bit R
> [R.app GUI 1.41 (5874) i386-apple-darwin9.8.0]
It does not happen on Linux (different versions)
nor Windows (2.13.1 patched, early August).
As this is calling LAPACK code,
I guess that this is yet another case where the Mac version
of optimized BLAS / LAPACK is playing wrongly.
Martin Maechler
> David Winsemius
> On Sep 6, 2011, at 12:12 AM, robin hankin wrote:
>> Hi. macosx 10.6.8
>>
>> With R-2.13.1 and also revision 56948 I get the following repeatable
>> segfault:
>>
>>
>>
>> wt118:~% R --vanilla --quiet
>>> R.Version()
>> $platform
>> [1] "x86_64-apple-darwin9.8.0"
>>
>> $arch
>> [1] "x86_64"
>>
>> $os
>> [1] "darwin9.8.0"
>>
>> $system
>> [1] "x86_64, darwin9.8.0"
>>
>> $status
>> [1] ""
>>
>> $major
>> [1] "2"
>>
>> $minor
>> [1] "13.1"
>>
>> $year
>> [1] "2011"
>>
>> $month
>> [1] "07"
>>
>> $day
>> [1] "08"
>>
>> $`svn rev`
>> [1] "56322"
>>
>> $language
>> [1] "R"
>>
>> $version.string
>> [1] "R version 2.13.1 (2011-07-08)"
>>
>>> eigen(crossprod(matrix(1:2000, 50)) + (0+0i), T, T)
>>
>> *** caught segfault ***
>> address 0x1038000a8, cause 'memory not mapped'
>>
>> Traceback:
>> 1: .Call("La_rs_cmplx", x, only.values, PACKAGE = "base")
>> 2: eigen(crossprod(matrix(1:2000, 50)) + (0 + (0+0i)), T, T)
>>
>> Possible actions:
>> 1: abort (with core dump, if enabled)
>> 2: normal R exit
>> 3: exit R without saving workspace
>> 4: exit R saving workspace
>> Selection: 2
>> wt118:~%
>>
>>
>>
>>
>>
>> --
>> Robin Hankin
>> Uncertainty Analyst
>> hankin.ro...@gmail.com
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
> David Winsemius, MD
> Heritage Laboratories
> West Hartford, CT
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] repeatable segfault - on Mac
On Sep 8, 2011, at 10:01 , Martin Maechler wrote:
>> David Winsemius
>>on Tue, 6 Sep 2011 00:38:13 -0400 writes:
>
>> I can reproduce:
>> eigen(crossprod(matrix(1:2000, 50)) + (0+0i), T, T)
>
>> *** caught segfault ***
>> address 0x102d0e028, cause 'memory not mapped'
>
>> Traceback:
>> 1: .Call("La_rs_cmplx", x, only.values, PACKAGE = "base")
>> 2: eigen(crossprod(matrix(1:2000, 50)) + (0 + (0+0i)), T, T)
>> ## after restart
>>> sessionInfo()
>> R version 2.13.1 (2011-07-08)
>> Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit)
>
>> locale:
>> [1] en_US.UTF-8/en_US.UTF-8/C/C/en_US.UTF-8/en_US.UTF-8
>
>> attached base packages:
>> [1] stats graphics grDevices utils datasets methods base
>
>> With OSX 10.5.8
>
>> Also happens with 32 bit R
>> [R.app GUI 1.41 (5874) i386-apple-darwin9.8.0]
>
> It does not happen on Linux (different versions)
> nor Windows (2.13.1 patched, early August).
>
> As this is calling LAPACK code,
> I guess that this is yet another case where the Mac version
> of optimized BLAS / LAPACK is playing wrongly.
Hmm, it does happen too on OSX (64bit) with a recent R-devel, vanilla compiled
with
LAPACK_LIBS='-L$(R_HOME)/lib$(R_ARCH) -lRlapack'
I tried recompiling with -O0, still happening:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x000102ddc128
0x00010046805e in zher2k (uplo=@0x7fff5fbf9b0e, trans=@0x1039fc54b,
n=@0x7fff5fbf98cc, k=@0x7fff5fbf98e0, alpha=@0x1039fc528, a=0x102198228,
lda=@0x7fff5fbf9b08, b=0x1023abca8, ldb=@0x7fff5fbf98f4, beta=@0x1039fc660,
c=0x10219d228, ldc=@0x7fff5fbf9b08, _uplo=1, _trans=12) at
../../../../R/src/extra/blas/cmplxblas.f:1566
1566 TEMP1 = ALPHA*DCONJG( B( J, L ) )
(gdb) where
#0 0x00010046805e in zher2k (uplo=@0x7fff5fbf9b0e, trans=@0x1039fc54b,
n=@0x7fff5fbf98cc, k=@0x7fff5fbf98e0, alpha=@0x1039fc528, a=0x102198228,
lda=@0x7fff5fbf9b08, b=0x1023abca8, ldb=@0x7fff5fbf98f4, beta=@0x1039fc660,
c=0x10219d228, ldc=@0x7fff5fbf9b08, _uplo=1, _trans=12) at
../../../../R/src/extra/blas/cmplxblas.f:1566
#1 0x0001039939aa in zhetrd (uplo=@0x7fff5fbf9b0e, n=@0x7fff5fbf9b08,
a=0x102198028, lda=@0x7fff5fbf9b08, d=0x100597f28, e=0x102e02d58,
tau=0x1023ab828, work=0x1023abaa8, lwork=@0x7fff5fbf9a30, info=@0x7fff5fbf9a44,
_uplo=1) at ../../../../R/src/modules/lapack/cmplx.f:8841
#2 0x00010399209e in zheev (jobz=@0x7fff5fbf9b0f, uplo=@0x7fff5fbf9b0e,
n=@0x7fff5fbf9b08, a=0x102198028, lda=@0x7fff5fbf9b08, w=0x100597f28,
work=0x1023ab828, lwork=@0x7fff5fbf9b04, rwork=0x102e02d58,
info=@0x7fff5fbf9b00, _jobz=10096376, _uplo=36013056) at
../../../../R/src/modules/lapack/cmplx.f:8275
#3 0x0001007f102e in modLa_rs_cmplx (xin=0x102258400,
only_values=0x1009a0ef8) at ../../../../R/src/modules/lapack/Lapack.c:776
#4 0x000100103baf in La_rs_cmplx (x=0x102258400, only_values=0x1009a0ef8)
at ../../../R/src/main/lapack.c:113
#5 0x00010007a82b in do_dotcall (call=0x1026c62e8, op=0x100864718,
args=0x1026d9278, env=0x1026d4278) at ../../../R/src/main/dotcode.c:845
Segmentation fault
(The segfault appears to be gdb itself tripping over)
-pd
>
> Martin Maechler
>
>> David Winsemius
>
>> On Sep 6, 2011, at 12:12 AM, robin hankin wrote:
>
>>> Hi. macosx 10.6.8
>>>
>>> With R-2.13.1 and also revision 56948 I get the following repeatable
>>> segfault:
>>>
>>>
>>>
>>> wt118:~% R --vanilla --quiet
R.Version()
>>> $platform
>>> [1] "x86_64-apple-darwin9.8.0"
>>>
>>> $arch
>>> [1] "x86_64"
>>>
>>> $os
>>> [1] "darwin9.8.0"
>>>
>>> $system
>>> [1] "x86_64, darwin9.8.0"
>>>
>>> $status
>>> [1] ""
>>>
>>> $major
>>> [1] "2"
>>>
>>> $minor
>>> [1] "13.1"
>>>
>>> $year
>>> [1] "2011"
>>>
>>> $month
>>> [1] "07"
>>>
>>> $day
>>> [1] "08"
>>>
>>> $`svn rev`
>>> [1] "56322"
>>>
>>> $language
>>> [1] "R"
>>>
>>> $version.string
>>> [1] "R version 2.13.1 (2011-07-08)"
>>>
eigen(crossprod(matrix(1:2000, 50)) + (0+0i), T, T)
>>>
>>> *** caught segfault ***
>>> address 0x1038000a8, cause 'memory not mapped'
>>>
>>> Traceback:
>>> 1: .Call("La_rs_cmplx", x, only.values, PACKAGE = "base")
>>> 2: eigen(crossprod(matrix(1:2000, 50)) + (0 + (0+0i)), T, T)
>>>
>>> Possible actions:
>>> 1: abort (with core dump, if enabled)
>>> 2: normal R exit
>>> 3: exit R without saving workspace
>>> 4: exit R saving workspace
>>> Selection: 2
>>> wt118:~%
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Robin Hankin
>>> Uncertainty Analyst
>>> hankin.ro...@gmail.com
>>>
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>> David Winsemius, MD
>> Heritage Laboratories
>> West Hartford, CT
>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> __
> R-devel@r-project.org mailing list
> https:/
Re: [Rd] repeatable segfault - on Mac
On Sep 8, 2011, at 4:01 AM, Martin Maechler wrote:
>> David Winsemius
>>on Tue, 6 Sep 2011 00:38:13 -0400 writes:
>
>> I can reproduce:
>> eigen(crossprod(matrix(1:2000, 50)) + (0+0i), T, T)
>
>> *** caught segfault ***
>> address 0x102d0e028, cause 'memory not mapped'
>
>> Traceback:
>> 1: .Call("La_rs_cmplx", x, only.values, PACKAGE = "base")
>> 2: eigen(crossprod(matrix(1:2000, 50)) + (0 + (0+0i)), T, T)
>> ## after restart
>>> sessionInfo()
>> R version 2.13.1 (2011-07-08)
>> Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit)
>
>> locale:
>> [1] en_US.UTF-8/en_US.UTF-8/C/C/en_US.UTF-8/en_US.UTF-8
>
>> attached base packages:
>> [1] stats graphics grDevices utils datasets methods base
>
>> With OSX 10.5.8
>
>> Also happens with 32 bit R
>> [R.app GUI 1.41 (5874) i386-apple-darwin9.8.0]
>
> It does not happen on Linux (different versions)
> nor Windows (2.13.1 patched, early August).
>
> As this is calling LAPACK code,
> I guess that this is yet another case where the Mac version
> of optimized BLAS / LAPACK is playing wrongly.
>
Nope, this is R's BLAS / LAPACK!
> Martin Maechler
>
>> David Winsemius
>
>> On Sep 6, 2011, at 12:12 AM, robin hankin wrote:
>
>>> Hi. macosx 10.6.8
>>>
>>> With R-2.13.1 and also revision 56948 I get the following repeatable
>>> segfault:
>>>
>>>
>>>
>>> wt118:~% R --vanilla --quiet
R.Version()
>>> $platform
>>> [1] "x86_64-apple-darwin9.8.0"
>>>
>>> $arch
>>> [1] "x86_64"
>>>
>>> $os
>>> [1] "darwin9.8.0"
>>>
>>> $system
>>> [1] "x86_64, darwin9.8.0"
>>>
>>> $status
>>> [1] ""
>>>
>>> $major
>>> [1] "2"
>>>
>>> $minor
>>> [1] "13.1"
>>>
>>> $year
>>> [1] "2011"
>>>
>>> $month
>>> [1] "07"
>>>
>>> $day
>>> [1] "08"
>>>
>>> $`svn rev`
>>> [1] "56322"
>>>
>>> $language
>>> [1] "R"
>>>
>>> $version.string
>>> [1] "R version 2.13.1 (2011-07-08)"
>>>
eigen(crossprod(matrix(1:2000, 50)) + (0+0i), T, T)
>>>
>>> *** caught segfault ***
>>> address 0x1038000a8, cause 'memory not mapped'
>>>
>>> Traceback:
>>> 1: .Call("La_rs_cmplx", x, only.values, PACKAGE = "base")
>>> 2: eigen(crossprod(matrix(1:2000, 50)) + (0 + (0+0i)), T, T)
>>>
>>> Possible actions:
>>> 1: abort (with core dump, if enabled)
>>> 2: normal R exit
>>> 3: exit R without saving workspace
>>> 4: exit R saving workspace
>>> Selection: 2
>>> wt118:~%
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Robin Hankin
>>> Uncertainty Analyst
>>> hankin.ro...@gmail.com
>>>
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>> David Winsemius, MD
>> Heritage Laboratories
>> West Hartford, CT
>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] repeatable segfault - on Mac
> Simon Urbanek
> on Thu, 8 Sep 2011 09:33:23 -0400 writes:
> On Sep 8, 2011, at 4:01 AM, Martin Maechler wrote:
>>> David Winsemius
>>> on Tue, 6 Sep 2011 00:38:13 -0400 writes:
>>
>>> I can reproduce:
>>> eigen(crossprod(matrix(1:2000, 50)) + (0+0i), T, T)
>>
>>> *** caught segfault ***
>>> address 0x102d0e028, cause 'memory not mapped'
>>
>>> Traceback:
>>> 1: .Call("La_rs_cmplx", x, only.values, PACKAGE = "base")
>>> 2: eigen(crossprod(matrix(1:2000, 50)) + (0 + (0+0i)), T, T)
>>> ## after restart
sessionInfo()
>>> R version 2.13.1 (2011-07-08)
>>> Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit)
>>
>>> locale:
>>> [1] en_US.UTF-8/en_US.UTF-8/C/C/en_US.UTF-8/en_US.UTF-8
>>
>>> attached base packages:
>>> [1] stats graphics grDevices utils datasets methods base
>>
>>> With OSX 10.5.8
>>
>>> Also happens with 32 bit R
>>> [R.app GUI 1.41 (5874) i386-apple-darwin9.8.0]
>>
>> It does not happen on Linux (different versions)
>> nor Windows (2.13.1 patched, early August).
>>
>> As this is calling LAPACK code,
>> I guess that this is yet another case where the Mac version
>> of optimized BLAS / LAPACK is playing wrongly.
>>
> Nope, this is R's BLAS / LAPACK!
yes, it seems, as Peter is confirming as well.
*BUT* as far as we currently know, the problem was never seen
outside of MacOS X , right?
Martin Maechler
>>> David Winsemius
>>
>>> On Sep 6, 2011, at 12:12 AM, robin hankin wrote:
>>
Hi. macosx 10.6.8
With R-2.13.1 and also revision 56948 I get the following repeatable
segfault:
wt118:~% R --vanilla --quiet
> R.Version()
$platform
[1] "x86_64-apple-darwin9.8.0"
$arch
[1] "x86_64"
$os
[1] "darwin9.8.0"
$system
[1] "x86_64, darwin9.8.0"
$status
[1] ""
$major
[1] "2"
$minor
[1] "13.1"
$year
[1] "2011"
$month
[1] "07"
$day
[1] "08"
$`svn rev`
[1] "56322"
$language
[1] "R"
$version.string
[1] "R version 2.13.1 (2011-07-08)"
> eigen(crossprod(matrix(1:2000, 50)) + (0+0i), T, T)
*** caught segfault ***
address 0x1038000a8, cause 'memory not mapped'
Traceback:
1: .Call("La_rs_cmplx", x, only.values, PACKAGE = "base")
2: eigen(crossprod(matrix(1:2000, 50)) + (0 + (0+0i)), T, T)
Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
Selection: 2
wt118:~%
--
Robin Hankin
Uncertainty Analyst
hankin.ro...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>> David Winsemius, MD
>>> Heritage Laboratories
>>> West Hartford, CT
>>
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] repeatable segfault - on Mac
On Thu, 8 Sep 2011, Martin Maechler wrote:
Simon Urbanek
on Thu, 8 Sep 2011 09:33:23 -0400 writes:
> On Sep 8, 2011, at 4:01 AM, Martin Maechler wrote:
>>> David Winsemius
>>> on Tue, 6 Sep 2011 00:38:13 -0400 writes:
>>
>>> I can reproduce:
>>> eigen(crossprod(matrix(1:2000, 50)) + (0+0i), T, T)
>>
>>> *** caught segfault ***
>>> address 0x102d0e028, cause 'memory not mapped'
>>
>>> Traceback:
>>> 1: .Call("La_rs_cmplx", x, only.values, PACKAGE = "base")
>>> 2: eigen(crossprod(matrix(1:2000, 50)) + (0 + (0+0i)), T, T)
>>> ## after restart
sessionInfo()
>>> R version 2.13.1 (2011-07-08)
>>> Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit)
>>
>>> locale:
>>> [1] en_US.UTF-8/en_US.UTF-8/C/C/en_US.UTF-8/en_US.UTF-8
>>
>>> attached base packages:
>>> [1] stats graphics grDevices utils datasets methods base
>>
>>> With OSX 10.5.8
>>
>>> Also happens with 32 bit R
>>> [R.app GUI 1.41 (5874) i386-apple-darwin9.8.0]
>>
>> It does not happen on Linux (different versions)
>> nor Windows (2.13.1 patched, early August).
>>
>> As this is calling LAPACK code,
>> I guess that this is yet another case where the Mac version
>> of optimized BLAS / LAPACK is playing wrongly.
>>
> Nope, this is R's BLAS / LAPACK!
yes, it seems, as Peter is confirming as well.
*BUT* as far as we currently know, the problem was never seen
outside of MacOS X , right?
My experience is that the Mac OS malloc is less forgiving of writing
outside allocated memory than the one usually used on Linux, so some
things show up only on macs or are easier to trigger on macs even
though the problems exist else where as well. Valgrind probably makes
up for that most of the time but maybe not always.
Best,
luke
Martin Maechler
>>> David Winsemius
>>
>>> On Sep 6, 2011, at 12:12 AM, robin hankin wrote:
>>
Hi. macosx 10.6.8
With R-2.13.1 and also revision 56948 I get the following repeatable
segfault:
wt118:~% R --vanilla --quiet
> R.Version()
$platform
[1] "x86_64-apple-darwin9.8.0"
$arch
[1] "x86_64"
$os
[1] "darwin9.8.0"
$system
[1] "x86_64, darwin9.8.0"
$status
[1] ""
$major
[1] "2"
$minor
[1] "13.1"
$year
[1] "2011"
$month
[1] "07"
$day
[1] "08"
$`svn rev`
[1] "56322"
$language
[1] "R"
$version.string
[1] "R version 2.13.1 (2011-07-08)"
> eigen(crossprod(matrix(1:2000, 50)) + (0+0i), T, T)
*** caught segfault ***
address 0x1038000a8, cause 'memory not mapped'
Traceback:
1: .Call("La_rs_cmplx", x, only.values, PACKAGE = "base")
2: eigen(crossprod(matrix(1:2000, 50)) + (0 + (0+0i)), T, T)
Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
Selection: 2
wt118:~%
--
Robin Hankin
Uncertainty Analyst
hankin.ro...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>> David Winsemius, MD
>>> Heritage Laboratories
>>> West Hartford, CT
>>
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Luke Tierney
Chair, Statistics and Actuarial Science
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa Phone: 319-335-3386
Department of Statistics andFax: 319-335-3017
Actuarial Science
241 Schaeffer Hall email: l...@stat.uiowa.edu
Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] repeatable segfault - on Mac
It is intermittent on both my systems.
Rob
On Sep 8, 2011, at 8:00 AM, luke-tier...@uiowa.edu wrote:
> On Thu, 8 Sep 2011, Martin Maechler wrote:
>
>>> Simon Urbanek
>>>on Thu, 8 Sep 2011 09:33:23 -0400 writes:
>>
>> > On Sep 8, 2011, at 4:01 AM, Martin Maechler wrote:
>>
>> >>> David Winsemius
>> >>> on Tue, 6 Sep 2011 00:38:13 -0400 writes:
>> >>
>> >>> I can reproduce:
>> >>> eigen(crossprod(matrix(1:2000, 50)) + (0+0i), T, T)
>> >>
>> >>> *** caught segfault ***
>> >>> address 0x102d0e028, cause 'memory not mapped'
>> >>
>> >>> Traceback:
>> >>> 1: .Call("La_rs_cmplx", x, only.values, PACKAGE = "base")
>> >>> 2: eigen(crossprod(matrix(1:2000, 50)) + (0 + (0+0i)), T, T)
>> >>> ## after restart
>> sessionInfo()
>> >>> R version 2.13.1 (2011-07-08)
>> >>> Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit)
>> >>
>> >>> locale:
>> >>> [1] en_US.UTF-8/en_US.UTF-8/C/C/en_US.UTF-8/en_US.UTF-8
>> >>
>> >>> attached base packages:
>> >>> [1] stats graphics grDevices utils datasets methods base
>> >>
>> >>> With OSX 10.5.8
>> >>
>> >>> Also happens with 32 bit R
>> >>> [R.app GUI 1.41 (5874) i386-apple-darwin9.8.0]
>> >>
>> >> It does not happen on Linux (different versions)
>> >> nor Windows (2.13.1 patched, early August).
>> >>
>> >> As this is calling LAPACK code,
>> >> I guess that this is yet another case where the Mac version
>> >> of optimized BLAS / LAPACK is playing wrongly.
>> >>
>>
>> > Nope, this is R's BLAS / LAPACK!
>>
>> yes, it seems, as Peter is confirming as well.
>>
>> *BUT* as far as we currently know, the problem was never seen
>> outside of MacOS X , right?
>>
>
> My experience is that the Mac OS malloc is less forgiving of writing
> outside allocated memory than the one usually used on Linux, so some
> things show up only on macs or are easier to trigger on macs even
> though the problems exist else where as well. Valgrind probably makes
> up for that most of the time but maybe not always.
>
> Best,
>
> luke
>
>
>> Martin Maechler
>>
>> >>> David Winsemius
>> >>
>> >>> On Sep 6, 2011, at 12:12 AM, robin hankin wrote:
>> >>
>> Hi. macosx 10.6.8
>>
>> With R-2.13.1 and also revision 56948 I get the following repeatable
>> segfault:
>>
>>
>>
>> wt118:~% R --vanilla --quiet
>> > R.Version()
>> $platform
>> [1] "x86_64-apple-darwin9.8.0"
>>
>> $arch
>> [1] "x86_64"
>>
>> $os
>> [1] "darwin9.8.0"
>>
>> $system
>> [1] "x86_64, darwin9.8.0"
>>
>> $status
>> [1] ""
>>
>> $major
>> [1] "2"
>>
>> $minor
>> [1] "13.1"
>>
>> $year
>> [1] "2011"
>>
>> $month
>> [1] "07"
>>
>> $day
>> [1] "08"
>>
>> $`svn rev`
>> [1] "56322"
>>
>> $language
>> [1] "R"
>>
>> $version.string
>> [1] "R version 2.13.1 (2011-07-08)"
>>
>> > eigen(crossprod(matrix(1:2000, 50)) + (0+0i), T, T)
>>
>> *** caught segfault ***
>> address 0x1038000a8, cause 'memory not mapped'
>>
>> Traceback:
>> 1: .Call("La_rs_cmplx", x, only.values, PACKAGE = "base")
>> 2: eigen(crossprod(matrix(1:2000, 50)) + (0 + (0+0i)), T, T)
>>
>> Possible actions:
>> 1: abort (with core dump, if enabled)
>> 2: normal R exit
>> 3: exit R without saving workspace
>> 4: exit R saving workspace
>> Selection: 2
>> wt118:~%
>>
>>
>>
>>
>>
>> --
>> Robin Hankin
>> Uncertainty Analyst
>> hankin.ro...@gmail.com
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>> >>
>> >>> David Winsemius, MD
>> >>> Heritage Laboratories
>> >>> West Hartford, CT
>> >>
>> >>> __
>> >>> R-devel@r-project.org mailing list
>> >>> https://stat.ethz.ch/mailman/listinfo/r-devel
>> >>
>> >> __
>> >> R-devel@r-project.org mailing list
>> >> https://stat.ethz.ch/mailman/listinfo/r-devel
>> >>
>> >>
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
> --
> Luke Tierney
> Chair, Statistics and Actuarial Science
> Ralph E. Wareham Professor of Mathematical Sciences
> University of Iowa Phone: 319-335-3386
> Department of Statistics andFax: 319-335-3017
> Actuarial Science
> 241 Schaeffer Hall email: l...@stat.uiowa.edu
> Iowa City, IA 52242
[Rd] As a package author, is there a way to specify that your package is architecture (x86_64) specific?
Hi, Essentially: subject line says it all. I've created a package that wraps an external c++ library (which I didn't write) that only successfully compiles on 64bit machines. I'd like to make the package broadly available, but is there a way to get it on CRAN if the 32-bit builds break by specifying its 64-bit only somehow? Luckily, I've ./configure'd my R-devel-compiled-from-source to only build x86_64 libs, so I can develop and install my package against that, but trying to `R CMD INSTALL mypackage` using the official R binaries breaks since it also tries to build a 32-bit *.so (I'm on a mac). I see hints in how to limit which architecture a package is built against in the R-ext and R-admin manuals where they seem to suggest to include a src/Makefile in order to do that ... but I'm not sure what I should put in it. Is it possible to limit the build architecture by putting something in my src/Makevars instead of trying to engineer an entire Makefile since "the normal build process" works just fine (except this whole architecture thing)? Even if it can't go on CRAN as 64-bit only, it would be great if I can put up some easy install instructions for people to d/l my source package externally and use it that way. Thanks, -steve -- Steve Lianoglou Graduate Student: Computational Systems Biology | Memorial Sloan-Kettering Cancer Center | Weill Medical College of Cornell University Contact Info: http://cbio.mskcc.org/~lianos/contact __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] As a package author, is there a way to specify that your package is architecture (x86_64) specific?
Quick follow up before I get RTFM'd: I just found I can do: R CMD INSTALL --no-multiarch mypackage To get this to successfully work from the command line, so apologies for the second part of the question. The first Q remains, which is to either get this to happen "automagically" via Makevars, or somehow specify the package as 64bit only to see if the package can go up on CRAN until I can find time to fix the problem (if/when). Thanks, -steve On Thu, Sep 8, 2011 at 3:59 PM, Steve Lianoglou wrote: > Hi, > > Essentially: subject line says it all. > > I've created a package that wraps an external c++ library (which I > didn't write) that only successfully compiles on 64bit machines. > > I'd like to make the package broadly available, but is there a way to > get it on CRAN if the 32-bit builds break by specifying its 64-bit > only somehow? > > Luckily, I've ./configure'd my R-devel-compiled-from-source to only > build x86_64 libs, so I can develop and install my package against > that, but trying to `R CMD INSTALL mypackage` using the official R > binaries breaks since it also tries to build a 32-bit *.so (I'm on a > mac). > > I see hints in how to limit which architecture a package is built > against in the R-ext and R-admin manuals where they seem to suggest to > include a src/Makefile in order to do that ... but I'm not sure what I > should put in it. > > Is it possible to limit the build architecture by putting something in > my src/Makevars instead of trying to engineer an entire Makefile since > "the normal build process" works just fine (except this whole > architecture thing)? > > Even if it can't go on CRAN as 64-bit only, it would be great if I can > put up some easy install instructions for people to d/l my source > package externally and use it that way. > > Thanks, > > -steve > > -- > Steve Lianoglou > Graduate Student: Computational Systems Biology > | Memorial Sloan-Kettering Cancer Center > | Weill Medical College of Cornell University > Contact Info: http://cbio.mskcc.org/~lianos/contact > -- Steve Lianoglou Graduate Student: Computational Systems Biology | Memorial Sloan-Kettering Cancer Center | Weill Medical College of Cornell University Contact Info: http://cbio.mskcc.org/~lianos/contact __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] As a package author, is there a way to specify that your package is architecture (x86_64) specific?
On Sep 8, 2011, at 3:59 PM, Steve Lianoglou wrote: > Hi, > > Essentially: subject line says it all. > > I've created a package that wraps an external c++ library (which I didn't > write) that only successfully compiles on 64bit machines. > That doesn't sound right, it contradicts your subject line - x86_64 is just one of many 64-bit architectures ... but from what you describe it's not about an architecture at all - it's about the library .. (see below). > I'd like to make the package broadly available, but is there a way to > get it on CRAN if the 32-bit builds break by specifying its 64-bit > only somehow? > > Luckily, I've ./configure'd my R-devel-compiled-from-source to only > build x86_64 libs, so I can develop and install my package against > that, but trying to `R CMD INSTALL mypackage` using the official R > binaries breaks since it also tries to build a 32-bit *.so (I'm on a > mac). > > I see hints in how to limit which architecture a package is built > against in the R-ext and R-admin manuals where they seem to suggest to > include a src/Makefile in order to do that ... but I'm not sure what I > should put in it. > No, that's not the purpose. > Is it possible to limit the build architecture by putting something in > my src/Makevars instead of trying to engineer an entire Makefile since > "the normal build process" works just fine (except this whole > architecture thing)? > > Even if it can't go on CRAN as 64-bit only, it would be great if I can > put up some easy install instructions for people to d/l my source > package externally and use it that way. > The configure script is designed to figure out things like that, so all you need to do is to add a configure script that will check whether the package can be built for that architecture or not. In fact, it should really check whatever the C++ library does that prevents it from working elsewhere. The particularities depends on the library so you'll need to provide more info in oder to help you better ... Note that it will also ensure that the package will be built only for one architecture. Cheers, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] nobs(lm(...)) != nobs(glm(...)) when there are 0s in weights
What is the rationale for nobs.lm omitting observations with zero weights while nobs.glm includes them? > df <- data.frame(x1=log(1:10), x2=1/(1:10), y=1:10, > wt=c(0,2,0,4,0,6,7,8,9,10)) > nobs(lm(data=df, y~x1+x2, weights=wt)) [1] 7 > nobs(glm(data=df, y~x1+x2, weights=wt)) [1] 10 The anova methods for lm and glm seem to agree on the number of degrees of freedom here, although anova.glm issues a message about it: > anova(lm(data=df, y~x1+x2, weights=wt)) Analysis of Variance Table Response: y Df Sum Sq Mean Sq F valuePr(>F) x1 1 196.682 196.682 1034.648 5.569e-06 *** x2 1 11.514 11.514 60.572 0.00147 ** Residuals 4 0.760 0.190 --- Signif. codes: 0 '***' 0.001 '**' 0.01 '*' 0.05 '.' 0.1 ' ' 1 > anova(glm(data=df, y~x1+x2, weights=wt)) Analysis of Deviance Table Model: gaussian, link: identity Response: y Terms added sequentially (first to last) Df Deviance Resid. Df Resid. Dev NULL 6208.957 x11 196.682 5 12.275 x21 11.514 4 0.760 Warning message: In summary.glm(object, dispersion = dispersion) : observations with zero weight not used for calculating dispersion Bill Dunlap Spotfire, TIBCO Software wdunlap tibco.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] As a package author, is there a way to specify that your package is architecture (x86_64) specific?
Hi Simon, Thanks for the quick response. Comments in line: On Thu, Sep 8, 2011 at 4:11 PM, Simon Urbanek wrote: > > On Sep 8, 2011, at 3:59 PM, Steve Lianoglou wrote: > >> Hi, >> >> Essentially: subject line says it all. >> >> I've created a package that wraps an external c++ library (which I didn't >> write) that only successfully compiles on 64bit machines. >> > > That doesn't sound right, it contradicts your subject line - x86_64 is just > one of many 64-bit architectures ... Ok, sorry for being imprecise. Let's see if we can figure out what it is (more precise details are at the bottom of the email). I see x86_64 on every 64bit machine I touch (linux or mac), so I thought they were interchangeable (as names). > My hunch is that it really is about the architecture, not x86_64 but from > what you describe it's not about an architecture at all - it's about the > library .. (see below). [snip] >> I see hints in how to limit which architecture a package is built >> against in the R-ext and R-admin manuals where they seem to suggest to >> include a src/Makefile in order to do that ... but I'm not sure what I >> should put in it. >> > > No, that's not the purpose. Well, the r-admin doc does suggest using your own Makefile in close proximity to targetting specific architectures several times ... eg. section 2.6, 6.3.1, 6.3.4. In fact, if you search that document for "src/Makefile" it's almost always found next to something that talks about compiling architecture specific builds ... I'm sure it's used for a lot more than that, but r-admin repeatedly suggests that this is one of its functions. But let's get to the good stuff. >> Even if it can't go on CRAN as 64-bit only, it would be great if I can >> put up some easy install instructions for people to d/l my source >> package externally and use it that way. >> > > The configure script is designed to figure out things like that, so all you > need to do is to add a configure script that will check whether the package > can be built for that architecture or not. OK ... I was hoping I could avoid getting into configure/autoconf stuff, but at some point I'll have to bite the bullet and read up on it much more than I really want to, so I guess that will happen sooner than later. > In fact, it should really check whatever the C++ library does that prevents > it from working elsewhere. The particularities depends on the library so > you'll need to provide more info in oder to help you better ... It's doing some inline assembly. The problematic code is here: https://github.com/lianos/buckshot/blob/master/src/cas_array.h#L90 Compiling the 32bit version of the library on my mac complains about the call to `cmpxchg`, specifically: /var/folders/C2/C2bsTekpH-qdLj5psUvjtk+++TM/-Tmp-//cc7q88qD.s:785:suffix or operands invalid for `cmpxchg' Doing surgery on the code to actually fix it is a bit above my pay grade right now as the last time I had to write in assembly was > 10 years ago for an undergraduate class, so I'd just like to sidestep the issue. I'm not sure how to properly check if this call to cmpxchg can work inside a configure script or using autoconf. If it's relatively simple, I'd appreciate a hint if you've got one to spare, otherwise I'll just keep compiling the 64bit only version of the library until I can figure out how to sort it out. The library also compiles fine on our linux compute servers, which `uname -a` tells me are also of the x86_64 64bit variety. I'm not sure if that's helpful to know, but thought I'd just put it out there. Thanks, -steve -- Steve Lianoglou Graduate Student: Computational Systems Biology | Memorial Sloan-Kettering Cancer Center | Weill Medical College of Cornell University Contact Info: http://cbio.mskcc.org/~lianos/contact __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
