Re: [R-SIG-Mac] another R crash issue
I am receiving email that I am involve in it , please stop
Il giorno dom 4 dic 2022 alle 11:25 Prof Brian Ripley
ha scritto:
> On 01/12/2022 21:00, Simon Urbanek wrote:
> > This is a clear bug in gmp (the R package) - simply division by zero in
> >
> > templateMatrix.h:126:return this->size() / nRows();
> >
> >* frame #0: 0x0001076e1b12
> gmp.so`math::Matrix::nCols(this=0x7ffeefbfc5d8) const at
> templateMatrix.h:126:25 [opt]
> > frame #1: 0x0001076ea253
> gmp.so`matrixz::bigint_transpose(mat=0x7ffeefbfc5d8) at
> matrix.cc:484:23 [opt]
> > frame #2: 0x0001076eb3be
> gmp.so`::biginteger_rbind(args=0x000108a60848) at matrix.cc:459:12 [opt]
> >
> > i.e., bigint_transpose() cannot deal with 0-row matrices. That may be
> just the tip of the ice berg, even biginteger_rbind itself should probably
> just skip zero-length objects.
>
> My macOS build showed a different issue which also needs correcting:
>
> > rbind(NULL, as.bigz(c(1,3)))
> Big Integer ('bigz') Error in sprintf("%d x %d matrix", nr, n/nr) :
>invalid format '%d'; use format %f, %e, %g or %a for numeric objects
>
> but I get a segfault on Linux.
>
> There are two instances in gmp/R:
>
> biginteger.R:sprintf("%d x %d matrix", nr, n/nr)
> bigq.R:sprintf("%d x %d matrix", nr, n/nr)
>
> Note too that n in
>
>if((n <- length(x)) > 0) {
>
> need not be of integer type, and n/nr never will be.
>
> > Cheers,
> > Simon
> >
> >
> >> On 17/11/2022, at 9:50 PM, Martin Maechler
> wrote:
> >>
> >>> Carl Witthoft
> >>> on Wed, 16 Nov 2022 19:58:31 -0500 writes:
> >>
> >>> This may be the fault of the `gmp` library, but posting to r-sig as
> well
> >>> just in case.
> >>
> >>> Mac OS 11.6.8 , R 4.2.2
> >>
> >> Yes, the gmp package Mac version gives immediate seg faults.
> >>
> >> Prof Brian Ripley has already alerted the gmp package maintainer, me
> >> (a gmp package co-author, not familiar with the C++ design in
> >> there, and maintainer of dependent R package 'Rmpfr') and
> >> the CRAN team.
> >>
> >> He has debugged deeply and tediously until diagnosing the
> >> problem happens in *assembler* (!) code of the libgmp.a library
> >> (i.e, the 'gmp' C library that has nothing to do with R).
> >>
> >> Brian Ripley further found that when using the latest
> >> *development* version of that gmp C library and building libgmp
> >> and R packages gmp and Rmpfr himself from the sources he got no
> >> more segfaults.
> >>
> >> The problem is only seen on the Mac.
> >>
> >> Martin
> >>
> >>
> >>> Consider the following work:
> >>
> >> Rgames> foo <- NULL
> >> Rgames> rbind(foo,c(1,3))
> >>> [,1] [,2]
> >>> [1,]13
> >> Rgames> foo <- NULL
> >> Rgames> # rbind(foo,as.bigz(c(1,3))) ## instant crash
> >>
> >>
> >>> Further playing around suggests that , given that as.bigz(NULL)
> returns
> >>> a "bigz(0) " empty object, gmp is really unhappy trying to do almost
> >>> anything with said object.
> >>
> >>
> >>> regards,
> >>> Carl
> >>
> >>
> >>> Crash log follows
> >>> Process: R [11657]
> >>> Path: /Applications/R.app/Contents/MacOS/R
> >>> Identifier:org.R-project.R
> >>> Version: R 4.2.2 GUI 1.79 High Sierra build (8160)
> >>> Code Type: X86-64 (Native)
> >>> Parent Process:??? [1]
> >>> Responsible: R [11657]
> >>> User ID: 502
> >>
> >>> Date/Time: 2022-11-16 19:42:41.462 -0500
> >>> OS Version:macOS 11.6.8 (20G730)
> >>> Report Version:12
> >>> Anonymous UUID:B755C094-C366-46AB-8EEA-9D3B8E7B388D
> >>
> >>> Sleep/Wake UUID: D725679E-AF7A-4203-8EA3-B313AA2846F5
> >>
> >>> Time Awake Since Boot: 98000 seconds
> >>> Time Since Wake: 2100 seconds
> >>
> >>> System Integrity Protection: enabled
> >>
> >>> Crashed Thread:0 Dispatch queue: com.apple.main-thread
> >>
> >>> Exception Type:EXC_ARITHMETIC (SIGFPE)
> >>> Exception Codes: EXC_I386_DIV (divide by zero)
> >>> Exception Note:EXC_CORPSE_NOTIFY
> >>
> >>> Termination Signal:Floating point exception: 8
> >>> Termination Reason:Namespace SIGNAL, Code 0x8
> >>> Terminating Process: exc handler [11657]
> >>
> >>> Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
> >>> 0 gmp.so 0x0001149159c2
> >>> math::Matrix::nCols() const + 34
> >>> 1 gmp.so 0x00011491e5af
> >>> matrixz::bigint_transpose(bigvec&) + 47
> >>> 2 gmp.so 0x00011491f8be
> biginteger_rbind + 158
> >>> 3 libR.dylib 0x000104b3f8dc R_doDotCall +
> 1420
> >>> (dotcode.c:601)
> >>> 4 libR.dylib 0x000104b8b7ed bcEval + 104269
> >>> (eval.c:7692)
> >>> 5 libR.dylib 0x000104b71a01 Rf_eval + 385
> >>> (eval.c:748)
> >>> 6 libR.dylib 0x000104b91839 R_execClosure +
> 2169
Re: [R-SIG-Mac] another R crash issue
On 01/12/2022 21:00, Simon Urbanek wrote:
This is a clear bug in gmp (the R package) - simply division by zero in
templateMatrix.h:126:return this->size() / nRows();
* frame #0: 0x0001076e1b12
gmp.so`math::Matrix::nCols(this=0x7ffeefbfc5d8) const at
templateMatrix.h:126:25 [opt]
frame #1: 0x0001076ea253
gmp.so`matrixz::bigint_transpose(mat=0x7ffeefbfc5d8) at matrix.cc:484:23
[opt]
frame #2: 0x0001076eb3be
gmp.so`::biginteger_rbind(args=0x000108a60848) at matrix.cc:459:12 [opt]
i.e., bigint_transpose() cannot deal with 0-row matrices. That may be just the
tip of the ice berg, even biginteger_rbind itself should probably just skip
zero-length objects.
My macOS build showed a different issue which also needs correcting:
> rbind(NULL, as.bigz(c(1,3)))
Big Integer ('bigz') Error in sprintf("%d x %d matrix", nr, n/nr) :
invalid format '%d'; use format %f, %e, %g or %a for numeric objects
but I get a segfault on Linux.
There are two instances in gmp/R:
biginteger.R:sprintf("%d x %d matrix", nr, n/nr)
bigq.R:sprintf("%d x %d matrix", nr, n/nr)
Note too that n in
if((n <- length(x)) > 0) {
need not be of integer type, and n/nr never will be.
Cheers,
Simon
On 17/11/2022, at 9:50 PM, Martin Maechler wrote:
Carl Witthoft
on Wed, 16 Nov 2022 19:58:31 -0500 writes:
This may be the fault of the `gmp` library, but posting to r-sig as well
just in case.
Mac OS 11.6.8 , R 4.2.2
Yes, the gmp package Mac version gives immediate seg faults.
Prof Brian Ripley has already alerted the gmp package maintainer, me
(a gmp package co-author, not familiar with the C++ design in
there, and maintainer of dependent R package 'Rmpfr') and
the CRAN team.
He has debugged deeply and tediously until diagnosing the
problem happens in *assembler* (!) code of the libgmp.a library
(i.e, the 'gmp' C library that has nothing to do with R).
Brian Ripley further found that when using the latest
*development* version of that gmp C library and building libgmp
and R packages gmp and Rmpfr himself from the sources he got no
more segfaults.
The problem is only seen on the Mac.
Martin
Consider the following work:
Rgames> foo <- NULL
Rgames> rbind(foo,c(1,3))
[,1] [,2]
[1,]13
Rgames> foo <- NULL
Rgames> # rbind(foo,as.bigz(c(1,3))) ## instant crash
Further playing around suggests that , given that as.bigz(NULL) returns
a "bigz(0) " empty object, gmp is really unhappy trying to do almost
anything with said object.
regards,
Carl
Crash log follows
Process: R [11657]
Path: /Applications/R.app/Contents/MacOS/R
Identifier:org.R-project.R
Version: R 4.2.2 GUI 1.79 High Sierra build (8160)
Code Type: X86-64 (Native)
Parent Process:??? [1]
Responsible: R [11657]
User ID: 502
Date/Time: 2022-11-16 19:42:41.462 -0500
OS Version:macOS 11.6.8 (20G730)
Report Version:12
Anonymous UUID:B755C094-C366-46AB-8EEA-9D3B8E7B388D
Sleep/Wake UUID: D725679E-AF7A-4203-8EA3-B313AA2846F5
Time Awake Since Boot: 98000 seconds
Time Since Wake: 2100 seconds
System Integrity Protection: enabled
Crashed Thread:0 Dispatch queue: com.apple.main-thread
Exception Type:EXC_ARITHMETIC (SIGFPE)
Exception Codes: EXC_I386_DIV (divide by zero)
Exception Note:EXC_CORPSE_NOTIFY
Termination Signal:Floating point exception: 8
Termination Reason:Namespace SIGNAL, Code 0x8
Terminating Process: exc handler [11657]
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 gmp.so 0x0001149159c2
math::Matrix::nCols() const + 34
1 gmp.so 0x00011491e5af
matrixz::bigint_transpose(bigvec&) + 47
2 gmp.so 0x00011491f8be biginteger_rbind +
158
3 libR.dylib 0x000104b3f8dc R_doDotCall + 1420
(dotcode.c:601)
4 libR.dylib 0x000104b8b7ed bcEval + 104269
(eval.c:7692)
5 libR.dylib 0x000104b71a01 Rf_eval + 385
(eval.c:748)
6 libR.dylib 0x000104b91839 R_execClosure + 2169
7 libR.dylib 0x000104b90627 Rf_applyClosure +
471 (eval.c:1844)
8 libR.dylib 0x000104af61db do_bind + 1051
(bind.c:1118)
9 libR.dylib 0x000104bdbbfa do_internal + 362
(names.c:1399)
10 libR.dylib 0x000104b7920d bcEval + 29037
(eval.c:7156)
11 libR.dylib 0x000104b71a01 Rf_eval + 385
(eval.c:748)
12 libR.dylib 0x000104b91839 R_execClosure + 2169
13 libR.dylib 0x000104b90627 Rf_applyClosure +
471 (eval.c:1844)
14 libR.dylib
Re: [R-SIG-Mac] another R crash issue
This is a clear bug in gmp (the R package) - simply division by zero in templateMatrix.h:126:return this->size() / nRows(); * frame #0: 0x0001076e1b12 gmp.so`math::Matrix::nCols(this=0x7ffeefbfc5d8) const at templateMatrix.h:126:25 [opt] frame #1: 0x0001076ea253 gmp.so`matrixz::bigint_transpose(mat=0x7ffeefbfc5d8) at matrix.cc:484:23 [opt] frame #2: 0x0001076eb3be gmp.so`::biginteger_rbind(args=0x000108a60848) at matrix.cc:459:12 [opt] i.e., bigint_transpose() cannot deal with 0-row matrices. That may be just the tip of the ice berg, even biginteger_rbind itself should probably just skip zero-length objects. Cheers, Simon > On 17/11/2022, at 9:50 PM, Martin Maechler wrote: > >> Carl Witthoft >>on Wed, 16 Nov 2022 19:58:31 -0500 writes: > >> This may be the fault of the `gmp` library, but posting to r-sig as well >> just in case. > >> Mac OS 11.6.8 , R 4.2.2 > > Yes, the gmp package Mac version gives immediate seg faults. > > Prof Brian Ripley has already alerted the gmp package maintainer, me > (a gmp package co-author, not familiar with the C++ design in > there, and maintainer of dependent R package 'Rmpfr') and > the CRAN team. > > He has debugged deeply and tediously until diagnosing the > problem happens in *assembler* (!) code of the libgmp.a library > (i.e, the 'gmp' C library that has nothing to do with R). > > Brian Ripley further found that when using the latest > *development* version of that gmp C library and building libgmp > and R packages gmp and Rmpfr himself from the sources he got no > more segfaults. > > The problem is only seen on the Mac. > > Martin > > >> Consider the following work: > >Rgames> foo <- NULL >Rgames> rbind(foo,c(1,3)) >> [,1] [,2] >> [1,]13 >Rgames> foo <- NULL >Rgames> # rbind(foo,as.bigz(c(1,3))) ## instant crash > > >> Further playing around suggests that , given that as.bigz(NULL) returns >> a "bigz(0) " empty object, gmp is really unhappy trying to do almost >> anything with said object. > > >> regards, >> Carl > > >> Crash log follows >> Process: R [11657] >> Path: /Applications/R.app/Contents/MacOS/R >> Identifier:org.R-project.R >> Version: R 4.2.2 GUI 1.79 High Sierra build (8160) >> Code Type: X86-64 (Native) >> Parent Process:??? [1] >> Responsible: R [11657] >> User ID: 502 > >> Date/Time: 2022-11-16 19:42:41.462 -0500 >> OS Version:macOS 11.6.8 (20G730) >> Report Version:12 >> Anonymous UUID:B755C094-C366-46AB-8EEA-9D3B8E7B388D > >> Sleep/Wake UUID: D725679E-AF7A-4203-8EA3-B313AA2846F5 > >> Time Awake Since Boot: 98000 seconds >> Time Since Wake: 2100 seconds > >> System Integrity Protection: enabled > >> Crashed Thread:0 Dispatch queue: com.apple.main-thread > >> Exception Type:EXC_ARITHMETIC (SIGFPE) >> Exception Codes: EXC_I386_DIV (divide by zero) >> Exception Note:EXC_CORPSE_NOTIFY > >> Termination Signal:Floating point exception: 8 >> Termination Reason:Namespace SIGNAL, Code 0x8 >> Terminating Process: exc handler [11657] > >> Thread 0 Crashed:: Dispatch queue: com.apple.main-thread >> 0 gmp.so 0x0001149159c2 >> math::Matrix::nCols() const + 34 >> 1 gmp.so 0x00011491e5af >> matrixz::bigint_transpose(bigvec&) + 47 >> 2 gmp.so 0x00011491f8be biginteger_rbind + >> 158 >> 3 libR.dylib 0x000104b3f8dc R_doDotCall + 1420 >> (dotcode.c:601) >> 4 libR.dylib 0x000104b8b7ed bcEval + 104269 >> (eval.c:7692) >> 5 libR.dylib 0x000104b71a01 Rf_eval + 385 >> (eval.c:748) >> 6 libR.dylib 0x000104b91839 R_execClosure + 2169 >> 7 libR.dylib 0x000104b90627 Rf_applyClosure + >> 471 (eval.c:1844) >> 8 libR.dylib 0x000104af61db do_bind + 1051 >> (bind.c:1118) >> 9 libR.dylib 0x000104bdbbfa do_internal + 362 >> (names.c:1399) >> 10 libR.dylib 0x000104b7920d bcEval + 29037 >> (eval.c:7156) >> 11 libR.dylib 0x000104b71a01 Rf_eval + 385 >> (eval.c:748) >> 12 libR.dylib 0x000104b91839 R_execClosure + 2169 >> 13 libR.dylib 0x000104b90627 Rf_applyClosure + >> 471 (eval.c:1844) >> 14 libR.dylib 0x000104b71ebb Rf_eval + 1595 >> (eval.c:871) >> 15 libR.dylib 0x000104b95821 do_eval + 625 >> (eval.c:3366) >> 16 libR.dylib 0x000104b79035 bcEval + 28565 >> (eval.c:7136) >> 17 libR.dylib 0x000104b71a01 Rf_eval + 385 >> (eval.c:748) >> 18 libR.dylib
Re: [R-SIG-Mac] another R crash issue
> Carl Witthoft > on Wed, 16 Nov 2022 19:58:31 -0500 writes: > This may be the fault of the `gmp` library, but posting to r-sig as well > just in case. > Mac OS 11.6.8 , R 4.2.2 Yes, the gmp package Mac version gives immediate seg faults. Prof Brian Ripley has already alerted the gmp package maintainer, me (a gmp package co-author, not familiar with the C++ design in there, and maintainer of dependent R package 'Rmpfr') and the CRAN team. He has debugged deeply and tediously until diagnosing the problem happens in *assembler* (!) code of the libgmp.a library (i.e, the 'gmp' C library that has nothing to do with R). Brian Ripley further found that when using the latest *development* version of that gmp C library and building libgmp and R packages gmp and Rmpfr himself from the sources he got no more segfaults. The problem is only seen on the Mac. Martin > Consider the following work: Rgames> foo <- NULL Rgames> rbind(foo,c(1,3)) > [,1] [,2] > [1,]13 Rgames> foo <- NULL Rgames> # rbind(foo,as.bigz(c(1,3))) ## instant crash > Further playing around suggests that , given that as.bigz(NULL) returns > a "bigz(0) " empty object, gmp is really unhappy trying to do almost > anything with said object. > regards, > Carl > Crash log follows > Process: R [11657] > Path: /Applications/R.app/Contents/MacOS/R > Identifier:org.R-project.R > Version: R 4.2.2 GUI 1.79 High Sierra build (8160) > Code Type: X86-64 (Native) > Parent Process:??? [1] > Responsible: R [11657] > User ID: 502 > Date/Time: 2022-11-16 19:42:41.462 -0500 > OS Version:macOS 11.6.8 (20G730) > Report Version:12 > Anonymous UUID:B755C094-C366-46AB-8EEA-9D3B8E7B388D > Sleep/Wake UUID: D725679E-AF7A-4203-8EA3-B313AA2846F5 > Time Awake Since Boot: 98000 seconds > Time Since Wake: 2100 seconds > System Integrity Protection: enabled > Crashed Thread:0 Dispatch queue: com.apple.main-thread > Exception Type:EXC_ARITHMETIC (SIGFPE) > Exception Codes: EXC_I386_DIV (divide by zero) > Exception Note:EXC_CORPSE_NOTIFY > Termination Signal:Floating point exception: 8 > Termination Reason:Namespace SIGNAL, Code 0x8 > Terminating Process: exc handler [11657] > Thread 0 Crashed:: Dispatch queue: com.apple.main-thread > 0 gmp.so0x0001149159c2 > math::Matrix::nCols() const + 34 > 1 gmp.so0x00011491e5af > matrixz::bigint_transpose(bigvec&) + 47 > 2 gmp.so0x00011491f8be biginteger_rbind + 158 > 3 libR.dylib0x000104b3f8dc R_doDotCall + 1420 > (dotcode.c:601) > 4 libR.dylib0x000104b8b7ed bcEval + 104269 > (eval.c:7692) > 5 libR.dylib0x000104b71a01 Rf_eval + 385 > (eval.c:748) > 6 libR.dylib0x000104b91839 R_execClosure + 2169 > 7 libR.dylib0x000104b90627 Rf_applyClosure + > 471 (eval.c:1844) > 8 libR.dylib0x000104af61db do_bind + 1051 > (bind.c:1118) > 9 libR.dylib0x000104bdbbfa do_internal + 362 > (names.c:1399) > 10 libR.dylib0x000104b7920d bcEval + 29037 > (eval.c:7156) > 11 libR.dylib0x000104b71a01 Rf_eval + 385 > (eval.c:748) > 12 libR.dylib0x000104b91839 R_execClosure + 2169 > 13 libR.dylib0x000104b90627 Rf_applyClosure + > 471 (eval.c:1844) > 14 libR.dylib0x000104b71ebb Rf_eval + 1595 > (eval.c:871) > 15 libR.dylib0x000104b95821 do_eval + 625 > (eval.c:3366) > 16 libR.dylib0x000104b79035 bcEval + 28565 > (eval.c:7136) > 17 libR.dylib0x000104b71a01 Rf_eval + 385 > (eval.c:748) > 18 libR.dylib0x000104b91839 R_execClosure + 2169 > 19 libR.dylib0x000104b90627 Rf_applyClosure + > 471 (eval.c:1844) > 20 libR.dylib0x000104b7892e bcEval + 26766 > (eval.c:7104) > 21 libR.dylib0x000104b71a01 Rf_eval + 385 > (eval.c:748) > 22 libR.dylib0x000104b91839 R_execClosure + 2169 > 23 libR.dylib
