MantisBT - Community
View Issue Details
0023345Community[OCCT] OCCT:Visualizationpublic2012-07-25 13:402012-11-16 13:18
WindowsVC++ 200832 bit
[OCCT] 6.5.3 
[OCCT] 6.5.4[OCCT] 6.5.4 
Not needed
0023345: Crash when destroying OpenGl_Element
After compiling master/origin with the HEAD revision 0023342 my MFC application started crashing (opening and then closing the document/viewer was enough). The crash in my case occurred only when closing the document (the handle to OpenGl_Context was Null).

I discovered that in the issue 023226 "Extend OpenGl_Context to store map of shared GPU resources" some new functionalities were added. One of them causes the crash.

And so, in OpenGl_Element.hxx a new method - Destroy - was added that makes the following call:

theElement->Release (theContext);

However, it is possible that the provided 'const Handle(OpenGl_Context)&' to the context is a Null one and that causes the crash.

My suggestion is to check the context against 'Null' and if it's not the case to call the 'Release' method.

if(theContext.IsNull() == Standard_False)
  theElement->Release (theContext);

The solves the problem in my case.
Here is the reproducer:

1. Compile the MFC samples provided with OCCT using the 0023342 revision of OCCT (origin/master branch)
2. Run the Triangulation sample.
3. Press the "Mesh" button.
4. Exit the application.

This reproduces the problem on my WinXP machine. The application finishes up in the OpenGl_PrimitiveArray::Release (as described in the below section) and crashes because of the Null context handle.

Interesting is, that if nothing is shown (no meshing done) in the application, no problem occurs.
The root problem is caused by the method OpenGl_PrimitiveArray::Release.

In line 1555, the method theContext->DelayedRelease (myVbos[anIter]); holds an Null context-handle and crashes.
No tags attached.
related to 0023500closed ibs Open CASCADE MFC texture example is crashed when view closed 
Issue History
2012-07-25 13:40PawelNew Issue
2012-07-25 13:40PawelAssigned To => Pawel
2012-07-25 13:52PawelNote Added: 0021147
2012-07-25 13:52PawelAssigned ToPawel => bugmaster
2012-07-25 13:52PawelStatusnew => resolved
2012-07-25 17:20abvAssigned Tobugmaster => kgv
2012-07-25 17:37kgvNote Added: 0021148
2012-07-25 17:37kgvAssigned Tokgv => Pawel
2012-07-25 17:37kgvStatusresolved => feedback
2012-07-25 18:35PawelAdditional Information Updatedbug_revision_view_page.php?rev_id=4084#r4084
2012-07-25 18:47PawelNote Added: 0021150
2012-07-25 18:47PawelStatusfeedback => assigned
2012-07-25 18:47PawelStatusassigned => feedback
2012-07-25 18:49PawelSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=4086#r4086
2012-07-25 18:49PawelNote Deleted: 0021150
2012-07-25 18:50PawelSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=4087#r4087
2012-07-25 18:51PawelNote Added: 0021151
2012-07-25 18:51PawelStatusfeedback => assigned
2012-07-25 18:51PawelAssigned ToPawel => kgv
2012-07-25 18:53PawelSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=4088#r4088
2012-08-01 10:50kgvAssigned Tokgv => san
2012-08-01 11:42PawelNote Added: 0021195
2012-09-13 11:52kgvNote Added: 0021472
2012-09-14 15:38sanAssigned Tosan => kgv
2012-10-08 16:47PawelNote Added: 0021681
2012-10-08 17:41kgvNote Added: 0021682
2012-10-08 17:42kgvNote Edited: 0021682bug_revision_view_page.php?bugnote_id=21682#r4316
2012-10-08 18:37PawelNote Added: 0021688
2012-10-10 17:41abvStatusassigned => resolved
2012-10-10 17:44abvAssigned Tokgv => bugmaster
2012-10-10 17:44abvStatusresolved => reviewed
2012-10-10 17:53abvNote Added: 0021711
2012-10-10 18:08mkvAssigned Tobugmaster => mkv
2012-10-16 10:16mkvNote Added: 0021778
2012-10-16 10:16mkvTest case number => Not needed
2012-10-16 10:16mkvAssigned Tomkv => bugmaster
2012-10-16 10:16mkvStatusreviewed => tested
2012-10-16 15:21kgvChangeset attached => occt master dd8a4ce9
2012-10-16 15:21kgvAssigned Tobugmaster => kgv
2012-10-16 15:21kgvStatustested => verified
2012-10-16 15:21kgvResolutionopen => fixed
2012-11-12 11:53kgvRelationship addedrelated to 0023500
2012-11-12 12:58kgvRelationship addedrelated to 0023226
2012-11-16 13:13bugmasterFixed in Version => 6.5.4
2012-11-16 13:18bugmasterStatusverified => closed

2012-07-25 13:52   
Corresponding git branch pushed. Please review.
2012-07-25 17:37   
This is incorrect by design - OpenGl_Element::Destroy() method needed to NEVER forget to release GPU resources. Thus all elements should be explicitly destroyed before OpenGl_Context.

Please provide full sample for your use case to prepare appropriate patch.
2012-07-25 18:51   
Thanks for reviewing the issue.

I have provided further information how to reproduce the problem in the issue description/information.

Hope this helps.
2012-08-01 11:42   
Just a couple of observations, maybe they help.

I have looked at the branch 23345_2 committed by kgv. In that form the samples still crash but with a couple of tweaks the problem seems to be solved:

- CViewer3dView in MFC samples does not inherit from OCC_3dView so that the cleaning code put in ~OCC_3dView() is not actually called. As first step, I put the cleaning code (ProcessLastView) to ~CViewer3dView()
- This solved the problem but only partially. If I run a sample (let's say Viewer3d) create an object (e.g sphere) and close the view everything is OK. But if I hover over an object in the viewer so that it gets highlighted or select it the application crashes closing the viewer.
- To solve this I noticed I had to nullify the handles to AIS_Shapes stored in CViewer3dDoc

Handle_User_Cylinder myCylinder;
Handle_AIS_Shape mySphere;
Handle_AIS_Shape myBox;
Handle_AIS_Shape myOverlappedCylinder;

- In that case no crash occurs anymore.

Again, as I don't have much experience with OpenGL I can't say if the root cause of the problem is solved by that but it seems to work.

Hope this helps
2012-09-13 11:52   
One more problem detected - this can be not enough to call
> AIS_InteractiveContext::RemoveAll (Standard_False);
to clean up all Interactive Objects.
There are several StdSelect_ViewerSelector3d instances present in AIS_InteractiveContext which holds SelectMgr_DataMapOfIntegerSensitive (StdSelect_ViewerSelector3d::myentities) and doesn't cleared by AIS_InteractiveContext::RemoveAll() call.

As workaround application may call:
> myAISContext->RemoveAll (Standard_False);
> Handle(StdSelect_ViewerSelector3d) aSel = myAISContext->MainSelector();
> if (!aSel.IsNull())
> {
> aSel->Clear();
> }
> aSel = myAISContext->LocalSelector();
> if (!aSel.IsNull())
> {
> aSel->Clear();
> }
But this extra code looks strange so it is probably better to perform it inside OCCT somehow.
2012-10-08 16:47   
I applied the workaround from kgv but still get crashes when working with local context.

The stack looks like this:

04B95320 (TKOpenGl): (filename not available): OpenGl_Context::DelayedRelease
04BAA510 (TKOpenGl): (filename not available): OpenGl_GraphicDriver::TriedronEcho

At the moment I don't have a reproducer (the crash occurs in our software but is 100% reproducible) so this note is for documentation purposes only.
2012-10-08 17:41   
(edited on: 2012-10-08 17:42)

just to clarify - your comment was about CR23345_3 branch?

2012-10-08 18:37   
Hello kgv,

1. No, I actually meant your suggestion (0021472) about StdSelect_ViewerSelector3d:

myAISContext->RemoveAll (Standard_False);
Handle(StdSelect_ViewerSelector3d) aSel = myAISContext->MainSelector();
if (!aSel.IsNull())

2. I haven't noticed the branch CR23345_3 so far. But I have compiled it just right now and it worked!

Thanks for the hint
2012-10-10 17:53   
I propose the current state of CR23345_3 to be tested for integration to 6.5.4 beta, and remaining problems to be treated within a separate issue
2012-10-16 10:16   
Dear BugMaster,
Branch CR23345_3 (and master from occt-products) was compiled on Linux and Windows platforms and tested.

Not detected

Not detected

Testing cases:
Not needed