-
Notifications
You must be signed in to change notification settings - Fork 11
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
[v6.24] Cling: prevent double release of Transactions #153
[v6.24] Cling: prevent double release of Transactions #153
Conversation
new of a char array might not have the correct alignment to hold a Transaction. Allocate a Transaction itself directly, instead of in-place constructing it in the character array. Each Transaction in the pool is thus constructed through `new Transaction(S)` and destructed through `delete T`, which is nicely symmetrical. The use of `::operator new` and `::operator delete` isn't actually necessary. While I'm at it, improve the assert message's wording.
This will allow Transaction remembering its RAII to not depend on Interpreter.
This will allow the Intrepreter to prevent unload() on Transactions held by RAIIs.
When a Transaction is unloaded for which *also* a ScopedTransactionRAII is waiting, the latter will potentially access a deleted Transaction. It can be deleted due to the Pool being full. Even if it is not deleted (as is the case in root-project#7657 ) it will get pushed into the Pool once by unload() and a second time by the RAII! The two options to track this case were full-blown ref counting or noting that a Transaction is attached to an RAII scope. If that is the case, freeing the Transaction must be skipped, as the RAII will take care of it.
a cheap way to notice what went wrong in root-project#7657.
A new Pull Request was created by @smuzaffar (Malik Shahzad Muzaffar) for branch cms/v6-24-00-patches/126c9c8. @cmsbuild, @smuzaffar, @mrodozov can you please review it and eventually sign? Thanks. |
please test with cms-sw/cmsdist#6777 |
+1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-feb1ca/13902/summary.html Comparison SummarySummary:
|
@slava77 , can you please check these reco comparison differences? These are for root 6.24 based cmssw |
please test with cms-sw/cmsdist#6777 |
test parameters:
|
please test with cms-sw/cmsdist#6777 |
the differences look like the baseline was different in more than jut this PR; most likely in cms-sw/cmsdist#6769 the tests were done on top of CMSSW_11_3_ROOT624_X_2021-03-29-2300, which is made before cms-sw/cmsdist#6769 was merged. |
Thanks @slava77 for your analysis. As I have restarted the tests, so hopefully comparisons should be better now. |
+1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-feb1ca/13915/summary.html Comparison SummarySummary:
|
comparison results look better now |
please test with cms-sw/cms-bot#1530,cms-sw/cmsdist#6777 |
+1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-feb1ca/13959/summary.html The following merge commits were also included on top of IB + this PR after doing git cms-merge-topic:
You can see more details here: Comparison SummaryThe workflows 140.53 have different files in step1_dasquery.log than the ones found in the baseline. You may want to check and retrigger the tests if necessary. You can check it in the "files" directory in the results of the comparisons Summary:
|
No description provided.