View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0023554CommunityOCCT:Application Frameworkpublic2012-11-14 18:172013-10-02 15:52
ReporterPawel Assigned ToPawel  
PriorityhighSeveritycrash 
Status closedResolutionunable to reproduce 
PlatformWindowsOSVC++ 2008 
Product Version6.5.4 
Target Version6.6.0Fixed in Version6.6.0 
Summary0023554: Crash when closing BinXCAF document
DescriptionAfter having compiled the version containing the fix 0023489 (Memory leak in TNaming_NamedShape) my (MFC) application started crashing when closing.

The interesting thing is that the crash occurs (I still mean the application crashes when closing/TDocStd_Document destructor is called) only when using the calls:

TDocStd_Document::NewCommand()
TDocStd_Document::CommitCommand()

!!??

The crash occurs in:

TDF_LabelNode* TDF_LabelNode::RootNode ()
{
#ifdef KEEP_LOCAL_ROOT
  return myData? myData -> myRoot: 0L;
#else
  TDF_LabelNode* lp = this;
  while (lp->myFather != NULL) lp = lp->myFather;
  return lp;
#endif
}

'myData' in the line

       return myData? myData -> myRoot: 0L;

is corrupt. TNaming_NamedShape::Clear() accesses root element that has obviously been deleted. The call is in line:

       Standard_Boolean MapExist = Label().Root().FindAttribute(TNaming_UsedShapes::GetID(),US);

Below the stack trace.

    TKLCAF.dll!TDF_LabelNode::RootNode() Zeile 156 + 0xf Bytes C++
     TKLCAF.dll!TDF_Label::Root() Zeile 167 + 0xa Bytes C++
     TKCAF.dll!TNaming_NamedShape::Clear() Zeile 279 + 0x21 Bytes C++
     TKCAF.dll!TNaming_NamedShape::`scalar deleting destructor'() + 0x40 Bytes C++
     TKernel.dll!MMgt_TShared::Delete() Zeile 27 + 0x20 Bytes C++
     TKernel.dll!Handle_Standard_Transient::EndScope() Zeile 58 C++
     TKLCAF.dll!TDF_DeltaOnAddition::`scalar deleting destructor'() + 0x57 Bytes C++
     TKernel.dll!MMgt_TShared::Delete() Zeile 27 + 0x20 Bytes C++
     TKernel.dll!Handle_Standard_Transient::EndScope() Zeile 58 C++
     TKLCAF.dll!TDF_ListNodeOfAttributeDeltaList::`scalar deleting destructor'() + 0x50 Bytes C++
     TKLCAF.dll!TDF_AttributeDeltaList::Clear() Zeile 86 + 0x20 Bytes C++
     TKLCAF.dll!TDF_Delta::`scalar deleting destructor'() + 0x4d Bytes C++
     TKernel.dll!MMgt_TShared::Delete() Zeile 27 + 0x20 Bytes C++
     TKernel.dll!Handle_Standard_Transient::EndScope() Zeile 58 C++
     TKLCAF.dll!TDF_ListNodeOfDeltaList::`scalar deleting destructor'() + 0x50 Bytes C++
     TKLCAF.dll!TDF_DeltaList::Clear() Zeile 86 + 0x20 Bytes C++
     TKLCAF.dll!TDocStd_Document::~TDocStd_Document() + 0x10e Bytes C++
     TKLCAF.dll!TDocStd_Document::`scalar deleting destructor'() + 0x11 Bytes C++
     TKernel.dll!Standard_Transient::Delete() Zeile 82 + 0x20 Bytes C++
     TKernel.dll!Handle_Standard_Transient::EndScope() Zeile 58 C++
     Helix.exe!Handle_Standard_Transient::~Handle_Standard_Transient() Zeile 93 C++
     Helix.exe!Handle_CDM_Document::~Handle_CDM_Document() + 0x2b Bytes C++
     Helix.exe!Handle_TDocStd_Document::~Handle_TDocStd_Document() + 0x2b Bytes C++
Steps To ReproduceUnfortunately I wasn't able to reproduce the problem using DRAW. Hence only C++:

Handle(XCAFApp_Application) anApp = XCAFApp_Application::GetApplication();
anApp->NewDocument(TCollection_ExtendedString(_T("BinXCAF")), aDoc);
aDoc->SetUndoLimit(10);

aDoc->NewCommand();
TopoDS_Shape s1 = BRepPrimAPI_MakeBox(gp_Pnt(0, 0, 0), gp_Pnt(10, 30, 20));
TDF_Label labelA0 = XCAFDoc_DocumentTool::ShapeTool (aDoc->Main ())->NewShape();
TDataStd_Name::Set(labelA0, "ASSEMBLY");
TDF_Label component01 = XCAFDoc_DocumentTool::ShapeTool (aDoc->Main ())->AddComponent(labelA0, s1);
Standard_Boolean result = aDoc->CommitCommand();


As stated above, it is interesting that when commenting the NewCommand/CommitCommand calls out there is no problem.
TagsNo tags attached.
Test case number

Relationships

related to 0023523 closedgka Open CASCADE In session DRAW it is impossible to close document having name already once closed document. 
related to 0023489 closedRoman Lygin Community Memory leak in TNaming_NamedShape 
related to 0024164 closedbugmaster Open CASCADE Optimization of OCAF document closing 

Activities

abv

2012-11-14 18:34

manager   ~0022247

This problem cannot be reproduced in DRAW in master since DRAW command Close does not destroy the document (it leaves it in the Tcl variable). See 0023523 where this has been fixed and caused the crash to reproduce in DRAW. Unfortunately, this has been recognized after 6.5.4 release (just a few hours!)...

The problem is caused by wrong order of destruction of fields of the class TDocStd_Document: Undo/Redo data are destroyed after all nodes (myData) are already destroyed, and if Undo/Redo contains any attributes that access labels in their destructor, we get access violation.

Please try to clean up Undo/Redo buffer in OCAF document and/or call ForgetAllAttributes(true) on the root label of the document before closing it.

Pawel

2012-11-28 16:23

developer   ~0022412

Hello Andrey,

thanks for the hints!

Yes, cleaning the Undo/Redo buffer before closing the document solved the problem.

gka

2012-12-19 16:31

developer   ~0022771

Fix for related bug 0023523 was integrated in current master.
Could you please to check it's behavior in your environment.

Pawel

2013-01-03 20:01

developer   ~0022897

Hello Galina,

unfortunately, I still have some cases where the application crashes.

Here is the stack:

Handle_Standard_Transient::EndScope
TDF_Label::ForgetAllAttributes
TDF_Label::ForgetAllAttributes
TDF_Label::ForgetAllAttributes
TDF_Label::ForgetAllAttributes
TDocStd_Document::Destroy
Handle_CDM_Document::~Handle_CDM_Document
Handle_TDocStd_Document::~Handle_TDocStd_Document

I hope I can provide a reproducer soon. Until then I would leave this issue open.

Some observations for documentation purposes:
1) The crash does not occur when running under debugger (!)
2) The crash occurs only after changing colors of objects in the XDE structure
3) Calling 'ClearUndos()' does not help any more (!). However, calling 'ClearUndos()' + 'ForgetAllAttributes' avoids the crash.

Pawel

2013-01-04 18:04

developer   ~0022903

Last edited: 2013-01-04 18:53

 Dear bugmaster,

although I can still observe some crashes I cannot isolate the problem. It might originate from our application.

For the moment I suggest to close the issue. If there are any new findings I will reopen it.

Issue History

Date Modified Username Field Change
2012-11-14 18:17 Pawel New Issue
2012-11-14 18:17 Pawel Assigned To => bugmaster
2012-11-14 18:24 abv Relationship added related to 0023523
2012-11-14 18:24 abv Relationship added related to 0023489
2012-11-14 18:25 abv Assigned To bugmaster => gka
2012-11-14 18:25 abv Status new => assigned
2012-11-14 18:34 abv Note Added: 0022247
2012-11-14 18:36 Pawel Steps to Reproduce Updated
2012-11-14 18:40 Pawel Description Updated
2012-11-28 16:23 Pawel Note Added: 0022412
2012-12-19 16:29 gka Assigned To gka => Pawel
2012-12-19 16:31 gka Note Added: 0022771
2012-12-20 10:26 abv Status assigned => feedback
2013-01-03 20:01 Pawel Note Added: 0022897
2013-01-03 20:01 Pawel Status feedback => assigned
2013-01-04 18:04 Pawel Note Added: 0022903
2013-01-04 18:04 Pawel Assigned To Pawel => bugmaster
2013-01-04 18:04 Pawel Status assigned => resolved
2013-01-04 18:49 Pawel Note Edited: 0022903
2013-01-04 18:53 Pawel Note Edited: 0022903
2013-02-26 15:47 abv Status resolved => feedback
2013-03-14 11:22 bugmaster Status feedback => closed
2013-03-14 11:22 bugmaster Resolution open => unable to reproduce
2013-03-14 11:41 bugmaster Status closed => assigned
2013-03-14 11:41 bugmaster Status assigned => resolved
2013-03-14 11:41 bugmaster Status resolved => reviewed
2013-03-14 11:42 bugmaster Status reviewed => verified
2013-03-14 11:42 bugmaster Assigned To bugmaster => Pawel
2013-04-23 13:35 aiv Status verified => closed
2013-04-29 15:23 aiv Fixed in Version => 6.6.0
2013-10-02 15:52 abv Relationship added related to 0024164