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 0x000
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