View Issue Details

IDProjectCategoryView StatusLast Update
0025493CommunityOCCT:Data Exchangepublic2014-12-08 13:55
Reportergdumonteil Assigned Togka 
PrioritynormalSeveritycrash 
Status closedResolutionunable to reproduce 
PlatformWindowsOSVC++ 2010 
Product Version6.7.0 
Summary0025493: Crash during transfer process to an XCAF document
DescriptionWe are reading a STEP file with STEPCAFControl_Reader::ReadFile() method.
Then, we transfer it with the "Transfer" method.

Like so:
   ...
   anApp = XCAFApp_Application::GetApplication();
   anApp->NewDocument("MDTF-XCAF", aDoc);

   if(!reader.Transfer(aDoc))
   {
      ... error ...
   }

The crash happen during the tansfer process, it seems like the handle of some EdgeElement get destroyed but are still used.
You will find the callstack attached.
When debugging in OCCT, the crash occure when getting the EdgeElement() of an StepShape_OrientedEdge.
(File StepToTopoDS_TranslateEdgeLoop.cxx line 285 : StepEdge = OrEdge1->EdgeElement();)
The entity pointer of the Handle_Standard_Transient seems to be out of scope.

The STEP file is under NDA so we can't provide it.
It was exported by SolidWorks 2014.

ImportExport Sample crash as well.
If I'am not wrong "CAD Exchanger" is based on OCCT, we manage to import the STEP file correctly without any crash.

Let us know if we can provide more information.
TagsNo tags attached.
Test case number

Attached Files

Activities

gdumonteil

2014-11-18 20:07

reporter  

callstack.txt (5,115 bytes)   

abv

2014-11-19 15:32

manager   ~0034512

Please first check how it works with OCCT 6.8.0, the problem might have been fixed since 6.7.0 version

gdumonteil

2014-11-20 11:56

reporter  

callstack_680.txt (5,877 bytes)   

gdumonteil

2014-11-20 11:58

reporter   ~0034536

I checked with OCCT 6.8.0 and the crash seems to happen at the same location. I uploaded the callstack with OCCT 6.8.0.

abv

2014-11-21 13:55

manager   ~0034589

Try to arrange C signal handlers in your application by calling OSD::SetSignal() (needs to be done only once, usually done in main() or its equivalent): this can help OCCT to handle this situation internally

gdumonteil

2014-11-21 16:23

reporter   ~0034595

Ok done. Now I have got a OSD_Exception_ACCESS_VIOLATION exception.
CallStack is the same as before plus exception managment.

gdumonteil

2014-11-21 16:23

reporter  

abv

2014-11-21 16:49

manager   ~0034599

Last edited: 2014-11-21 16:50

Sorry, is exception still reported as unhandled after SetSignal()? What I expected is that this exception will be caught now by STEP translator and it will produce some result.

gdumonteil

2014-11-21 18:47

reporter   ~0034605

Last edited: 2014-11-21 20:44

Well ok, I didn't realize that handling signals will allow STEP translator to react in function. So the result is that now the file load without crash but a shape is missing.
I assume that the shape was not transfered because of the exception, but how do I can retrieve this information to display it for the user?
And now I have install OCCT signals handlers, others handlers on standard C++ exception do not catch anything.

gdumonteil

2014-11-27 13:31

reporter   ~0034736

Last edited: 2014-11-27 13:32

Ok now everything work fine.
I have managed to get the entity that was not transfered but still not can get any name of enetity that correspond to the missing shape.

Here is what I am using to get the failed entity:
Handle_Transfer_TransientProcess transferTProcess = reader.Reader().WS()->MapReader();
Transfer_IteratorOfProcessForTransient transferTProcessIt(Standard_True);
transferTProcessIt = transferTProcess->CompleteResult(Standard_True);

I iterate through the transient and test the binder.

Do you have any idea how I can retreive parent entity of an entity.

abv

2014-11-27 14:08

manager   ~0034744

You can try to load your file in DRAW and check where error is reported:

Draw[]> pload ALL
Draw[]> stepread <path_to_your_file.stp> a *
Draw[]> tpstat ?b

The latter command will give list of problems reported during translation, with IDs of relevant STEP entities.

gdumonteil

2014-12-08 13:10

reporter   ~0035123

Well ok, thanks for the support. You can close this issue.

Issue History

Date Modified Username Field Change
2014-11-18 20:07 gdumonteil New Issue
2014-11-18 20:07 gdumonteil Assigned To => gka
2014-11-18 20:07 gdumonteil File Added: callstack.txt
2014-11-19 15:32 abv Note Added: 0034512
2014-11-19 15:32 abv Assigned To gka => gdumonteil
2014-11-19 15:32 abv Status new => feedback
2014-11-20 11:56 gdumonteil File Added: callstack_680.txt
2014-11-20 11:58 gdumonteil Note Added: 0034536
2014-11-21 13:24 gdumonteil Assigned To gdumonteil =>
2014-11-21 13:24 gdumonteil Assigned To => abv
2014-11-21 13:25 gdumonteil Assigned To abv => gka
2014-11-21 13:55 abv Note Added: 0034589
2014-11-21 16:23 gdumonteil Note Added: 0034595
2014-11-21 16:23 gdumonteil File Added: callstack_680._OSD_SetSignal.txt
2014-11-21 16:49 abv Note Added: 0034599
2014-11-21 16:50 abv Note Edited: 0034599
2014-11-21 18:47 gdumonteil Note Added: 0034605
2014-11-21 20:44 gdumonteil Note Edited: 0034605
2014-11-27 13:31 gdumonteil Note Added: 0034736
2014-11-27 13:32 gdumonteil Note Edited: 0034736
2014-11-27 14:08 abv Note Added: 0034744
2014-12-08 13:10 gdumonteil Note Added: 0035123
2014-12-08 13:55 abv Status feedback => closed
2014-12-08 13:55 abv Resolution open => unable to reproduce