View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001039 | Community | OCCT:Application Framework | public | 2002-11-22 13:00 | 2011-12-15 17:50 |
| Reporter | Assigned To | ||||
| Priority | normal | Severity | trivial | ||
| Status | closed | Resolution | fixed | ||
| OS | All | ||||
| Summary | 0001039: HUGE bug in AIS_InteractiveContext | ||||
| Description | This bug has been added by Stephane Routelous stephane.routelous@exotk.org at http://www.opencascade.org/forumorg/bug.php?bug_id=97&f=8 : Hi, After 3 days searching in my code why my AIS_InteractiveObjects are not destroyed, I found that the bug is in the OpenCASCADE code ( I hate you guys !!! ). OK : here is what's happens: When an object is selected ( AIS_InteractiveContext::Select() method ), it is stored *somewhere* ( I didn't find where, but I suspect AIS_Selection or SelectMgr_something ). The problem is that the list of the stored object is not cleared when the AIS_InteractiveContext is destroyed. It means, that those objects are only freed when the application exits. See the attached visualC++ project based on the viewer wizard. I defined a class inheriting from AIS_Shape, just to put a message box in the constructor and another one in the destructor. How to reproduce the bug : compile the exe. 1/ without selection : launch it. Import a brep. You will see the dialog box for the creation of the AIS_MyShape. Do nothing and close the document. When the AIS_InteractiveObject is destroyed, the AIS_MyShape also : you can see the destructor dialog box. exit the application 2/ with selection : lauch the exe import a brep Select it by picking with the left mouse button on the 3d object pick somewhere else to unselect it. close the document. The destructor dialog box is not shown exit the application you will see the AIS_MyShape dialog box destructor So, please, solve this HUGE bug as soon as possible. For extra-informations, you can contact me ( stephane.routelous@exotk.org ) Thanks in advance. Stephane ---------- Additional comment by Stephane at http://www.opencascade.org/forumorg/read.php?f=8&i=171&t=171 : Hi, I trace the problem and have found it : the problem is the AIS_Selection. The AIS_Selection is referenced in AIS_Interactivecontext with myCurrentName and mySelectionName. the Handle(AIS_Selection) object is stored in a static object ( static TColStd_SequenceOfTransient Selections; ) in AIS_Selection.cxx. But the created AIS_Selection in a AIS_InteractiveContext is not destroyed. It means that the object is kept in the static sequence, till the programm terminates. As written in AIS_Selection.cxx : "// beurk mais moins qu'avant.... rob". For me, it is very very "beurk". So, you have to destroy the both Handle_AIS_Selection ( for myCurrentName and mySelectionName ) in the destructor of the AIS_InteractiveContext. BTW, why the AIS_Selction objects are stored with TCollection_AsciiString in the context, and not directly with the handles ? As soon as both AIS_Selection are only used in a context ( see the AIS_InteractiveContext::InitAttributes() where : myCurrentName = AIS_Context_NewCurName(); mySelectionName = AIS_Context_NewSelName(); AIS_Selection::CreateSelection(mySelectionName.ToCString()); AIS_Selection::CreateSelection(myCurrentName.ToCString()); ), you candirectly store the Handles and not the names !!! Please, clean-up the code ( removing all the "beurk" things ( not the comments, but the ugly code )), and correct the problem ASAP. Stephane http://www.exotk.org | ||||
| Tags | No tags attached. | ||||
| Test case number | |||||
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2002-11-25 14:29 | bugmaster | Assigned To | bugmaster => sav |
| 2002-11-25 14:29 | bugmaster | Status | new => assigned |
| 2002-11-25 19:23 |
|
Status | assigned => resolved |
| 2002-11-25 19:54 | bugmaster | CC | => apv |
| 2002-11-25 20:52 |
|
CC | => aki |
| 2002-12-03 22:47 |
|
Status | resolved => tested |
| 2002-12-11 15:51 | bugmaster | Status | tested => closed |
| 2002-12-11 15:51 | bugmaster | Resolution | @0@ => fixed |
| 2011-08-02 10:32 | bugmaster | Category | OCCT:OCAF => OCCT:Application Framework |
| 2011-12-15 17:50 | bugmaster | Project | Open CASCADE => Community |