-
Notifications
You must be signed in to change notification settings - Fork 1
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
196 Potential race condition in read-modify-write PDF vectors in parallel loop in onesource::generatePDF() #206
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #206 +/- ##
==========================================
+ Coverage 66.29% 66.65% +0.35%
==========================================
Files 50 50
Lines 6169 6229 +60
Branches 928 937 +9
==========================================
+ Hits 4090 4152 +62
+ Misses 2079 2077 -2 ☔ View full report in Codecov by Sentry. |
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.
CMakeLists.txt
Outdated
message(STATUS "Building with thread sanitizing enabled.") | ||
SET(GCC_COVERAGE_COMPILE_FLAGS "-g -O2 -fsanitize=thread") | ||
SET(GCC_COVERAGE_LINK_FLAGS "-fsanitize=thread") | ||
SET( CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${GCC_COVERAGE_COMPILE_FLAGS}" ) |
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.
There's a coding style inconsistency here: space between the parentheses and variable name vs. no space.
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.
agreed, fixed in #7aee2ff
CMakeLists.txt
Outdated
SET(GCC_COVERAGE_COMPILE_FLAGS "-g -O2 -fsanitize=thread") | ||
SET(GCC_COVERAGE_LINK_FLAGS "-fsanitize=thread") | ||
SET( CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${GCC_COVERAGE_COMPILE_FLAGS}" ) | ||
SET( CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} ${GCC_COVERAGE_LINK_FLAGS}" ) |
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.
There's a coding style inconsistency here: space between the parentheses and variable name vs. no space.
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.
agreed, fixed in #7aee2ff
CMakeLists.txt
Outdated
if(DEFINED ENV{INCLUDE_COVERAGE}) | ||
message(STATUS "Building with code coverage enabled.") | ||
SET(GCC_COVERAGE_COMPILE_FLAGS "-g -O0 -coverage -fprofile-arcs -ftest-coverage") | ||
SET(GCC_COVERAGE_LINK_FLAGS "-coverage -lgcov") | ||
SET(GCC_COVERAGE_COMPILE_FLAGS "-g -O0 -coverage -fprofile-arcs -ftest-coverage -fPIC -pie") |
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.
Are explicit -fPIC
and -pie
really required here ? These flags are platform-dependent.
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.
agreed. Fixed in #7aee2ff
pdfcol1.vPDF.assign((PDFcol1loc), (PDFcol1loc+pdfcol1.size())); | ||
pdfcol2.vPDF.assign((PDFcol2loc), (PDFcol2loc+pdfcol2.size())); | ||
pdfmref.vPDF.assign((PDFmrefloc), (PDFmrefloc+pdfmref.size())); | ||
pdfbayzg.vPDF.assign((PDFzloc), (PDFzloc + pdfbayzg.size())); |
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.
This is a coding style change unrelated to the pull request, should it have a different commit ?
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.
It is done automatically by pre-commit, and comes from a previous merge from you that I forced, so I think we can get it through here now.
Hello, Johann, the conclusion for these patches is that they work now, but when enabling the thread sanitizer and testing, I'm receiving what at first look seem to be false positive data races caused by my OpenMP library, which seems to be Intel's library implicitly installed by conda. Are you having any data race warnings ? I think I'll just open another issue that might be closed as invalid if the false positive is confirmed. The main question is then if it makes sense to have an option to enable the thread sanitizer if it doesn't play well with OpenMP. The patch now looks good to me, if this repository allows forced pushes, I suggest squashing the commits with fixups into the original patch (96ab990) to avoid inserting commits with issues in the main branch. https://stackoverflow.com/questions/33004809/can-i-use-thread-sanitizer-for-openmp-programs |
Yes, I also saw a lot of warnings, starting with mag_gal, that I did not understand. A repeating one is the creation of oneSEDInt in each thread out of a given external single oneSED : the thread sanitizer seems to complain about copy constructor.... It may be worth trying suppression as my recollection is that the same warning was repeating itself over and over again. https://github.com/google/sanitizers/wiki/ThreadSanitizerSuppressions |
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.
Ack
…rallel-with-read-modify-write-operation-in-onesourcegeneratepdf
(squashing 3 commits)
This patch allows enabling the address sanitizer functionality present in some compilers to detect memory access errors when using the library. See: https://github.com/google/sanitizers/wiki/AddressSanitizer
…-read-modify-write-operation-in-onesourcegeneratepdf' of github.com:lephare-photoz/lephare into 197-reduction-operation-being-executed-in-parallel-with-read-modify-write-operation-in-onesourcegeneratepdf
@hdante dante looks like you need to redo a formal review :( |
Johann, the resulting code is mostly ok, but the patch set as a whole ended up with some duplicated commits (both the squashed and the original commits are present) and 2 intermediate merges, so I decided to redo the complete pull request into another version: This branch only has 2 commits instead of 8 and is rebased on top of the main branch, so that no intermediate merges are needed. It results in the exact same code as this pull request. If you prefer I may open a pull request with that branch. After the commits were simplified I noticed that there might be some comments added in the makefile that are in the wrong place, so we'll need another review of that pull request. |
darn.... so my squashing did not proceed as planned? Yes let's do as you suggest. |
Ok, created pull request #209 |
…-read-modify-write-operation-in-onesourcegeneratepdf' into johannct-patch-1
Fix comments in CMakeLists.txt
This has been dealt with more properly in another PR |
Change Description
Solution Description
Code Quality
Project-Specific Pull Request Checklists
Bug Fix Checklist
New Feature Checklist
Documentation Change Checklist
Build/CI Change Checklist
Other Change Checklist