| f413a53 | Philippe Canal | 03 March 2023, 19:23:45 UTC | fBits read: preserve kIsOnHeap, always set kNotDeleted. Rather than reading from the file the value of kIsOnHeap, preserve the value that was calculated at object creation time (i.e. in the current execution). For example, for an embedded object (inside an object created on the heap or stack), the bit always need to be off (i.e. it can never be explicitly deleted) | 20 December 2023, 18:09:00 UTC |
| e802864 | Philippe Canal | 14 August 2023, 19:36:30 UTC | io: Do not turn on automatically MustClean for TDirectory | 21 August 2023, 16:49:40 UTC |
| 19b18cc | Philippe Canal | 16 August 2023, 00:39:58 UTC | Delete the object held by gROOT after we reset the globals. For example this allows unique_ptr to be deleted first and thus inform TROOT if need be. Fix #13462 | 16 August 2023, 22:44:13 UTC |
| 3557172 | Philippe Canal | 11 November 2022, 04:11:30 UTC | Add Rint as a dependency of rootcling `TCling.cxx`’s `RegisterCxxModules` loads explicitly several modules including `Core`, `Rint` and `RIO`. When executing rootcling (for example for G__Net.cxx) *before* `G__Rint.cxx` was created and thus before `lib/Rint.pcm` was properly created, a default `lib/Rint.pcm` is auto-generated and registered as one of the dependencies. Later the real `lib/Rint.pcm` is created is creation date is later than other `pcm` than depends-on/uses it’s creation time. For example: ``` $ ls -lart lib/Net.pcm lib/MultiProc.pcm lib/Imt.pcm lib/MathCore.pcm lib/Rint.pcm -rw-r--r-- 1 pcanal pcanal 1158548 Nov 10 20:26 lib/Net.pcm -rw-r--r-- 1 pcanal pcanal 1278392 Nov 10 20:27 lib/MultiProc.pcm -rw-r--r-- 1 pcanal pcanal 2032752 Nov 10 20:27 lib/Imt.pcm -rw-r--r-- 1 pcanal pcanal 12911448 Nov 10 20:27 lib/MathCore.pcm -rw-r--r-- 1 pcanal pcanal 444724 Nov 10 20:35 lib/Rint.pcm ``` then later uses of those `pcm` leads to the (mis-worded) error message: ``` <<< cling interactive line includer >>>: fatal error: module file '/home/neel/Desktop/Root/build/lib/Rint.pcm' is out of date and needs to be rebuilt: could not read module signature <<< cling interactive line includer >>>: note: imported by module 'MathCore' in '/home/neel/Desktop/Root/build/lib/MathCore.pcm' Error: Module 'MathCore.pcm' failed to load. Error: Error loading the default rootcling header files. make[2]: *** [math/mathmore/CMakeFiles/G__MathMore.dir/build.make:130: math/mathmore/G__MathMore.cxx] Error 1 ``` See the related circumstances in https://root-forum.cern.ch/t/wsl-build-from-source-error-rint-pcm-is-out-of-date-cannot-read-module-signature/47564/39 The stack trace that was triggers the auto-generation of `Rint.pcm` at /home/pcanal/root_working/code/master/interpreter/llvm/src/tools/clang/lib/Sema/SemaModule.cpp:325 at /home/pcanal/root_working/code/master/interpreter/cling/lib/Interpreter/Interpreter.cpp:908 at /home/pcanal/root_working/code/master/interpreter/cling/lib/Interpreter/Interpreter.cpp:872 at /home/pcanal/root_working/code/master/core/metacling/src/TCling.cxx:1590 | 11 November 2022, 22:37:31 UTC |
| 8de9c82 | Philippe Canal | 16 April 2021, 17:19:20 UTC | TListOfDataMembers ctor: remove redundant assignemnts | 05 October 2022, 17:08:22 UTC |
| 333cd78 | Philippe Canal | 30 November 2020, 21:37:27 UTC | Extend GenerateInfoForPair integrity check | 05 October 2022, 17:08:22 UTC |
| 60ffb22 | Philippe Canal | 25 November 2020, 15:49:51 UTC | Error out if the offset and size hint are the same | 05 October 2022, 17:08:22 UTC |
| da9ac8a | Philippe Canal | 25 November 2020, 15:07:14 UTC | Fix for 43c37311ed Record that the TClass is from GenerateInfoForPair. | 05 October 2022, 17:08:22 UTC |
| 76b21bf | Philippe Canal | 24 November 2020, 19:42:25 UTC | Don't treat all 'char' members as a string. This leads to writing random memory if the member is not a char*. Side note, we should add array support to TClass::Dump | 05 October 2022, 17:08:22 UTC |
| 1bd8792 | Philippe Canal | 21 November 2020, 19:16:18 UTC | Ignore onfile StreamerInfo for Synthetic TClass for pair | 05 October 2022, 17:08:22 UTC |
| 8d187a1 | Philippe Canal | 21 November 2020, 03:37:42 UTC | TStreamerInfo::Build: fix size calculation for synthetic TClass for pair. | 05 October 2022, 17:08:22 UTC |
| 843ca57 | Philippe Canal | 21 November 2020, 03:36:24 UTC | Avoid spurrious warning about missing info in synthetic TClass for pair | 05 October 2022, 17:08:22 UTC |
| de5be5e | Philippe Canal | 21 November 2020, 03:33:37 UTC | Remove deleted StreamerInfo from the global list Note: If a StreamerInfo is loaded from a file and is the same information as an existing one, it is assigned the same "unique id" and we need to double check before removing it from the global list. | 05 October 2022, 17:08:22 UTC |
| 3ca3cb6 | Philippe Canal | 21 November 2020, 02:50:25 UTC | TProtoClass::FillTClass create synthetic pair TClass as needed. Use the data in fPRealData to calculate the offset and size of the pair | 05 October 2022, 17:08:22 UTC |
| 18a224a | Philippe Canal | 21 November 2020, 02:43:31 UTC | Add specialization of TClass::GetClass<T> for pair. Extract the offset and size of the pair and pass it along to raw TClass::GetClass | 05 October 2022, 17:08:22 UTC |
| 488aa66 | Philippe Canal | 21 November 2020, 00:44:04 UTC | TClass::GetClass now create a synthetic instance only if pair hints are provided. Since getting the right alignment and padding is hard (either use Cling/Clang with the associated memory cost and potential autoparsing or duplicating the platform dependent code that calculates it), we now only creates the synthetic TClass instance that represent and std::pair ***if and only*** the call is provided the actual offset of second and sizeof the pair. This information is known to compiled (and later interpreted) CollectionProxy, to TClass for class containing an std::pair (via their list of RealData which is recorded in the rootpcm) and to TClass::GetClass templated on the actual type (since the pair's data members are public) | 05 October 2022, 17:08:22 UTC |
| 1c235c1 | Philippe Canal | 21 November 2020, 00:38:25 UTC | Record that the TClass is from GenerateInfoForPair. The TClass generated by TStreamerInfo::GenerateInfoForPair is neither 'Interpreted' (cling likely does not, yet, have any information about that pair) nor loaded (the user did not request a dictionary for it) but need to have special treatment for those TClass. It is not clear whether this should be a new state. For now we introduce a new data member (`fIsSyntheticPair`) and don't increase the size of TClass instance by using a bit field. | 05 October 2022, 17:08:22 UTC |
| 930386f | Philippe Canal | 17 November 2020, 22:03:22 UTC | Get hints from the CollectionProxy to create the pair TClass | 05 October 2022, 17:08:22 UTC |
| 0a6f9d0 | Philippe Canal | 06 November 2020, 17:59:06 UTC | TProtoClass deal with STL collection without Proxy. Now that we don't generate unusable collectionProxy (for example in the case one of the value type is 'only' forward declared), we see (in roottest) case where the TProtoClass build the RealData but there is no (good) corresponding data members. | 05 October 2022, 17:08:22 UTC |
| c871ec1 | Philippe Canal | 05 November 2020, 23:42:10 UTC | Do not create emulated TClass for std:pair containing forward declared types | 05 October 2022, 17:08:22 UTC |
| 3cdd3b8 | Philippe Canal | 05 November 2020, 23:41:42 UTC | Allow TClass to be created when known by the interpreter this is used in the case where TStreamerInfo can not handle them. | 05 October 2022, 17:08:22 UTC |
| 5f9bba7 | Philippe Canal | 04 November 2020, 19:46:57 UTC | TStreamerInfo::SetClass also updates the StreamerElement | 05 October 2022, 17:08:22 UTC |
| 3a96f84 | Philippe Canal | 04 November 2020, 19:45:09 UTC | Remove unused code in TClass::ReplaceWith | 05 October 2022, 17:08:22 UTC |
| 2fda823 | Philippe Canal | 04 November 2020, 19:44:35 UTC | More enhancing GenerateInfoForPair to respect the 'silent' flag. | 05 October 2022, 17:08:22 UTC |
| 79de546 | Philippe Canal | 03 November 2020, 23:02:27 UTC | In TGenCollectionProxy::Value::Value more elegantly handle case of forward declared classes. Previously we issue a Fatal message about impossible code path. | 05 October 2022, 17:08:22 UTC |
| 30e0e88 | Philippe Canal | 03 November 2020, 23:01:19 UTC | Fix creation of void's TDataType | 05 October 2022, 17:08:22 UTC |
| 6d84e1f | Philippe Canal | 03 November 2020, 23:00:48 UTC | Enhance GenerateInfoForPair to respect the 'silent' flag. The silent flag to skip over error message about transient data member. Also remove last traces of R__GenerateTClassForPair | 05 October 2022, 17:08:22 UTC |
| 52d0a86 | Philippe Canal | 30 October 2020, 16:37:20 UTC | Skip unnecessary work in TClass::GetClass | 05 October 2022, 17:08:22 UTC |
| 84806c4 | Philippe Canal | 29 October 2020, 22:57:34 UTC | TDataType::GetDataType avoid out-of-bound reads. Search for 'kNumDataTypes'/unknown type should return nullptr not a random. | 05 October 2022, 17:08:22 UTC |
| 6df3597 | Philippe Canal | 29 October 2020, 16:27:57 UTC | In TStreamerInfo::GenerateInfoForPair use a non-zero size enums. This fix #6726 As reported by CMSSW tests (for example: cms-sw/cmsdist#6314 (comment)) where the data appear odd/corrupted, there is an issue in TStreamerInfo::GenerateInfoForPair (which is almost always used for std::pair in the tip of v6.22 and master). The problem is when calculating the offset of the second data member, TStreamerInfo::GenerateInfoForPair uses (unwittingly, of course :) ), the value zero for the size of the enums. | 05 October 2022, 17:08:22 UTC |
| 6962668 | Philippe Canal | 22 October 2020, 21:19:39 UTC | rootpcm: Don't record the sizeof 'emulated' collection. Instead record the size as reported by Cling or -1 if we don't have it | 05 October 2022, 17:08:22 UTC |
| ad5af0b | Philippe Canal | 22 October 2020, 17:32:25 UTC | TProtoClass Extend error message. | 05 October 2022, 17:08:22 UTC |
| ec1cf26 | Philippe Canal | 23 October 2020, 03:51:22 UTC | [NFC] White space | 05 October 2022, 17:08:22 UTC |
| f896d14 | Philippe Canal | 22 October 2020, 17:31:46 UTC | [NFC] typo | 05 October 2022, 17:08:22 UTC |
| 810249d | Philippe Canal | 22 October 2020, 17:30:48 UTC | TClass::FillTClass fSizeof can be set by TGenericClassInfo. When the TClass creation is triggered before the TProtoClass is registered, fSizeof will be set by TGenericClassInfo and that's fine as long as the info is consistent. | 05 October 2022, 17:08:22 UTC |
| 377444a | Philippe Canal | 22 October 2020, 17:26:34 UTC | [NFC] TClass slight code cleanup | 05 October 2022, 17:08:22 UTC |
| 8801226 | Philippe Canal | 22 October 2020, 17:25:53 UTC | TClass::GetListOfBases: actually return fBase after loading via TProtoClass | 05 October 2022, 17:08:22 UTC |
| 16103ba | Philippe Canal | 21 October 2020, 19:47:05 UTC | Rely on TProtoClass::FillTClass now setting fHasRootPcmInfo | 05 October 2022, 17:08:22 UTC |
| 83d7a1c | Philippe Canal | 21 October 2020, 19:36:08 UTC | If a TProtoClass is loaded later, use it immediately Have TProtoClass::FillTClass sets fHasRootPcmInfo. | 05 October 2022, 17:08:22 UTC |
| e72b5c7 | Philippe Canal | 21 October 2020, 16:04:07 UTC | Extent TClass's fProperty and Property()'s documentation. | 05 October 2022, 17:08:22 UTC |
| 50afc4f | Philippe Canal | 20 October 2020, 21:06:51 UTC | Fix issue #6670. Avoid infinite recursion from TClass::InheritsFrom. Do not inadvertently request TClass::fProperty's initialization during TProtoClass::FillTClass, the former ends up calling TProtoClass::FillTClass thus leading to an infinite recursion. | 05 October 2022, 17:08:22 UTC |
| ecb4f64 | Philippe Canal | 19 October 2020, 21:31:39 UTC | TClass::GetListOfDataMembers reload list for struct/class when needed. The problem was due the introduction (in commit f3f0f13) of a fast path in TClass::GetListOfDataMember which did not take in consideration the case: c = GetClass(someclassname) c->GetState() == TClass::kForwardDeclared c->GetListOfDataMember() -> list is now created but empty. load and parse header file for c->GetState() == TClass::kInterpreted c->GetListOfDataMember() -> list is still empty but should have been filled (loaded at this point). The logic assumed incorrectly that if someclassname was indeed pointing to a class or struct and the list was created then it was loaded. To keep the fast path and correct the logic, we need to 'promote' TListOfDataMembers::fIsLoaded to be an std::atomic | 05 October 2022, 17:08:22 UTC |
| a2e9e8e | Philippe Canal | 30 September 2020, 19:41:57 UTC | Avoid auto-parsing upon seeing __pair_base | 05 October 2022, 17:08:22 UTC |
| 01f4aa4 | Philippe Canal | 29 September 2020, 00:49:23 UTC | TCling::CheckClassInfo switch suspensions to use RAII object. | 05 October 2022, 17:08:22 UTC |
| d350566 | Philippe Canal | 28 September 2020, 21:23:49 UTC | [NFC] extend documentation for some of std::pair handling code | 05 October 2022, 17:08:22 UTC |
| d434b0f | Philippe Canal | 28 September 2020, 20:39:46 UTC | Do not generate TClass for pair of unknown type(s). Except in the case where we know the type did exist at some point and thus is an enum (because it was not then we would have information about in the form of TStreamerInfo). The exception to the exception is the case of a custom Streamer that does not use TStreamerInfo underneath. In that case, we don't know about the class then we don't have access to the custom Streamer and thus can't read the object. | 05 October 2022, 17:08:22 UTC |
| 3dfbb76 | Philippe Canal | 26 September 2020, 03:16:13 UTC | Remove restriction (from circa 2005) that is no longer true. i.e. map can be split even if we don't have the interpreter info loaded for the pair and we do not even need a dictionary; we nowadays generate the TClass for most of the std::pairs | 05 October 2022, 17:08:22 UTC |
| 4d7174c | Philippe Canal | 25 September 2020, 20:22:19 UTC | TClass::GetClass uses GenerateInfoForPair rather than auto-parsing | 05 October 2022, 17:08:22 UTC |
| 1d5287b | Philippe Canal | 25 September 2020, 20:07:04 UTC | Migrate R__GenerateTClassForPair to TVirtualStreamerInfo::GenerateInfoForPair | 05 October 2022, 17:08:22 UTC |
| c49e8b1 | Philippe Canal | 26 September 2020, 00:35:51 UTC | In CheckClassInfo suspend autoparsing for std::pair | 05 October 2022, 17:08:22 UTC |
| 631020a | Philippe Canal | 26 September 2020, 00:36:05 UTC | Use TClassEdit::IsStdPair | 05 October 2022, 17:08:22 UTC |
| 567b9ae | Philippe Canal | 26 September 2020, 00:31:57 UTC | Add TClassEdit::IsStdPair to factor out all the comparison | 05 October 2022, 17:08:22 UTC |
| 5ee44a9 | Philippe Canal | 25 September 2020, 16:42:59 UTC | Do not (inadvertently) stip the @@ suffix for emulated class template instances | 05 October 2022, 17:08:22 UTC |
| 2c45c39 | Philippe Canal | 24 September 2020, 22:57:38 UTC | Introduce TClassEdit::IsArtificial to wrap the '@' search. just in case we need to make it more complexe and/or replace it at a later date | 05 October 2022, 17:08:22 UTC |
| c504071 | Philippe Canal | 24 September 2020, 17:13:39 UTC | [NFC] white space | 05 October 2022, 17:08:22 UTC |
| 1d6cc21 | Philippe Canal | 24 September 2020, 17:13:22 UTC | Avoid spurrious auto-loading/parsing due to artificial classes. artificial/synthetic classes are created in the support of I/O customization rules. | 05 October 2022, 17:08:22 UTC |
| 5487e77 | Philippe Canal | 24 September 2020, 15:53:21 UTC | Avoid auto-parsing if we can tell early that the name is an enumerator. In particular use TEnum::GetEnum 'do-not-autoparse-nor-autoload' feature. | 05 October 2022, 17:08:22 UTC |
| 31e5979 | Philippe Canal | 23 September 2020, 19:17:45 UTC | Also avoid auto-parsing for __pair_base during I/O init | 05 October 2022, 17:08:22 UTC |
| ac33252 | Philippe Canal | 23 September 2020, 19:16:51 UTC | fix off by one error in pair auto-parsing skipping | 05 October 2022, 17:08:22 UTC |
| 6c35f47 | Philippe Canal | 19 August 2020, 00:54:28 UTC | tree: Add missing nullptr check in SetLeavesPtr. Fix ROOT-11001. When checking whether a class has a custom streamer, it can happen that there is no TClass for class. This can happen when the file a collection of object that is always empty | 05 October 2022, 17:08:22 UTC |
| 79a8e9f | Philippe Canal | 26 September 2022, 19:02:57 UTC | Force storing of StreamerInfo for nested non-split but memberwise streamed collection. This fix #11436 | 04 October 2022, 17:26:05 UTC |
| b21a5b3 | Philippe Canal | 15 February 2022, 23:31:26 UTC | TBranchElement: no drilling through new members. This resolved the problem seen at: https://github.com/cms-sw/cmssw/issues/36908#issuecomment-1036397481 and fix #9899. The problem is the rules are applied to a data member nested inside an object nested inside an STL collection that is a new data member of the class reco::HaloClusterCandidateHCAL, since it is a new member compared to the layout on file, none of the objects; from the new member down to the object on which the rules need to be run) are actually streamed and the code gathering the information to run the rule got a bit lost ; it is likely (I am checking as we speak) that in previous release the rule was not even attempted to be run ... which might actually be the desired behavior in this specific case. The solution is to have GatherArtificialElements stop drilling through data members which are not stored in the existing TTree. | 18 February 2022, 17:13:11 UTC |
| f632fc7 | Philippe Canal | 25 January 2022, 23:58:47 UTC | TBranchElement::InitInfo improve doc | 18 February 2022, 17:13:11 UTC |
| 94d5443 | Philippe Canal | 12 November 2021, 21:59:39 UTC | TBranchElement: do not set fOnfileObject for collection parent (type 3 or 4). This assignment is both unnecessary and harmfull. It is unnecessary because the pushd and popd of the onfile object address for those cases is already handle by the usage of PushDataCache and PopDataCache action for the branches of type 3 and 4 (via their configuration). It is harmfull because the type of the used/seen in the sub-branches might be completely different from the type of the collection content. For example, this code was crashing some CMS jobs because the sub-branches that had a "OnfileObject" corresponded to a nested sub-object (of type reco::ParticleState) and then this was (unconditionally) associated with the head node of the collection, which contained reco::PFCandidate objects (One of PFCandidate base class contains a reco::ParticleState sub-object). The assignment is triggered when visiting one of the child branch (type 31 or 41) of the collection parent branch. This is a fix for the main branch commit 875e8fb91418f9e520e5d9b22fb1d32f4a42faf0 which is fix for the issue #7754. | 03 February 2022, 01:23:26 UTC |
| d1247ea | Philippe Canal | 18 October 2021, 20:35:32 UTC | [NFC] Typo in comment | 03 February 2022, 01:23:26 UTC |
| b294814 | Philippe Canal | 05 October 2021, 22:12:06 UTC | TClass::GetRealData support more than one level of nesting | 03 February 2022, 01:23:26 UTC |
| d151c55 | Philippe Canal | 05 October 2021, 19:11:57 UTC | TBranchElement::Print add fOnfileObject to 'debugAddress' | 03 February 2022, 01:23:25 UTC |
| 202e774 | Philippe Canal | 29 June 2021, 21:50:58 UTC | Add comment on semantic of fConfiguration->fElemId == -1 | 03 February 2022, 01:22:49 UTC |
| d716865 | Philippe Canal | 29 June 2021, 21:34:29 UTC | TBranchElement::InitializeOffsets: don't confuse top level collection for missing data member | 03 February 2022, 01:22:49 UTC |
| 266f257 | Philippe Canal | 22 October 2021, 22:58:21 UTC | In SetOnfileObject also determine the 'last' branch based on name. The branch ID is not reliable as for the 'later' branch it has not yet been updated from the as-seen-when-writing value to the current value. | 03 February 2022, 01:22:49 UTC |
| 4c8da46 | Philippe Canal | 05 October 2021, 19:11:30 UTC | Further devel for extend io customization support: whole obj rule in split obj. Use the full name to make branch name comparisons | 03 February 2022, 01:22:49 UTC |
| 4c39fe1 | Philippe Canal | 25 June 2021, 18:10:01 UTC | Extend io customization support: whole obj rule in split obj with repetion In the case where the containing object held several sub-object whose type is a class which has a 'whole object' rule, prior to this commit, the infrastructure would re-use only one of the incoming object as input to the rule executions. | 03 February 2022, 01:22:49 UTC |
| 3bd95ed | Philippe Canal | 14 June 2021, 22:46:24 UTC | Extend io customization support: whole obj rule in split obj. Extend the support for a rule that applies to several data members (and thus currently is applied as the 'object level') to the case of a split object embedded within a split subobject of an object (previous it worked only for the collection case). This fixes issue #8428, see also https://cdcvs.fnal.gov/redmine/issues/25893. | 03 February 2022, 01:22:47 UTC |
| e707d41 | Philippe Canal | 29 January 2022, 00:56:28 UTC | Emulated Collection Proxy always need the VectorLooper for the StreamerInfoActions This fixes #9136. Without this commit, SelectLooper would select the 'GenericLooper' in the case of an emulated proxy for STL collection with (in the name) a custom allocator. However the GenericLooper only usable for collection with a compiled collection proxy. In particular, GenericLooper is calling the 'Next' function which is not defined for vector ... and emulated collection. Using it lead to an assert complaining (right fully so) that an 'undefined' function is being called. | 31 January 2022, 16:58:29 UTC |
| 5236a99 | Philippe Canal | 14 January 2022, 16:39:07 UTC | TStreamerInfo::New needs to use the CollectionProxy::New This fixes issue #9543 In the issue #9543, the unusual situation is the combination of: * there is (intentionally) no dictionary for `std::map<int,std::vector<int>>` * consequently we use an "emulated collection proxy" for that collection * there is (unintentional due to external config) interpreter information/ClassInfo for `std::map<int,std::vector<int>>` The crux of the issue #9542 is: * TClass::fSizeof info prefers the information from the CollectionProxy * TStreamerInfo::fSize is set to the value of TClass::fSizeOf * TClass:New prefers the constructor from the interpreter * TStreamerInfo::New was using TClass::New for that case * On the failing platform, the `sizeof(std::map<int,std::vector<int>>)` is larger than the size of the emulated collection. Since the I/O and TStreamerInfo uses the TCollection proxy and all of TStreamerInfo needs to prefer the information from the collection proxy (including the 'sizeof'). To fix #9542 the solution is for * TStremearInfo::New to prefer/use TCollectionProxy::New over TClass::New (i.e. the interpreted constructor in this particular case). | 19 January 2022, 16:01:33 UTC |
| 71bab00 | Jonas Hahnfeld | 13 January 2022, 09:28:00 UTC | RooAddPdf: Avoid UB in checkObservables A RooAddPdf may have more PDFs than coefficients, in which case "the coefficient of the last PDF is calculated automatically from the condition that the sum of all coefficients has to be 1". In this case, the last call to "_coefList.at(i)" is supposed to return a nullptr because the index is out of range, and dereferencing it is undefined behavior which Clang 13 optimizes away, leading to crashes. Fixes #9547 (cherry picked from commit 1f3f0fdc0544087042e6289376094bf06b2d259f) | 14 January 2022, 15:51:37 UTC |
| 89d80e1 | Jonas Rembser | 10 November 2021, 13:13:30 UTC | [RF] Cleanup `RooRealVar::_sharedPropList` in RooRealVar destructor In df1a5a6, a memory leak when reading RooRealVars from ROOT files was fixed by introducing a `RooRealVar::_sharedPropList` map that holds `std::weak_ptr`s to all shared properties objects that were created by any RooRealVar. However, a mechanism to cleanup the weak pointers from the map when they were explired was still missing, which caused the `RooRealVar::_sharedPropList` map to grow forever and by a lot, especially in toy studies where many datasets are created (in the RooFit dataset constructors, RooAbsReals are cloned, which triggers the creation of the shared properties object). In this commit, the `RooRealVar::_sharedPropList` map is cleaned from expiring pointers in the RooRealVar destructor, which should fix a bunch of RooFit problems that seemed like memory leaks. To avoid the static initialization order fiasko, the `_sharedPropList` is now allocated on the heap and only deleted when the process exits using the `RooSentinel` mechanism that is already used for the RooFit memory pools. | 12 November 2021, 23:19:03 UTC |
| 188739c | Emmanouil | 23 October 2020, 07:55:13 UTC | [RF] Fix global static objects initialization problem. | 12 November 2021, 23:19:03 UTC |
| cb756fc | Omar Zapata | 09 August 2021, 14:39:44 UTC | ROOT-R:fixed links to the users guide. | 19 August 2021, 17:30:55 UTC |
| 912c205 | Omar Zapata | 09 August 2021, 14:38:10 UTC | ROOT-R: fixed segfault evaluating R code | 19 August 2021, 17:30:55 UTC |
| 0099f77 | Philippe Canal | 07 July 2021, 20:11:24 UTC | gdml: add support for the official spelling of millimeter | 07 July 2021, 20:11:24 UTC |
| cf67fed | Philippe Canal | 22 June 2021, 21:03:46 UTC | Remove stray debug print out. It was inadvertently introduced in 82fad768c9a In TBranchElement::Print use the correct StreamerInfo in case of schema evolution | 22 June 2021, 21:10:20 UTC |
| b09e4d0 | Jonas Rembser | 21 June 2021, 09:32:11 UTC | [RF] Fix missing initializer warnings in MemPoolForRooSets.h (2nd try) This PR should finally fix the build warnings in the master nightlies, after the unsuccessful fix attempt in commit 4ed5ea3976743d1206a8f8c7579adeb1818a9695. I have checked that the missing field initializer warnings go away with this change by compiling the following example snippet under gcc48: ```C++ // compile with g++ -Wmissing-field-initializers -std=c++11 -o test test.cc struct A{ A() : arr_{{}} {} std::array<int, 10> arr_ = {{}}; }; int main() { A a{}; std::cout << a.arr_[0] << std::endl; return 0; } ``` The warnings are reproduced, and can successfully be suppressed by replacing `{}` with `{{}}`. | 22 June 2021, 08:11:18 UTC |
| 67dc213 | Vincenzo Eduardo Padulano | 06 May 2021, 12:17:21 UTC | [core] Missing include in string_view header | 31 May 2021, 16:53:22 UTC |
| 9cd0cac | Philippe Canal | 05 May 2021, 21:24:37 UTC | Record properly the number of dim of a string array in its StreamerElement | 07 May 2021, 20:26:46 UTC |
| a352ac9 | Philippe Canal | 05 May 2021, 21:23:47 UTC | Fix #8033: string array StreamerElement not recorded properly | 07 May 2021, 20:26:46 UTC |
| 6817011 | Jonas Rembser | 23 April 2021, 16:49:57 UTC | [RF] Use again operator new instead of ObjectAlloc in MemPoolForRooSets This reverts a change from commit 64f299ce3c08501d3ba42e164ad6e40c151bb25b. The change was causing crashes in in python code. | 29 April 2021, 14:27:33 UTC |
| 0e3b40d | Jonas Rembser | 21 April 2021, 15:57:16 UTC | [RF] Reduce memory consumption of MemPoolForRooSets The MemPoolForRooSets has two problems: 1. Scaling issues: increasing memory and CPU consumption with increasing number of arenas, becuase trying to allocate a new non-overlapping arena often fails. 2. Amplification of memory leaks in user code: If one of the elements in the arena leaks, the whole arena will leak. Since each arena has 6000 elements, this means a leak of a RooArgSet will be ampilfied by a factor 6000 in the worst case. This commit proposes a solution to the scaling/performance issues and the leak amplification. Explained for the example for RooArgSet, the idea is to use each arena 120 times because this is the size of RooArgSet in bytes. This can be done while still having unique adresses for each RooArgSet: 1. Keep a gap of 120 bytes between each RooArgSet 2. When an address was used before, add one byte and in can be used again So at the cost of allocating 2x more memory per arena, we can reuse each arena 120 times. Now, the good thing is that the interval of creating/deleting RooArgSets is usually higher than 6000. So when reusing an arena multiple times, they will eventually be filled only by leaking RooArgSets if there is a leak. Meaning the leak amplification effect should be gone. This was checked with the CMS Higgs combine toy fit example from the Higgs combine tutorial. Without this commit, there is a GB-level leak that can be clearly observed with `top`, but with this commit the leak becomes negligible again. (cherry picked from commit 73acf88a799547bfe7eacf37a4537a2968da57af) | 22 April 2021, 18:43:24 UTC |
| 3bae1f6 | Jonas Rembser | 20 April 2021, 10:43:20 UTC | [RF] Deallocate memory owned by empty MemPoolForRooSets Arenas If an arena in the MemPoolForRooSets is not referenced anymore, it should delete the memory it has allocated. (cherry picked from commit a3f4198f546e6e41323a8d0871aad74fcbb9b252) | 22 April 2021, 18:43:24 UTC |
| f0da4b4 | Stephan Hageboeck | 16 April 2021, 12:56:14 UTC | [RF] Fix memory leak in ToyMCSampler. Fix #7890. (cherry picked from commit e485b2898ae65b78cd4208ae2f5337b703228c8a) | 22 April 2021, 18:43:24 UTC |
| 76a5b5d | Axel Naumann | 12 April 2021, 09:13:16 UTC | [test] Update location of xrootd test files: The original directory was removed. (cherry picked from commit ca9ab88c7e38046dae309d039b7912e294a5435d) | 14 April 2021, 17:13:29 UTC |
| c55f27a | Jonas Hahnfeld | 09 April 2021, 08:51:56 UTC | [AArch64] Materialize FP constant in code for large code model (#7807) Backport of D99607, commit 6415f424bc. Original commit message: --- When using the large code model with FastISel (for example via clang -O0 which adds the optnone attribute), FP constants could still be materialized using adrp + ldr. Unconditionally enable the existing path for MachO to materialize the constant in code. [...] --- See the discussion in https://github.com/cms-sw/cmssw/issues/31123 for context on the observed crashes. (cherry picked from commit 9e104ac7900ca264066d57aac1655ac1d8daf5f0) | 09 April 2021, 08:51:56 UTC |
| 4419fb7 | Philippe Canal | 31 March 2021, 00:36:28 UTC | Fix the action PushDataCache for TClonesArray. It was using the wrong signature leading to the configuration to be mis-read. Fixes #7754 | 31 March 2021, 21:29:28 UTC |
| f8c8a43 | Philippe Canal | 24 March 2021, 18:09:47 UTC | [io] Correct cycle order in file merging for non-mergeable obj. Fixes #7676 | 26 March 2021, 17:42:44 UTC |
| 1f740dd | Axel Naumann | 12 November 2020, 11:24:46 UTC | [core] Fix TCling::GetSharedLibs() for macOS11: The massaging of libray names introduced by Fons needs to be applied earlier, right at the library names extracted from macOS dyld,to fix also TCling::GetSharedLibs() not mentioning unlinkable libraries. This in turn fixes TFile::MakeProject(), specifically roottest/root/meta/MakeProject/stltest generating a MAKEP that contains a linker line with unlinkable libs on macOS 11. While at it, update the static function name to signal what it is actually doing these days :-) (cherry picked from commit a7a4a54c01e1528e7a88c33d6d11306c7eda89f2) | 24 March 2021, 13:18:42 UTC |
| 08abf82 | Fons Rademakers | 04 November 2020, 15:37:32 UTC | Libraries found in the dynamic linker cache must be linked with -lXxxx. Linking with the full path of /usr/lib libraries does not trigger a search in the dynamic linker cache, only when libs are linked via -l. Exclude the Big Sur libs liboah and libRosetta as they cannot be linked. No idea why (yet). (cherry picked from commit 3c4a1197a102238336e8daef7948f083b293e696) | 24 March 2021, 13:18:42 UTC |
| aa43ecd | Fons Rademakers | 03 November 2020, 14:50:29 UTC | Check for libraries in the dynamic linker-cache of macOS 11. On macOS 11 most libraries are not anymore on the filesystem. The system ships with a built-in dynamic linker cache of all system-provided libraries. As part of this change, copies of dynamic libraries are no longer present on the filesystem. (cherry picked from commit f39d4b00b12ee09acf644e8c5bcf6b801b3340a5) | 24 March 2021, 13:18:42 UTC |
| 09eb975 | Fons Rademakers | 22 October 2020, 12:29:54 UTC | [etc,config] Update Makefile.arch, root-config.in for macOS 11. (cherry picked from commit 11909ee5a2ab7471dfedf21c1f4d83f56bdceba7) | 24 March 2021, 13:18:42 UTC |
| 160b699 | Axel Naumann | 29 October 2020, 13:08:43 UTC | [build] Fix compiledata.h for macOS11, remove <10.5. (cherry picked from commit 132b72c2000b9f942cc77b5cddec4e9c7161f836) | 24 March 2021, 13:18:42 UTC |
| 899e5aa | Axel Naumann | 22 October 2020, 13:22:57 UTC | [cmake] gsl, tbb: for macOS11, pass isysroot also to ld; silence warning "include <gsl/... - you meant <GSL/...?" by renaming source dir. (cherry picked from commit 06453461ae1b5ed2b452242f658c8498a13a8ee7) | 24 March 2021, 13:18:42 UTC |
