Archived issue #0027432
Null Handle Access When Creating AIS_Trihedron
Description
When I create an AIS_Trihedron with the following code
Handle(Geom_Axis2Placement) placement = new Geom_Axis2Placement(
robotPathPoint->getAxisSystem());
interactiveObject = new AIS_Trihedron(placement);
my application crashes, but only when OCCT is compiled in release mode. If OCCT is compiled in debug mode, no crash happens.
By entering debug text output into the related OCCT files, I have been able to find out that lstlexicon is a null-handle in line 74 of Units_Sentence.cxx and that is the reason for the crash.
The line reads:
for(index=1; index<=lstlexicon->Length(); index++) {
Actually line 63 reads:
Units_NoSuchType_Raise_if(lstlexicon.IsNull(),"BAD LEXICON descriptor");
and throwing an exception here would prevent working with a null lstlexicon, but in release builds the macro "No_Exception" seems to be defined here, which prevents the exception. But then I get a crash.
Handle(Geom_Axis2Placement) placement = new Geom_Axis2Placement(
robotPathPoint->getAxisSystem());
interactiveObject = new AIS_Trihedron(placement);
my application crashes, but only when OCCT is compiled in release mode. If OCCT is compiled in debug mode, no crash happens.
By entering debug text output into the related OCCT files, I have been able to find out that lstlexicon is a null-handle in line 74 of Units_Sentence.cxx and that is the reason for the crash.
The line reads:
for(index=1; index<=lstlexicon->Length(); index++) {
Actually line 63 reads:
Units_NoSuchType_Raise_if(lstlexicon.IsNull(),"BAD LEXICON descriptor");
and throwing an exception here would prevent working with a null lstlexicon, but in release builds the macro "No_Exception" seems to be defined here, which prevents the exception. But then I get a crash.
Steps to reproduce
In a new DRAW session:
set env(CSF_UnitsDefinition) /dev/null
set env(CSF_UnitsLexicon) /dev/null
pload VISUALIZATION
vinit
vtrihedron t
Note that exception does not reproduce in DRAW in Release mode, but can be caught in debugger in Debug mode
set env(CSF_UnitsDefinition) /dev/null
set env(CSF_UnitsLexicon) /dev/null
pload VISUALIZATION
vinit
vtrihedron t
Note that exception does not reproduce in DRAW in Release mode, but can be caught in debugger in Debug mode
Public activity
16 archived notes
Participants are labeled by their role within this record.
I have forgotten to add: my AIS_Trihedron creation code has worked correctly with OCCT 6.8.0.
I am prepared to give more details, but I guess that I cannot fix the issue, because I am not familiar with why there is a No_Exception macro and how to deal with exceptions, when they may not be thrown.
I am prepared to give more details, but I guess that I cannot fix the issue, because I am not familiar with why there is a No_Exception macro and how to deal with exceptions, when they may not be thrown.
Could you please comment why do you report it as a bug?
As far as I understand the context, application does not define required OCCT resources to use this functionality:
http://dev.opencascade.org/doc/overview/html/index.html#OCCT_OVW_SECTION_4_2
As far as I understand the context, application does not define required OCCT resources to use this functionality:
http://dev.opencascade.org/doc/overview/html/index.html#OCCT_OVW_SECTION_4_2
Branch [archived branch] has been created by Participant.
[revision removed]
Detailed log of new commits:
Author: abv
Date: Tue Apr 26 21:24:27 2016 +0300
0027432: Null Handle Access When Creating AIS_Trihedron
Debug-only "RaiseIf" is replaced by simple "if" to have exceptional situation handled correctly in Release mode.
[revision removed]
Detailed log of new commits:
Author: abv
Date: Tue Apr 26 21:24:27 2016 +0300
0027432: Null Handle Access When Creating AIS_Trihedron
Debug-only "RaiseIf" is replaced by simple "if" to have exceptional situation handled correctly in Release mode.
Benjamin, I have pushed correction to branch CR27432, could you please check whether it helps you?
Sorry for answering so late, I have been out-of-office yesterday.
Kirill, thank you for the hint. You are right - setting CSF_UnitsDefinition and CSF_UnitsLexicon environment variables makes the problem go away.
Andrey, thank you for the fix, it works. In my opinion this is a great improvement, since application crashes due to forgotten environment variables cannot be considered as good design. In fact, your change makes setting the environment variables mentioned above even unnecessary for creating an AIS_Trihedron.
I am glad to see that there is already work going on on the related issue #0027258. Actually the environment variables (shaders and units) have been a major part of my porting work from 6.8.0 to 7.0.0. If I have not missed anything, the environment variables have not been mentioned in the upgrade guides.
Kirill, thank you for the hint. You are right - setting CSF_UnitsDefinition and CSF_UnitsLexicon environment variables makes the problem go away.
Andrey, thank you for the fix, it works. In my opinion this is a great improvement, since application crashes due to forgotten environment variables cannot be considered as good design. In fact, your change makes setting the environment variables mentioned above even unnecessary for creating an AIS_Trihedron.
I am glad to see that there is already work going on on the related issue #0027258. Actually the environment variables (shaders and units) have been a major part of my porting work from 6.8.0 to 7.0.0. If I have not missed anything, the environment variables have not been mentioned in the upgrade guides.
Branch [archived branch] has been updated by Commenter 3.
[revision removed]
Detailed log of new commits:
Author: Commenter 3
Date: Thu May 5 15:47:52 2016 +0300
Mention mandatory variable CSF_ShadersDirectory in porting notes for OCCT 6.9.0
[revision removed]
Detailed log of new commits:
Author: Commenter 3
Date: Thu May 5 15:47:52 2016 +0300
Mention mandatory variable CSF_ShadersDirectory in porting notes for OCCT 6.9.0
Reviewed, please test
Branch [archived branch] has been updated forcibly by Participant.
[revision removed]
[revision removed]
Dear Commenter 1,
Branch CR27432 was rebased on current master of occt git-repository.
[revision removed]
Branch CR27432 was rebased on current master of occt git-repository.
[revision removed]
Dear Commenter 1,
Branch CR27432 from occt git-repository (and master from products git-repository) was compiled on Linux, MacOS and Windows platforms and tested on Release mode.
[revision removed]
Number of compiler warnings:
occt component :
Linux: 0 (0 on master)
Windows: 0 (0 on master)
MacOS : 0 (0 on master)
products component :
Linux: 72 (72 on master)
Windows: 4 (4 on master)
MacOS : 1119
Regressions/Differences/Improvements:
No regressions/differences
Testing cases:
http://occt-tests/CR27432-master-OCCT/Debian70-64/bugs/fclasses/bug27432.html
http://occt-tests/CR27432-master-OCCT/Windows-64-VC10/bugs/fclasses/bug27432.html
bugs fclasses bug27432: OK
Testing on Linux:
occt component :
Total MEMORY difference: 87700114 / 87499965 [+0.23%]
Total CPU difference: 19337.210000000123 / 19370.860000000182 [-0.17%]
products component :
Total MEMORY difference: 27857964 / 27839978 [+0.06%]
Total CPU difference: 5352.689999999983 / 5344.489999999986 [+0.15%]
Testing on Windows:
occt component :
Total MEMORY difference: 55528604 / 55549122 [-0.04%]
Total CPU difference: 17921.84728289889 / 18280.618382698816 [-1.96%]
products component :
Total MEMORY difference: 18922444 / 18891436 [+0.16%]
Total CPU difference: 5041.234715399943 / 5013.591338199941 [+0.55%]
There are no differences in images found by testdiff.
Branch CR27432 from occt git-repository (and master from products git-repository) was compiled on Linux, MacOS and Windows platforms and tested on Release mode.
[revision removed]
Number of compiler warnings:
occt component :
Linux: 0 (0 on master)
Windows: 0 (0 on master)
MacOS : 0 (0 on master)
products component :
Linux: 72 (72 on master)
Windows: 4 (4 on master)
MacOS : 1119
Regressions/Differences/Improvements:
No regressions/differences
Testing cases:
http://occt-tests/CR27432-master-OCCT/Debian70-64/bugs/fclasses/bug27432.html
http://occt-tests/CR27432-master-OCCT/Windows-64-VC10/bugs/fclasses/bug27432.html
bugs fclasses bug27432: OK
Testing on Linux:
occt component :
Total MEMORY difference: 87700114 / 87499965 [+0.23%]
Total CPU difference: 19337.210000000123 / 19370.860000000182 [-0.17%]
products component :
Total MEMORY difference: 27857964 / 27839978 [+0.06%]
Total CPU difference: 5352.689999999983 / 5344.489999999986 [+0.15%]
Testing on Windows:
occt component :
Total MEMORY difference: 55528604 / 55549122 [-0.04%]
Total CPU difference: 17921.84728289889 / 18280.618382698816 [-1.96%]
products component :
Total MEMORY difference: 18922444 / 18891436 [+0.16%]
Total CPU difference: 5041.234715399943 / 5013.591338199941 [+0.55%]
There are no differences in images found by testdiff.
Branch [archived branch] has been updated by Participant.
[revision removed]
Detailed log of new commits:
Author: mkv
Date: Wed May 11 15:24:17 2016 +0300
Test cases for issue CR27432
[revision removed]
Detailed log of new commits:
Author: mkv
Date: Wed May 11 15:24:17 2016 +0300
Test cases for issue CR27432
Dear kgv,
could you please review following test case
bugs fclasses bug27432
could you please review following test case
bugs fclasses bug27432
As agreed, please remove test as it is not able to show problem in standard test environment
Branch [archived branch] has been updated by Participant.
[revision removed]
Detailed log of new commits:
Author: mkv
Date: Wed May 11 16:14:41 2016 +0300
Deleting test cases for issue CR27432
[revision removed]
Detailed log of new commits:
Author: mkv
Date: Wed May 11 16:14:41 2016 +0300
Deleting test cases for issue CR27432
Dear Commenter 1,
Branch CR27432 is TESTED.
Branch CR27432 is TESTED.
Branch [archived branch] has been deleted by Participant.
[revision removed]
[revision removed]
Related records