Error: std::bad_alloc in test-unordered on ppc32

[barracuda156]

* using log directory ‘/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_R_R-literanger/R-literanger/work/literanger-0.0.2/literanger.Rcheck’
* using R version 4.3.1 (2023-06-16)
* using platform: powerpc-apple-darwin10.0.0d2 (32-bit)
* R was compiled by
    gcc-mp-12 (MacPorts gcc12 12.3.0_0) 12.3.0
    GNU Fortran (MacPorts gcc12 12.3.0_0) 12.3.0
* running under: OS X Snow Leopard 10.6
* using session charset: UTF-8
* checking for file ‘literanger/DESCRIPTION’ ... OK
* this is package ‘literanger’ version ‘0.0.2’
* package encoding: UTF-8
* checking package namespace information ... OK
* checking package dependencies ... OK
* checking if this is a source package ... OK
* checking if there is a namespace ... OK
* checking for executable files ... OK
* checking for hidden files and directories ... OK
* checking for portable file names ... OK
* checking for sufficient/correct file permissions ... OK
* checking whether package ‘literanger’ can be installed ... OK
* used C++ compiler: ‘g++-mp-12 (MacPorts gcc12 12.3.0_0) 12.3.0’
* used SDK: ‘NA’‘NA’‘NA’‘NA’‘NA’‘NA’
* checking installed package size ... OK
* checking package directory ... OK
* checking DESCRIPTION meta-information ... OK
* checking top-level files ... OK
* checking for left-over files ... OK
* checking index information ... OK
* checking package subdirectories ... OK
* checking R files for non-ASCII characters ... OK
* checking R files for syntax errors ... OK
* checking whether the package can be loaded ... OK
* checking whether the package can be loaded with stated dependencies ... OK
* checking whether the package can be unloaded cleanly ... OK
* checking whether the namespace can be loaded with stated dependencies ... OK
* checking whether the namespace can be unloaded cleanly ... OK
* checking loading without being on the library search path ... OK
* checking dependencies in R code ... OK
* checking S3 generic/method consistency ... OK
* checking replacement functions ... OK
* checking foreign function calls ... OK
* checking R code for possible problems ... OK
* checking Rd files ... OK
* checking Rd metadata ... OK
* checking Rd cross-references ... OK
* checking for missing documentation entries ... OK
* checking for code/documentation mismatches ... OK
* checking Rd \usage sections ... OK
* checking Rd contents ... OK
* checking for unstated dependencies in examples ... OK
* checking line endings in C/C++/Fortran sources/headers ... OK
* checking line endings in Makefiles ... OK
* checking compilation flags in Makevars ... OK
* checking for GNU extensions in Makefiles ... OK
* checking for portable use of $(BLAS_LIBS) and $(LAPACK_LIBS) ... OK
* checking use of PKG_*FLAGS in Makefiles ... OK
* checking compiled code ... OK
* checking examples ... OK
* checking for unstated dependencies in ‘tests’ ... OK
* checking tests ... ERROR
  Running ‘testthat.R’
Running the tests in ‘tests/testthat.R’ failed.
Last 13 lines of output:
  Error: std::bad_alloc
  Backtrace:
      ▆
   1. └─literanger::train(data = dat_class, response_name = "y", unordered_predictors = "partition") at test-unordered.R:52:4
   2.   └─literanger:::cpp11_train(...)
  ── Error ('test-unordered.R:178:5'): can predict unobserved levels given unordered predictors ──
  Error: std::bad_alloc
  Backtrace:
      ▆
   1. └─literanger::train(data = dat_train, response_name = "y", unordered_predictors = "partition") at test-unordered.R:178:4
   2.   └─literanger:::cpp11_train(...)
  
  [ FAIL 3 | WARN 0 | SKIP 0 | PASS 188 ]
  Error: Test failures
  Execution halted
* checking PDF version of manual ... OK
* DONE
Status: 1 ERROR

P. S. This is not necessarily a problem with the code, since malloc errors show up once in a while when there are duplicate libstdc++ (one belonging to the OS and another to GCC). However, for R we have fixed that problem, and I do not see it now when testing packages. So possibly something assumes 64-bitness?

[stephematician]

There are assumptions about sizes within the "partition" code; this would be the cause of the failure. Thanks for picking this one up.

Probably affects Windows i386 (32-bit) too.

[barracuda156]

@stephematician Thank you! Once there is a fix, I will test it.

[stephematician]

@barracuda156 - I've looked through the partition code; it's not clear to me why there's a bad alloc. I don't have a powerpc to debug on so looks like this one won't get fixed by me.

[barracuda156]

@stephematician Do tests pass fine on 32-bit Linux (i.e., i386)?

[stephematician]

They pass on Windows i386 (32-bit). I have not tested building i386 R on Linux.

Valgrind passes, and as far as i know, the ASAN tests on CRAN pass, too.

If I had a stacktrace that included the library calls then I'd know where to start looking.

[barracuda156]

@stephematician

If I had a stacktrace that included the library calls then I'd know where to start looking

How do I get it? Run a test binary via GDB?

[stephematician]

I think so; that's roughly how I debug on Ubuntu - e.g. I'll run R -d gdb --vanilla and try the tests (e.g. pkgbuild::compile_dll/testthat::test_local or devtools::test probably will do). Any exception should bring up GDB prompt and you can get the stack info from there.

I'm not the most experienced dev, so if you have any suggestions, let me know!

[barracuda156]

@stephematician Sorry for a delay, I will return to this shortly.

[stephematician]

@barracuda156 - just letting you know I've tested with linux i386 (via Docker, i386/ubuntu image - stock standard build-essential kit) and there were no failures during the test.

[barracuda156]

@stephematician Thank you! And thanks for reminding of the issue – it got lost in the queue of to-dos :(

I gonna re-run tests and try to get meaningful output.

[barracuda156]

UPD1. The error did not vanish with gcc13, just for the record.
Will update on the issue further.

[barracuda156]

@stephematician I will test the updated version now.

[stephematician]

Hi - thanks, I've moved the project to gitlab: https://gitlab.com/stephematician/literanger - so stay tuned there for updates.