View Issue Details

Related ChangesetsJump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0029355CommunityOCCT:Foundation Classespublic2017-11-30 07:132018-06-29 21:19
ReporterabvAssigned Tobugmaster  
PrioritynormalSeverityminor 
Status closedResolutionfixed 
Target Version7.3.0Fixed in Version7.3.0 
Summary0029355: OCCT 6.9.1 persistence restored in OCCT 7.2.0 not working
DescriptionThe problem is reported in https://www.opencascade.com/content/occt-691-persistence-restored-occt-720-not-working#comment-20211:

> Handle(StdStorage_Data) data;
> Storage_Error error = StdStorage::Read(fileName, data);

This code crashes with the following error: terminate called after throwing an instance of 'Storage_StreamFormatError'

I have attached the data file (model.brep) which I was trying to read with this code. This file can be read without problems using the old ShapeSchema and OCCT 6.9.1.

Following is the stack trace from gdb:

Thread 1 "emcad" received signal SIGABRT, Aborted.
0x00007fffee9d8428 in raise () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0 0x00007fffee9d8428 in raise () from /lib/x86_64-linux-gnu/libc.so.6
0000001 0x00007fffee9da02a in abort () from /lib/x86_64-linux-gnu/libc.so.6
0000002 0x00007fffef75a84d in __gnu_cxx::__verbose_terminate_handler() ()
   from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3 0x00007fffef7586b6 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4 0x00007fffef7576a9 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5 0x00007fffef758005 in __gxx_personality_v0 ()
   from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#6 0x00007fffeef99f83 in ?? () from /lib/x86_64-linux-gnu/libgcc_s.so.1
0000007 0x00007fffeef9a2eb in _Unwind_RaiseException ()
   from /lib/x86_64-linux-gnu/libgcc_s.so.1
0000008 0x00007fffef75890c in __cxa_throw ()
   from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
0000009 0x00007ffff5c9b629 in FSD_File::EndReadObjectData() ()
   from /home/walter/local/OCC/lib/libTKernel.so.7
#10 0x00007ffff26b8a50 in ShapePersistent_TopoDS::HShape::Read(StdObjMgt_ReadData&) () from /home/walter/local/OCC/lib/libTKStd.so.7
0000011 0x00007ffff23a340f in StdObjMgt_ReadData::ReadPersistentObject(int) ()
   from /home/walter/local/OCC/lib/libTKStdL.so.7
#12 0x00007ffff266f602 in StdStorage::Read(Storage_BaseDriver&, opencascade::handle<StdStorage_Data>&) () from /home/walter/local/OCC/lib/libTKStd.so.7
0000013 0x00007ffff267069f in StdStorage::Read(TCollection_AsciiString const&, opencascade::handle<StdStorage_Data>&) ()
---Type <return> to continue, or q <return> to quit---
   from /home/walter/local/OCC/lib/libTKStd.so.7
0000014 0x000000000058cf57 in openShape (
    fileName=0x1ade6a0 "/tmp/EmCAD-3zL5mp/Work/CMP_IN_1/model.brep", shape=...)
    at /home/walter/MwCAD/EmCAD/EmCAD-tet-OCC7_2_0/src/CAD/InputOutput.cpp:311
Steps To Reproducepload OCAF
fsdread bug29355.fsd a
Additional information
and documentation updates		Submitted by walter steffe on 30 November, 2017 - 01:29

I have done an experiment to get more information on the situation before the crash:

The following line: "std::ios_base::iostate streamState=myStream.rdstate();"

was inserted into the following function which is defined inside of FSD_File.cxx

void FSD_File::EndReadObjectData()
{

  char c;
  std::ios_base::iostate streamState=myStream.rdstate();
  myStream.get(c);
  while (c != ')') {
    if (IsEnd() || (c != ' ') || (c == '\n')) {
      throw Storage_StreamFormatError();
    }
    myStream.get(c);
  }

// cout << "EndReadObjectData" << endl;
}

So I have discovered that when the code enters into that functions the stream status is not valid

(gdb) p streamState
$1 = std::_S_failbit

and therefore c is not read inside of the function.

So the problem occurred in some other place before entering into the function void FSD_File::EndReadObjectData(). But I do not know where.

Walter
TagsNo tags attached.
Test case numberbugs fclasses bug29355

Attached Files

  • bug29355.fsd (34,868 bytes)
  • bug29355_truncated.fsd (34,862 bytes)

Activities

git

2017-12-02 11:25

administrator   ~0072665

Branch CR29355 has been created by abv.

SHA-1: a82756e44c5d4f0bf5c8774eec458645eafcdef0


Detailed log of new commits:

Author: abv
Date: Sat Dec 2 11:24:58 2017 +0300

    0029355: OCCT 6.9.1 persistence restored in OCCT 7.2.0 not working

git

2017-12-02 19:37

administrator   ~0072667

Branch CR29355 has been updated forcibly by abv.

SHA-1: 2f0d34c00b73a1f5224979ab142d814f45dcbeaf

abv

2017-12-02 20:01

manager  

bug29355.fsd (34,868 bytes)

abv

2017-12-02 20:02

manager  

bug29355_truncated.fsd (34,862 bytes)

git

2017-12-02 20:13

administrator   ~0072668

Branch CR29355 has been updated forcibly by abv.

SHA-1: 727550b7628617df7b33e480633b2ea8b8bfce0d

abv

2017-12-03 09:25

manager   ~0072670

Fix pushed to CR29355 and tested (see Jenkins job CR29355-master-abv), please review

abv

2017-12-03 09:58

manager   ~0072671

The problem was in poor design of the code reading objects.

Data of each object in FSD file are enclosed in parentheses. To ensure parity of reading / writing these parentheses, classes StdObjMgt_ReadData::Object and StdObjMgt_WriteData::Object are used: these classes read or write open parenthesis in constructor, and closing - in destructor.

The problem was that instead of creating these objects in the functions reading object data, these functions accepted such objects on input, thus they were created implicitly on the caller side. Looks fine. However, these reader functions are defined as operator >>, and in some places several such functions were called in single statement, like this:

theReadData >> myTShape >> myLocation >> myOrient;

In this case, the behavior depends on compiler: if it creates and destroys temporary object
for each call (as apparently MSVC does), it works OK; if it creates all temporary objects at once and destroy them at the end of the statement (assumed to be the case of GCC), it fails.

bugmaster

2017-12-08 14:15

administrator   ~0072858

Combination -
OCCT branch : CR29355 SHA - 727550b7628617df7b33e480633b2ea8b8bfce0d
Products branch : master SHA - 38989178e2a28aeae4ef5fa8e4f0c3fee7b3879d
was compiled on Linux, MacOS and Windows platforms and tested on optimize mode.

Number of compiler warnings:
No new/fixed warnings

Regressions/Differences/Improvements:
No regressions/differences

CPU differences:
Debian70-64:
OCCT
Total CPU difference: 18349.689999999802 / 18469.379999999688 [-0.65%]
Products
Total CPU difference: 7486.6299999999965 / 7457.620000000003 [+0.39%]
Windows-64-VC10:
OCCT
Total CPU difference: 17901.16155029869 / 17828.96428749855 [+0.40%]
Products
Total CPU difference: 8129.508511899966 / 8009.6685436999705 [+1.50%]


Image differences :
No differences that require special attention

Memory differences :
No differences that require special attention

New test files have been added.
New test case is OK

git

2017-12-11 12:00

administrator   ~0072897

Branch CR29355 has been deleted by kgv.

SHA-1: 727550b7628617df7b33e480633b2ea8b8bfce0d

Related Changesets

occt: master 472433e2

2017-12-02 08:24:58

abv


Committer: bugmaster Details Diff		 0029355: OCCT 6.9.1 persistence restored in OCCT 7.2.0 not working

Auxiliary classes StdObjMgt_ReadData::Object and StdObjMgt_WriteData::Object are renamed to "ObjectSentry" (to better reflect their nature); constructor is made explicit to ensure that such objects are always created intentionally.
These objects are instantiated explicitly in the body of relevant functions, instead of implicit creation as temporary objects when function requires such object as argument.
Variable used to get char from stream is nullified in several places in FSD_File and other classes, to avoid possible usage of uninitialized memory in case if stream is bad.		 Affected Issues
0029355
mod - src/DDF/DDF_IOStream.cxx Diff File
mod - src/FSD/FSD_CmpFile.cxx Diff File
mod - src/FSD/FSD_File.cxx Diff File
mod - src/ShapePersistent/ShapePersistent_HArray1.hxx Diff File
mod - src/StdLPersistent/StdLPersistent_HArray1.cxx Diff File
mod - src/StdLPersistent/StdLPersistent_HArray2.cxx Diff File
mod - src/StdLPersistent/StdLPersistent_HString.cxx Diff File
mod - src/StdObject/StdObject_gp_Axes.hxx Diff File
mod - src/StdObject/StdObject_gp_Trsfs.hxx Diff File
mod - src/StdObject/StdObject_gp_Vectors.hxx Diff File
mod - src/StdObject/StdObject_Location.hxx Diff File
mod - src/StdObject/StdObject_Shape.hxx Diff File
mod - src/StdObjMgt/StdObjMgt_ReadData.cxx Diff File
mod - src/StdObjMgt/StdObjMgt_ReadData.hxx Diff File
mod - src/StdObjMgt/StdObjMgt_WriteData.cxx Diff File
mod - src/StdObjMgt/StdObjMgt_WriteData.hxx Diff File
mod - tests/bugs/fclasses/begin Diff File
add - tests/bugs/fclasses/bug29355 Diff File

Issue History

Date Modified Username Field Change
2017-11-30 07:13 abv New Issue
2017-11-30 07:13 abv Assigned To => abv
2017-11-30 07:13 abv File Added: model.fsd
2017-11-30 07:13 abv Additional Information Updated
2017-12-02 11:25 git Note Added: 0072665
2017-12-02 19:37 git Note Added: 0072667
2017-12-02 20:01 abv File Deleted: model.fsd
2017-12-02 20:01 abv File Added: bug29355.fsd
2017-12-02 20:02 abv File Added: bug29355_truncated.fsd
2017-12-02 20:02 abv Steps to Reproduce Updated
2017-12-02 20:13 git Note Added: 0072668
2017-12-03 09:25 abv Note Added: 0072670
2017-12-03 09:25 abv Assigned To abv => snn
2017-12-03 09:25 abv Status new => resolved
2017-12-03 09:58 abv Note Added: 0072671
2017-12-08 10:23 snn Status resolved => reviewed
2017-12-08 13:49 bugmaster Test case number => bugs fclasses bug29355
2017-12-08 14:15 bugmaster Note Added: 0072858
2017-12-08 14:15 bugmaster Status reviewed => tested
2017-12-08 23:00 bugmaster Changeset attached => occt master 472433e2
2017-12-08 23:00 bugmaster Assigned To snn => bugmaster
2017-12-08 23:00 bugmaster Status tested => verified
2017-12-08 23:00 bugmaster Resolution open => fixed
2017-12-11 12:00 git Note Added: 0072897
2018-06-29 21:15 aiv Fixed in Version => 7.3.0
2018-06-29 21:19 aiv Status verified => closed