View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0030563||Community||OCCT:Coding||public||2019-03-12 21:05||2020-12-02 17:11|
|Target Version||7.5.0||Fixed in Version||7.5.0|
|Summary||0030563: Coding - Standard_Type vptr error|
|Description||This one has me stumped. Running with OCC 7.3.0 compiled with -fsanitize=undefined I get the following error.|
src/Standard/Standard_Type.cxx:128:3: runtime error: member call on address 0x7fd4153f2b80 which does not point to an object of type 'NCollection_DataMap'
0x7fd4153f2b80: note: object is of type 'NCollection_BaseMap'
00 00 00 00 c0 0c 95 1a d4 7f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
vptr for 'NCollection_BaseMap'
So far it only seems to occur after using the STEP writer. However, I found that simply adding this check avoids the error (not sure if it is completely correct).
if (aRegistry.Extent() > 0)
Standard_ASSERT(aRegistry.UnBind (mySystemName), "Standard_Type::~Standard_Type() cannot find itself in registry",);
|Steps To Reproduce||Compile OCCT 7.3.0 with -fsanitize=undefined and run the test suite.|
|Tags||No tags attached.|
|Test case number|
||Slight correction. It consistently occurs when either reading or writing STEP files. I'm guessing something with the STEP IO is the real problem here.|
In general I agree that the proposed fix is reasonable, even if the problem is rather unexpected.
The registry in Standard_Type.cxx is a part of OCCT own (legacy) RTTI system. It is needed to ensure that only one instance of type descriptor exists for each type (at any particular moment).
Type descriptors (objects of type Standard_Type) are created on demand within template function opencascade::type_instance<T>::get() (see Standard_Type.hxx, line 248), and handle to descriptor is stored in static variable defined within that function. The compiler takes care of instantiation of these functions for particular types, and allocation of variables, and (hopefully) linker merges all instances when composing a dynamic library. However, each library has its own instance of that variable for each type it uses. The registry is thus needed to ensure that each instance is unique.
Method Standard_Type::Register() is the only place where type descriptors are constructed (the constructor is private), and it checks whether the descriptor already exists in the registry before creation of a new one.
The assumption was that registry will always be constructed before any of the descriptors, and thus destructed after. Now I realize that hat assumption may be violated - for instance, some other global variable defined in TKernel may be instantiated before type registry, but later store a handle to some type descriptor, which then will get destructed after the registry. I admit this is just a theory and I cannot recognize what that variable might be.
It could be possible to debug this with a debugger, putting a breakpoint at the Standard_Type::~Standard_Type(), triggered by condition of empty registry, and looking at the stack trace.
Just confirming that I still see this with OCCT 7.4.
opencascade-7.4/src/Standard/Standard_Type.cxx:132:3: runtime error: member call on address 0x00010ac93d88 which does not point to an object of type 'NCollection_DataMap<const char *, Standard_Type *, (anony
0x00010ac93d88: note: object is of type 'NCollection_BaseMap'
00 00 00 00 a0 ab a4 0a 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
vptr for 'NCollection_BaseMap'
||The fix for 0031075 enforces STANDARD_TYPE(Standard_Transient) initialization, which might resolve this particular issue as well - to be checked.|
we believe this issue was likely fixed by patch for 0031075, can you please check that in your environment using OCCT 7.5.0.beta (https://dev.opencascade.org/index.php?q=node/1305)?
||Yes I will test it out and get back to you.|
||I can confirm that this issue has been resolved.|
||Great, thank you!|
|2019-03-12 21:05||galbramc||New Issue|
|2019-03-12 21:05||galbramc||Assigned To||=> kgv|
|2019-03-12 21:08||galbramc||Note Added: 0082886|
|2019-03-25 14:20||kgv||Relationship added||child of 0030557|
|2019-09-20 09:06||abv||Note Added: 0087342|
|2019-09-20 11:38||abv||Target Version||=> 7.4.0|
|2019-09-24 13:53||abv||Target Version||7.4.0 => 7.5.0|
|2019-10-03 16:25||galbramc||Note Added: 0087775|
|2020-08-28 14:46||kgv||Relationship added||related to 0031075|
|2020-08-28 14:48||kgv||Note Added: 0093694|
|2020-09-11 15:34||utverdov||Target Version||7.5.0 => 7.6.0|
|2020-09-11 15:48||kgv||Target Version||7.6.0 => 7.5.0|
|2020-10-12 15:01||abv||Note Added: 0095887|
|2020-10-12 15:01||abv||Assigned To||kgv => galbramc|
|2020-10-12 15:01||abv||Status||new => feedback|
|2020-10-12 16:23||galbramc||Note Added: 0095893|
|2020-10-13 17:17||galbramc||Note Added: 0095939|
|2020-10-13 19:39||galbramc||Assigned To||galbramc => abv|
|2020-10-13 21:13||abv||Note Added: 0095944|
|2020-10-22 09:56||abv||Status||feedback => verified|
|2020-10-22 09:56||abv||Resolution||open => fixed|
|2020-10-22 09:56||abv||Fixed in Version||=> 7.5.0|
|2020-12-02 17:11||emo||Status||verified => closed|