meta: Allow global disabling of AutoParsing during TClass::GetClass #18402
Conversation
|
@makortel @Dr15Jones Any opinions on the interface to see the auto-parsed classes and to disable auto-parsing in TClass::GetClass. Note: this was extracted/separated from #18373 |
|
I'm concerned that keeping the full list of what was auto parsed to lead to a noticeable memory increase. In my opinion, the additional gDebug enabled printout is probably sufficient to allow CMS to do what we want. |
Test Results 18 files 18 suites 4d 4h 40m 50s ⏱️ Results for commit 214f513. ♻️ This comment has been updated with latest results. |
pcanal
force-pushed
the
master-18363-TClass
branch
2 times, most recently
from
a3a40ee to
143831c
Compare
|
I'm also concerned of the memory use of the added I'm wondering about the difference of From usability standpoint I suspect a global setting would not seem to necessarily help CMS. We'd need the header parsing enabled for the following cases
To be useful within |
|
The memory cost is:
|
The idea of the setting was solely for debugging purposes .... Although .... Reading your list, it actually sounds like disabling the auto-parsing solely during |
It is not clear as |
|
@makortel Should we test CMSSW with |
Just to clarify, do you mean the |
With "which version" do you mean whether In any case I'd be fine with testing |
Choices that we have:
Having the build with the suspending auto-parsing force on was to answer the question on whether it lead to any of:
It suspends/prevent any auto-parsing.
It is used in connection to code related to C++ modules ... I did not yet dig deeper than that :) |
|
Thanks @pcanal for the clarifications. I think a test with CMSSW with this PR and @smuzaffar What do you think? |
If TClass.cxx is build with the cpp macro: ROOT_DISABLE_TCLASS_GET_CLASS_AUTOPARSING defined, it will no longer do any auto-parsing during the execution of `TClass::GetClass`. This will result in not being able to find TClass-es when the name requires not-already loaded interpreted information (eg. a typedef to be resolved). Comments include additional possible interfaces to turn on this feature.
Use `gInterpreter->Print("autoparsed");` to print a list
of the class names that directly lead to auto-parsing.
Use `gCling->GetAutoParseClasses()` to programatically get a set
of the class names that directly lead to auto-parsing.
This allows to disable auto-parsing during `TClass::GetClass` for debugging purposes.
The pair should not need a dictionary (but having it doesn't hurt either) unless one of its component does not have a dictionary. i.e. does |
Yes, the |
|
Alright then the failing step must be the step removing/following typedefs. Without the header file they are no longer available. You may need to also ask for all the dictionary for some/all the related typedefs. |
This failure seems to be caused by I checked "manually" that |
Thanks. I defined the relevant dictionaries (*) with the expanded types, and the job went tiny bit forward, i.e. it now makes the same complaint but for (*) |
When you pass the expanded type, ROOT will record the long name and the normalized name (where typedef are fully resolved). If there is any in-between name used (with some typedef resolved but not others), we would need to register those spelling too if we want to avoid the need for autoparsing. We also support the following syntax: |
Never mind, testing again I see that adding the |
This failure turned out to be a mismatch between the type name being requested and the type that was registered in the |
A priori if using the short name in the |
The "short name" could be useful if the string would be passed by a human, but in the CMSSW framework case the string name originates from |
|
I took a look of another unit test failure reported in cms-sw#222 (comment)
The test fails because |
The point is by using the short name in the exception you get both at the same time and the selection.xml is more readable :) |
That routine should not crash :( ... even when they are missing dictionary! |
Is there a way to get the short name from the long name (or from |
You can get from |
Ok. Although in this case the error message originates from ROOT. |
In this case the Lines 4001 to 4013 in 3cf3b64 on line 4008. From gdb at the point of crash So for some reason the |
Adding the dictionary for |
|
With @pcanal we traced another failure from cms-sw#222 (comment)
to be caused by #19705. As a workaround we could modify the |
6 participants
This PR helped debug the issue related to #18373
This is an improvement in the detection of unwanted auto-parsing.
The roottest companion PR is root-project/roottest#1305
To ease debugging of unwanted auto-parsing triggered by
TClass::GetClass, 2 new features are introduced.TClass::GetClassWe "could" allow further way to customize it:
In addition,
gDebug >=1now print an additional line: