-
Notifications
You must be signed in to change notification settings - Fork 1k
Avoid memcpy(dst, NULL, 0) in forder.c
#7055
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
During thread contention, it's possible for a thread to not call push() even once, leaving gs_thread[me] unallocated. The resulting call to memcpy() was noticed by a sanitizer during additional CRAN checks.
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #7055 +/- ##
=======================================
Coverage 98.69% 98.69%
=======================================
Files 79 79
Lines 14676 14676
=======================================
Hits 14485 14485
Misses 191 191 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
Generated via commit ac7ac01 Download link for the artifact containing the test results: ↓ atime-results.zip
|
|
LGTM (needs a test); I'll let Jan review based on how it will fit into the ongoing froll workstream. |
jangorecki
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, could have nocov marker because codecov now complaints about added line
Currently, the condition is only encountered during thread contention, which is prohibitively expensive to test or at least requires non-portable tricks.
|
Thanks! Currently I don't know any way besides adding the # nocov. I
can reproduce the issue either by running cat /dev/urandom > /dev/null
on every CPU core or by pinning all data.table threads to one CPU core
prior to running the R script, and neither seems appropriate for an R
package test.
|
* flush(): avoid memcpy(<dst>, NULL, 0) During thread contention, it's possible for a thread to not call push() even once, leaving gs_thread[me] unallocated. The resulting call to memcpy() was noticed by a sanitizer during additional CRAN checks. * NEWS item * Add nocov to the hard-to-test branch Currently, the condition is only encountered during thread contention, which is prohibitively expensive to test or at least requires non-portable tricks. * Explain why the branch is #nocov

Closes: #7051. Tested manually by running the reproducer in the same configuration that previously showed the warning. The NEWS item is technically correct but may be overly detailed.
Looking at the remaining
memcpy()calls, I wasn't able to find any definite examples of the same thing happening; there's usually a way to prove that the size is above 0. Possible issues in the newfrollcode are tracked in #7054.