MantisBT
Mantis Bug Tracker Workflow

View Issue Details Jump to Notes ] Related Changesets ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0029355Community[OCCT] OCCT:Foundation Classespublic2017-11-30 07:132018-06-29 21:19
Reporterabv 
Assigned Tobugmaster 
PrioritynormalSeverityminor 
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Version[OCCT] 7.3.0Fixed in Version[OCCT] 7.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? file icon bug29355.fsd (34,868 bytes) 2017-12-02 20:01
? file icon bug29355_truncated.fsd (34,862 bytes) 2017-12-02 20:02

- Relationships

-  Notes
(0072665)
git (administrator)
2017-12-02 11:25

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
(0072667)
git (administrator)
2017-12-02 19:37

Branch CR29355 has been updated forcibly by abv.

SHA-1: 2f0d34c00b73a1f5224979ab142d814f45dcbeaf
(0072668)
git (administrator)
2017-12-02 20:13

Branch CR29355 has been updated forcibly by abv.

SHA-1: 727550b7628617df7b33e480633b2ea8b8bfce0d
(0072670)
abv (manager)
2017-12-03 09:25

Fix pushed to CR29355 and tested (see Jenkins job CR29355-master-abv), please review
(0072671)
abv (manager)
2017-12-03 09:58

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.
(0072858)
bugmaster (administrator)
2017-12-08 14:15

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
(0072897)
git (administrator)
2017-12-11 12:00

Branch CR29355 has been deleted by kgv.

SHA-1: 727550b7628617df7b33e480633b2ea8b8bfce0d

- Related Changesets
occt: master 472433e2
Timestamp: 2017-12-02 08:24:58
Author: 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.
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 View Revisions
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 View Revisions
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-03 10:19 abv Relationship added related to 0028564
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 user533 Fixed in Version => 7.3.0
2018-06-29 21:19 user533 Status verified => closed


Copyright © 2000 - 2018 MantisBT Team
Powered by Mantis Bugtracker