Archived issue #0025275
Different result of reading operation from *.igs and *.stp file for WINDOWS and LINUX platforms
Description
For example, there is the file UKI60107-6.igs in OCCT Base with following structure.
Useful data are in line-range from 1 to 11092 (see Attachment 1 (PNG) attached picture). Next lines contain not actual data. [In the picture file is showed with unprinted symbols, such as LF (ASCII-code 0x0A), SUB (ASCII-code 0x1A), BEL (ASCII-code 0x07) etc.]
WINDOWS reads only (!) these 1092 lines, after that it breaks to read in reason of meeting end of file.
LINUX continues reading. It results in this error:
"1 F: Syntax error in IGES file at line 11093 in section T."
(see test de iges_3 A3 in DEBUG mode on LINUX platform). On WINDOWS platform these errors are absent.
Useful data are in line-range from 1 to 11092 (see Attachment 1 (PNG) attached picture). Next lines contain not actual data. [In the picture file is showed with unprinted symbols, such as LF (ASCII-code 0x0A), SUB (ASCII-code 0x1A), BEL (ASCII-code 0x07) etc.]
WINDOWS reads only (!) these 1092 lines, after that it breaks to read in reason of meeting end of file.
LINUX continues reading. It results in this error:
"1 F: Syntax error in IGES file at line 11093 in section T."
(see test de iges_3 A3 in DEBUG mode on LINUX platform). On WINDOWS platform these errors are absent.
Steps to reproduce
test de iges_3 A3
New test case is not required.
New test case is not required.
Additional information
Just for the record:
According to information from here (http://ru.science.wikia.com/wiki/ASCII), symbol SUB (ASCII-code 0x1A) is used for substituting lost or entering with mistake symbol. Now it is interpreted by DOS and WINDOWS (LINUX is not in this list) system as END OF FILE. Therefore, LINUX does not break reading.
According to information from here (http://ru.science.wikia.com/wiki/ASCII), symbol SUB (ASCII-code 0x1A) is used for substituting lost or entering with mistake symbol. Now it is interpreted by DOS and WINDOWS (LINUX is not in this list) system as END OF FILE. Therefore, LINUX does not break reading.
Public activity
28 archived notes
Participants are labeled by their role within this record.
Small remark!
This problem is actual for *.igs file. In *.stp-file range of correct data is well-defined thanks to file-structure (for example, useful data are contained between "ISO-10303-21" and "END-ISO-10303-21" tags).
This problem is actual for *.igs file. In *.stp-file range of correct data is well-defined thanks to file-structure (for example, useful data are contained between "ISO-10303-21" and "END-ISO-10303-21" tags).
Branch [archived branch] has been created by Author.
[revision removed]
Detailed log of new commits:
Author: Author
Date: Fri Oct 17 15:45:19 2014 +0400
step
Author: Author
Date: Fri Oct 17 13:32:21 2014 +0400
tests/de/iges_2/H9
Author: Author
Date: Mon Oct 13 17:36:20 2014 +0400
Illegal number processing.
Author: Author
Date: Tue Sep 30 12:51:38 2014 +0400
Catch illegal numbers.
Author: Author
Date: Tue Sep 30 09:44:28 2014 +0400
0025275: Diferent result of reading operation from *.igs and *.stp file for WINDOWS and LINUX platform
Symbol SUB (ASCII-code 0x1A) should be considered as End-Of-File both on WINDOWS and LINUX (and on other) system.
[revision removed]
Detailed log of new commits:
Author: Author
Date: Fri Oct 17 15:45:19 2014 +0400
step
Author: Author
Date: Fri Oct 17 13:32:21 2014 +0400
tests/de/iges_2/H9
Author: Author
Date: Mon Oct 13 17:36:20 2014 +0400
Illegal number processing.
Author: Author
Date: Tue Sep 30 12:51:38 2014 +0400
Catch illegal numbers.
Author: Author
Date: Tue Sep 30 09:44:28 2014 +0400
0025275: Diferent result of reading operation from *.igs and *.stp file for WINDOWS and LINUX platform
Symbol SUB (ASCII-code 0x1A) should be considered as End-Of-File both on WINDOWS and LINUX (and on other) system.
Branch [archived branch] has been updated forcibly by Author.
[revision removed]
[revision removed]
Branch [archived branch] has been updated forcibly by Author.
[revision removed]
[revision removed]
Branch [archived branch] has been updated forcibly by Author.
[revision removed]
[revision removed]
Branch [archived branch] has been updated forcibly by Author.
[revision removed]
[revision removed]
Branch [archived branch] has been updated forcibly by Author.
[revision removed]
[revision removed]
Branch [archived branch] has been updated forcibly by Author.
[revision removed]
[revision removed]
Dear Mikhail!
Please review branch CR25275.
Please review branch CR25275.
Remarks:
Class Precision.
- The macro DEFINE_STANDARD_ALLOC is extra for the class containing only static methods.
- Please remove obsolete code in "#ifdef PRECISION_OBSOLETE"
- Do not use Standard_EXPORT keyword for inline methods.
- The method IsIllegal is too complex to be inline.
- The method IsInfinitesimal will return true for zero argument. It is wrong by definition.
Package Standard
- It is questionable adding new exception of type Standard_FloatingPointOverflow. First, it must inherit Standard_NumericError rather than Standard_Failure. Second, There is already Standard_Overflow exception. Moreover, taking into account the contexts, in which this new exception is raised I would name it Standard_IllegalNumber, again inheriting Standard_NumericError.
IGESData_GlobalSection.cxx
- The lines 157-165 must be placed inside the scope of condition of line 154:
if ( i == 13 || i == 17 || i == 19 || i == 20)
StepData_StepReaderData.cxx
- The lines 543-552 have wrong indentation. Please take into account that where tab characters are used there tab length is assumed to be 8 characters.
General remark. I would like to know where exception about illegal number is caught during step/iges reading. What will be the result of reading such file?
Class Precision.
- The macro DEFINE_STANDARD_ALLOC is extra for the class containing only static methods.
- Please remove obsolete code in "#ifdef PRECISION_OBSOLETE"
- Do not use Standard_EXPORT keyword for inline methods.
- The method IsIllegal is too complex to be inline.
- The method IsInfinitesimal will return true for zero argument. It is wrong by definition.
Package Standard
- It is questionable adding new exception of type Standard_FloatingPointOverflow. First, it must inherit Standard_NumericError rather than Standard_Failure. Second, There is already Standard_Overflow exception. Moreover, taking into account the contexts, in which this new exception is raised I would name it Standard_IllegalNumber, again inheriting Standard_NumericError.
IGESData_GlobalSection.cxx
- The lines 157-165 must be placed inside the scope of condition of line 154:
if ( i == 13 || i == 17 || i == 19 || i == 20)
StepData_StepReaderData.cxx
- The lines 543-552 have wrong indentation. Please take into account that where tab characters are used there tab length is assumed to be 8 characters.
General remark. I would like to know where exception about illegal number is caught during step/iges reading. What will be the result of reading such file?
Nikolai, please describe what has been done in your fix. The issue description refers to problem with symbol SUB which, in my own experience, unavoidably breaks reading of the file on Windows. Have you been able to cope with that? Or you made some changes completely irrelevant to this problem (as I guess from Mikhail remarks)?
Andrey, Nikolay did two fixes in one. He addressed the SUB symbol as well, stopping reading the file in this case.
Dear Andrey!
Bug description was extended:
"Additionally, it is important for IGES and STEP file format to add check, if if wrong data are read from the file. For example, if file contains number ~ 1.0e-314 (less than DBL_MIN) or Nan-numbers (see wrongnum.PNG file attached)."
However, it is not the reason for different result for WINDOWS and LINUX platforms. Therefore, we are discussing with Mikhail: "Should we divide this issue on two separately parts (create new bug about wrong numbers reading or keep full script in this issue)?"
Bug description was extended:
"Additionally, it is important for IGES and STEP file format to add check, if if wrong data are read from the file. For example, if file contains number ~ 1.0e-314 (less than DBL_MIN) or Nan-numbers (see wrongnum.PNG file attached)."
However, it is not the reason for different result for WINDOWS and LINUX platforms. Therefore, we are discussing with Mikhail: "Should we divide this issue on two separately parts (create new bug about wrong numbers reading or keep full script in this issue)?"
Nikolay, one thing is unclear for me. Why you in steps to reproduce added the line:
test de step_1 E6
I looked at that step file, and it does not contain any unprintable symbols. Is this file also read differently on windows and linux?
test de step_1 E6
I looked at that step file, and it does not contain any unprintable symbols. Is this file also read differently on windows and linux?
Test "de iges_3 A3" contains unprintable symbol SUB (ASCII-code 0x1A). For *.stp-file this problem is not actual (see above).
Test "de step_1 E6" uses file, fragment of which is in attached picture "wrongnum.PNG". Therefore, this test must be in Steps To Reproduce.
Test "de step_1 E6" uses file, fragment of which is in attached picture "wrongnum.PNG". Therefore, this test must be in Steps To Reproduce.
What is wrong when reading bad numbers? Do you observe different behavior on windows and linux? Or is there any floating point exception? Why is it necessary to take care of illegal numbers?
In any case, I would like to separate these two problems in different bugs and solved them separately.
In any case, I would like to separate these two problems in different bugs and solved them separately.
"What is wrong when reading bad numbers?"
Sometimes it is not wrong. But it is possible for computations to use these data. For example, when computing value of (X^2)*f(X) (in Newton method), where X is 1.0e+109 => f(X) ~ 1.0e+100. Then (X^2)*f(X) ~ 1.0e+318 > DBL_MAX. Earlier, when OCCT Catch Signals was ON, this fact will result of the exception. Now, this situation is not controlled. There is no point in improving OCCT computational methods for processing these cases, if these wrong numbers are source data.
"Do you observe different behavior on windows and linux?"
See #0025275 "...it is not the reason for different result for WINDOWS and LINUX platforms."
Sometimes it is not wrong. But it is possible for computations to use these data. For example, when computing value of (X^2)*f(X) (in Newton method), where X is 1.0e+109 => f(X) ~ 1.0e+100. Then (X^2)*f(X) ~ 1.0e+318 > DBL_MAX. Earlier, when OCCT Catch Signals was ON, this fact will result of the exception. Now, this situation is not controlled. There is no point in improving OCCT computational methods for processing these cases, if these wrong numbers are source data.
"Do you observe different behavior on windows and linux?"
See #0025275 "...it is not the reason for different result for WINDOWS and LINUX platforms."
Nikolay, concluding the above discussion, I suggest that you create a new bug for treating illegal numbers during files import, and leave in the current fix only the code relevant to the subject of this bug.
OK! Thank you so much.
Branch [archived branch] has been updated forcibly by Author.
[revision removed]
[revision removed]
Dear Mikhail!
Please review CR25275 branch. Principle changes are in lines #87+
Please review CR25275 branch. Principle changes are in lines #87+
Reviewed.
Branch [archived branch] has been updated forcibly by Participant.
[revision removed]
[revision removed]
Branch [archived branch] has been rebased on the current master
Dear Commenter 1,
Branch CR25275 from occt git-repository (and master from products git-repository) was compiled on Linux, MacOS and Windows platforms and tested.
[revision removed]
Number of compiler warnings:
occt component:
Linux: 18 (18 on master)
Windows: 0 (0 on master)
products component :
Linux: 11 (11 on master)
Windows: 1 (1 on master)
Regressions/Differences:
http://occt-tests/CR25275-master-products/Debian60-64/summary.html
http://occt-tests/CR25275-master-products/Windows-32-VC10/summary.html
cr standard(001) E1
Testing on Linux:
Total MEMORY difference: 367181040 / 367862128
Total CPU difference: 48660.6899999999 / 51444.81000000015
Testing on Windows:
Total MEMORY difference: 277906444 / 277277864
Total CPU difference: 46918.0 / 37472.0935757
Branch CR25275 from occt git-repository (and master from products git-repository) was compiled on Linux, MacOS and Windows platforms and tested.
[revision removed]
Number of compiler warnings:
occt component:
Linux: 18 (18 on master)
Windows: 0 (0 on master)
products component :
Linux: 11 (11 on master)
Windows: 1 (1 on master)
Regressions/Differences:
http://occt-tests/CR25275-master-products/Debian60-64/summary.html
http://occt-tests/CR25275-master-products/Windows-32-VC10/summary.html
cr standard(001) E1
Testing on Linux:
Total MEMORY difference: 367181040 / 367862128
Total CPU difference: 48660.6899999999 / 51444.81000000015
Testing on Windows:
Total MEMORY difference: 277906444 / 277277864
Total CPU difference: 46918.0 / 37472.0935757
Dear Alexei!
Please recheck regression tests.
Please recheck regression tests.
Test-case cr standard(001) E1 is unstable on current master.
Branch [archived branch] has been deleted by Participant.
[revision removed]
[revision removed]
Related records