Mantis Bug Tracker Workflow

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0030563Community[OCCT] OCCT:Codingpublic2019-03-12 21:052020-09-11 15:48
Assigned Tokgv 
PlatformOSOS Version
Product Version[OCCT] 7.3.0 
Target Version[OCCT] 7.5.0Fixed in Version 
Summary0030563: Coding - Standard_Type vptr error
DescriptionThis 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 ReproduceCompile OCCT 7.3.0 with -fsanitize=undefined and run the test suite.
TagsNo tags attached.
Test case number
Attached Files

- Relationships
related to 0031075verifiedbugmaster Open CASCADE Application Framework - reading STEP file into TDocStd_Document leads to memory leaks 
child of 0030557newkgv Open CASCADE Coding - eliminate errors reported by -fsanitize 

-  Notes
galbramc (reporter)
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.
abv (manager)
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.
galbramc (reporter)
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'
kgv (developer)
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.

- Issue History
Date Modified Username Field Change
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

Copyright © 2000 - 2020 MantisBT Team
Powered by Mantis Bugtracker