MantisBT - Community
View Issue Details
0030563Community[OCCT] OCCT:Codingpublic2019-03-12 21:052020-10-22 09:56
galbramc 
abv 
normalminor 
verifiedfixed 
[OCCT] 7.3.0 
[OCCT] 7.5.0[OCCT] 7.5.0 
0030563: Coding - Standard_Type vptr error
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",);
  }
Compile OCCT 7.3.0 with -fsanitize=undefined and run the test suite.
No tags attached.
related to 0031075verified bugmaster Open CASCADE Application Framework - reading STEP file into TDocStd_Document leads to memory leaks 
child of 0030557new kgv Open CASCADE Coding - eliminate errors reported by -fsanitize 
Issue History
2019-03-12 21:05galbramcNew Issue
2019-03-12 21:05galbramcAssigned To => kgv
2019-03-12 21:08galbramcNote Added: 0082886
2019-03-25 14:20kgvRelationship addedchild of 0030557
2019-09-20 09:06abvNote Added: 0087342
2019-09-20 11:38abvTarget Version => 7.4.0
2019-09-24 13:53abvTarget Version7.4.0 => 7.5.0
2019-10-03 16:25galbramcNote Added: 0087775
2020-08-28 14:46kgvRelationship addedrelated to 0031075
2020-08-28 14:48kgvNote Added: 0093694
2020-09-11 15:34utverdovTarget Version7.5.0 => 7.6.0*
2020-09-11 15:48kgvTarget Version7.6.0* => 7.5.0
2020-10-12 15:01abvNote Added: 0095887
2020-10-12 15:01abvAssigned Tokgv => galbramc
2020-10-12 15:01abvStatusnew => feedback
2020-10-12 16:23galbramcNote Added: 0095893
2020-10-13 17:17galbramcNote Added: 0095939
2020-10-13 19:39galbramcAssigned Togalbramc => abv
2020-10-13 21:13abvNote Added: 0095944
2020-10-22 09:56abvStatusfeedback => verified
2020-10-22 09:56abvResolutionopen => fixed
2020-10-22 09:56abvFixed in Version => 7.5.0

Notes
(0082886)
galbramc   
2019-03-12 21:08   
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.
(0087342)
abv   
2019-09-20 09:06   
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.
(0087775)
galbramc   
2019-10-03 16:25   
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'
(0093694)
kgv   
2020-08-28 14:48   
The fix for 0031075 enforces STANDARD_TYPE(Standard_Transient) initialization, which might resolve this particular issue as well - to be checked.
(0095887)
abv   
2020-10-12 15:01   
Hello @galbramc,
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 [^])?
(0095893)
galbramc   
2020-10-12 16:23   
Yes I will test it out and get back to you.
(0095939)
galbramc   
2020-10-13 17:17   
I can confirm that this issue has been resolved.
(0095944)
abv   
2020-10-13 21:13   
Great, thank you!