[I/O] Race condition when reading vectors with custom allocators with TTreeProcessorMT #10357
Comments
|
@pcanal suggests the following patch which does seem to fix the crash for me: diff --git a/core/meta/src/TClass.cxx b/core/meta/src/TClass.cxx
index a36ff3f6f5..ba5dbc50d6 100644
--- a/core/meta/src/TClass.cxx
+++ b/core/meta/src/TClass.cxx
@@ -5414,7 +5414,7 @@ void TClass::Destructor(void *obj, Bool_t dtorOnly)
// There is no dictionary at all, so this is an emulated
// class; however we do have the services of a collection proxy,
// so this is an emulated STL class.
- fCollectionProxy->Destructor(p, dtorOnly);
+ GetCollectionProxy()->Destructor(p, dtorOnly);
} else if (!HasInterpreterInfo() && !fCollectionProxy) {
// There is no dictionary at all and we do not have
// the services of a collection proxy available, so
@@ -5540,7 +5540,7 @@ void TClass::DeleteArray(void *ary, Bool_t dtorOnly)
// There is no dictionary at all, so this is an emulated
// class; however we do have the services of a collection proxy,
// so this is an emulated STL class.
- fCollectionProxy->DeleteArray(ary, dtorOnly);
+ GetCollectionProxy()->DeleteArray(ary, dtorOnly);
} else if (!HasInterpreterInfo() && !fCollectionProxy) {
// There is no dictionary at all and we do not have
// the services of a collection proxy available, so |
|
Valgrind's helgrind sees several problems, but it is not to be trusted completely as it does not understand the thread synchronization semantics of TBB tasks. One of the reports that seems relevant is e.g.: |
|
The problem appears when reading branch type |
eguiraud
added a commit
to eguiraud/root
that referenced
this issue
Apr 8, 2022
This fixes root-project#10357 (a race condition when reading vectors with custom allocators with TTreeProcessorMT that also affected RDataFrame). Co-authored-by: Philippe Canal <pcanal@fnal.gov>
eguiraud
added a commit
that referenced
this issue
Apr 10, 2022
This fixes #10357 (a race condition when reading vectors with custom allocators with TTreeProcessorMT that also affected RDataFrame). Co-authored-by: Philippe Canal <pcanal@fnal.gov>
eguiraud
added a commit
to eguiraud/root
that referenced
this issue
Apr 10, 2022
This fixes root-project#10357 (a race condition when reading vectors with custom allocators with TTreeProcessorMT that also affected RDataFrame). Co-authored-by: Philippe Canal <pcanal@fnal.gov>
|
Reopening until backport is in. |
eguiraud
added a commit
that referenced
this issue
Apr 10, 2022
This fixes #10357 (a race condition when reading vectors with custom allocators with TTreeProcessorMT that also affected RDataFrame). Co-authored-by: Philippe Canal <pcanal@fnal.gov>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is a reproducer (segfaults frequently but not always):
With these files: files.zip
The problem seems to be at the level of TGenCollectionProxy: multiple threads end up sharing the same TGenCollectionProxy objects, which is not thread safe (e.g. because of
root/io/io/src/TEmulatedCollectionProxy.cxx
Lines 84 to 85 in bce5777
Example backtraces at the point of crash (this is one of several failure modes, but it's the one where the problem is clear -- both threads, at frame 0, are accessing the same TGenCollectionProxy instance):
First reported at https://root-forum.cern.ch/t/root-6-26-00-issue-with-multi-threaded-rdataframe-and-rvec/49310 .
The text was updated successfully, but these errors were encountered: