MantisBT
Mantis Bug Tracker Workflow

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0030563Community[OCCT] OCCT:Codingpublic2019-03-12 21:052019-10-03 16:25
Reportergalbramc 
Assigned Tokgv 
PrioritynormalSeverityminor 
StatusnewResolutionopen 
PlatformOSOS Version
Product Version[OCCT] 7.3.0 
Target Version[OCCT] 7.5.0*Fixed 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
child of 0030557newkgv Open CASCADE Coding - eliminate errors reported by -fsanitize 

-  Notes
(0082886)
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.
(0087342)
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.
(0087775)
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'

- 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


Copyright © 2000 - 2019 MantisBT Team
Powered by Mantis Bugtracker