View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0030563CommunityOCCT:Codingpublic2019-03-12 21:052020-12-02 17:11
Reportergalbramc Assigned Toabv 
PrioritynormalSeverityminor 
Status closedResolutionfixed 
Product Version7.3.0 
Target Version7.5.0Fixed in Version7.5.0 
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

Relationships

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

Activities

galbramc

2019-03-12 21:08

reporter   ~0082886

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

2019-09-20 09:06

manager   ~0087342

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

2019-10-03 16:25

reporter   ~0087775

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

2020-08-28 14:48

developer   ~0093694

The fix for 0031075 enforces STANDARD_TYPE(Standard_Transient) initialization, which might resolve this particular issue as well - to be checked.

abv

2020-10-12 15:01

manager   ~0095887

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)?

galbramc

2020-10-12 16:23

reporter   ~0095893

Yes I will test it out and get back to you.

galbramc

2020-10-13 17:17

reporter   ~0095939

I can confirm that this issue has been resolved.

abv

2020-10-13 21:13

manager   ~0095944

Great, thank you!

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
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