Issues with memory management in fmelt

[MichaelChirico]

As identified by rchk on CRAN:

https://raw.githubusercontent.com/kalibera/cran-checks/master/rchk/results/data.table.out

Function checkVars
  [UP] allocating function uniq_diff may destroy its unprotected argument (measure_int_or_list <arg 1>), which is later used. data.table/src/fmelt.c:251
Function uniq_diff
  [UP] calling allocating function set_diff(V,?) with a fresh pointer (unique_col_numbers <arg 1>) data.table/src/fmelt.c:201

Note that the cols_to_int_or_list() output is indeed PROTECT()'d properly in other nearby branches. This makes sense because measure_int_or_list is a new SEXP not yet on the stack that must be marked against gc removal.

[github-actions]

Generated via commit ea67015

Download link for the artifact containing the test results: ↓ atime-results.zip

Time taken to finish the standard R installation steps: 12 minutes and 10 seconds

Time taken to run atime::atime_pkg on the tests: 3 minutes and 23 seconds

[tdhock]

great. I wrote this code and I guess forgot a PROTECT, thanks for looking at rchk results and providing a fix. add a NEWS item?

[tdhock]

does this one fix handle all three rchk issues in fmelt.c?

Function checkVars
  [UP] allocating function uniq_diff may destroy its unprotected argument (measure_int_or_list <arg 1>), which is later used. data.table/src/fmelt.c:251
  [UP] calling allocating function uniq_diff with a fresh pointer (measure_int_or_list <arg 1>) data.table/src/fmelt.c:251
  [UP] unprotected variable measure_int_or_list while calling allocating function Rf_allocVector data.table/src/fmelt.c:254

I'm not used to reading / understanding these messages, are some redundant with each other?

[MichaelChirico]

does this one fix handle all three rchk issues in fmelt.c?

I'm also not sure, but yes that's my read.

I'll add NEWS in a bit