Repository navigation
Fix CRAN R CMD check issues by 2026-02-01 #7587
Description
Activity
Can confirm, received the email earlier today. Have until February 1. No additional details were provided by CRAN team. I created the
patch-1.18.2branch based on the 1.18.0 release for us to work with.What does the email say? Is it about ATTRIB, rchk or valgrind?
ATTRIBspecifically:Specifically, please see the NOTE in the compiled code check about using ATTRIB or SET_ATTRIB. These are from \item Packages using the non-API functions \code{ATTRIB} and \code{SET_ATTRIB} will now receive check \samp{NOTE}s. See \sQuote{Writing R Extensions} for alternatives to use. where "Working with attributes" in R-exts has details on alternatives.Reacted by Benjamin Schwendinger and Michael ChiricoGreat! I pushed as
cherry-pickall the issues onmasterI think can be submitted in the patch:https://github.com/Rdatatable/data.table/compare/1.18.0..patch-1.18.2
@ben-schwen should we include #7538?
Reacted by Tyson BarrettIs there anything else we should put into the patch? IMO it's ready to submit whenever you have time.
https://rcdata.nau.edu/genomic-ml/data.table-revdeps/analyze/2026-01-12/ is clean too (though there's still the issue of ~1000 packages not installing: tdhock/data.table-revdeps#37)
cc @Rdatatable/committers.
This is great, I'll have time this upcoming weekend to get this submitted. I'll notify when I start the process for this patch in case there are any other small fixes we want to include.
Please also use assignment of issues to 1.18.2 milestone, so it is very clear to browse through. Thank for looking after patch release.
Reacted by Michael Chirico, aitap, Tyson Barrett and Benjamin Schwendinger- f72637a (patch-1.18.2) passes R CMD check --as-cran with only a few false positives in URL checks. Out of the ~20 reverse dependencies currently in trouble for #7583, the new version causes tidytable to fail with df1 <- tidytable(x = 1:3) df2 <- tidytable(x = c(2, 3, 3), y = c("a", "b", "c")) out <- nest_join(df1, df2) Error in bmerge(i, x, leftcols, rightcols, roll, rollends, nomatch, mult, : typeof x.x (double) != typeof i.x (integer) Calls: nest_join -> left_join -> [ -> [.data.table -> bmerge Execution halted Investigating... Edit: see #7604
Thanks, @aitap. I'll start the release process tonight and likely get this off to CRAN tomorrow.
Reacted by Shiyu Hu and Jan Gorecki4 remaining items
strange that this started with 1.18.2, does this happen with 1.18.0? did something change in r-devel?
- Same thing happens on R-4.2.2/data.table-master. I can even cherry-pick 7d70b15 (#7548) on top of 3c044ce (where the second call to test.data.table() appears in tests/froll.R), and the symptoms are very similar: $ R -d valgrind -f tests/froll.R ...test.data.table(script="frollBatch.Rraw", optional=TRUE) require(data.table) test.data.table(script="froll.Rraw")... With OMP_THREAD_LIMIT=1, the infinite loop disappears. This makes the issues reported in #7546 a bit suspect, although as far as I can tell, they were real; disabling mcparallel() doesn't make them go away. Cherry-picking #7548 on top of f1aab37 (parent of 3c044ce) results in tests/froll.R that takes a very long time under Valgrind to run test.data.table() once, I ran out of patience. I think it might misbehave under Valgrind as well. The following is enough to confuse Rstd_ReadConsole(): library(parallel) letters |> sample(1e3, TRUE) |> order(method = 'radix') |> mcparallel() -> p q <- mccollect(p) Under R -d valgrind -f foo.R, the third line runs twice. I couldn't find an example that doesn't use threads in the child process. If we have to fix this, the tests on CRAN could use Sys.getenv("OMP_THREAD_LIMIT", "1") instead of "2", (with a comment that this is required to work around a problem in Valgrind itself), and our CI could set OMP_THREAD_LIMIT=$(nproc) to override this.
My previous setup for testing under valgrind was a little messed up but now testing on r-devel in docker looks like this is now passing (and can be used for future releases). Will amend the version to
1.18.2-1for CRAN and resubmit.As a heads up,
packageVersion()normalized1.18.2-1to1.18.2.1, which is called duringonLoad()and so using anything other than dots will give us an error there (unless we want to adjust our onLoad function to avoid that normalization to all dots). I'll update the release docs as long as we are ok with1.18.2.1as the resubmitted version of1.18.2.Reacted by Michael Chirico, Jan Gorecki and aitapI'm not sure I understand this NOTE and why it would be considered a failed pretest. Anyone understand it? It is the test under valgrind.
Package check result: NOTE Check: tests, Result: NOTE Running ‘S4.R’ [13s/13s] Running ‘autoprint.R’ [10s/10s] Comparing ‘autoprint.Rout’ to ‘autoprint.Rout.save’ ... 1,5d0 < ==773278== Memcheck, a memory error detector < ==773278== Copyright (C) 2002-2024, and GNU GPL'd, by Julian Seward et al. < ==773278== Using Valgrind-3.25.1 and LibVEX; rerun with -h for copyright info < ==773278== Command: /home/hornik/tmp/R-d-gcc-valg/bin/exec/R -f autoprint.R --restore --save --no-readline --vanilla < ==773278== 187,204d181 < > proc.time() < user system elapsed < 9.202 0.232 8.611 < ==773278== < ==773278== HEAP SUMMARY: < ==773278== in use at exit: 58,125,770 bytes in 10,720 blocks < ==773278== total heap usage: 30,910 allocs, 20,190 frees, 89,635,873 bytes allocated < ==773278== < ==773278== LEAK SUMMARY: < ==773278== definitely lost: 0 bytes in 0 blocks < ==773278== indirectly lost: 0 bytes in 0 blocks < ==773278== possibly lost: 0 bytes in 0 blocks < ==773278== still reachable: 58,125,770 bytes in 10,720 blocks < ==773278== suppressed: 0 bytes in 0 blocks < ==773278== Rerun with --leak-check=full to see details of leaked memory < ==773278== < ==773278== For lists of detected and suppressed errors, rerun with: -s < ==773278== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) Running ‘froll.R’ [54s/54s] Running ‘knitr.R’ [12s/12s] Comparing ‘knitr.Rout’ to ‘knitr.Rout.save’ ... 1,5d0 < ==773575== Memcheck, a memory error detector < ==773575== Copyright (C) 2002-2024, and GNU GPL'd, by Julian Seward et al. < ==773575== Using Valgrind-3.25.1 and LibVEX; rerun with -h for copyright info < ==773575== Command: /home/hornik/tmp/R-d-gcc-valg/bin/exec/R -f knitr.R --restore --save --no-readline --vanilla < ==773575== 60,77d54 < > proc.time() < user system elapsed < 10.644 0.221 10.026 < ==773575== < ==773575== HEAP SUMMARY: < ==773575== in use at exit: 66,029,518 bytes in 12,589 blocks < ==773575== total heap usage: 41,416 allocs, 28,827 frees, 106,364,631 bytes allocated < ==773575== < ==773575== LEAK SUMMARY: < ==773575== definitely lost: 0 bytes in 0 blocks < ==773575== indirectly lost: 0 bytes in 0 blocks < ==773575== possibly lost: 0 bytes in 0 blocks < ==773575== still reachable: 66,027,670 bytes in 12,568 blocks < ==773575== suppressed: 0 bytes in 0 blocks < ==773575== Rerun with --leak-check=full to see details of leaked memory < ==773575== < ==773575== For lists of detected and suppressed errors, rerun with: -s < ==773575== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) Running ‘main.R’ [25m/25m] Running ‘mergelist.R’ [59s/59s] Running ‘nafill.R’ [16s/16s] Running ‘other.R’ [9s/9s] Running ‘programming.R’ [38s/37s] Running ‘types.R’ [13s/13s]I can argue that this shouldn't stop the patch from being published if this isn't important.
It looks like this is just Rout.save differing die to the valgrind output. valgrind itself is not showing any issues.
strange for this to produce a NOTE since this must happen on all Rout.save golden tests?
Reacted by Tyson Barrett- The NOTE is more or less unavoidable with golden tests because Valgrind produces this output into the same standard error stream which is recorded into the .Rout file together with R's output. Maybe this should be fixed in tools:::.runPackageTests -> tools::Rdiff to avoid the need for manual review in such cases?Reacted by Michael Chirico, Tyson Barrett and Jan Gorecki
The resubmitted version is 1.18.2.1 and is passing checks except Kurt just brought up the fact our README link to governance isn't working. Any ideas why that is? If we have to resubmit to fix that, we can cherry-pick #7632.
Reacted by aitapActually, since this is something we can fix in master without a resubmission, I can let him know that that is just a web issue and we should be good to publish 1.18.2.1
Reacted by aitap, Benjamin Schwendinger and Michael ChiricoYes, I guess it was slightly imprudent to be messing around with the website in the middle of submission 😅
Reacted by Tyson BarrettNot a big deal I think, it had to be manually reviewed anyway (hope eventually they can find a better way of handling valgrind outputs) but just another thing to keep in mind during this process.
FWIW Ivan and I fixed the governance homepage thingy 😅
Reacted by Tyson Barrett1.18.2.1 on CRAN and tagged on GitHub.
Reacted by Michael Chirico
This package is failing CRAN checks and is at risk of archival.
https://cran.r-project.org/web/checks/check_results_data.table.html
This issue was opened by https://github.com/Rdatatable/data.table/actions/runs/20909842626.