MantisBT - Community
View Issue Details
0029355Community[OCCT] OCCT:Foundation Classespublic2017-11-30 07:132018-06-29 21:19
abv 
bugmaster 
normalminor 
closedfixed 
 
[OCCT] 7.3.0[OCCT] 7.3.0 
bugs fclasses bug29355
0029355: OCCT 6.9.1 persistence restored in OCCT 7.2.0 not working
The 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
pload OCAF
fsdread bug29355.fsd a
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
No tags attached.
? bug29355.fsd (34,868) 2017-12-02 20:01
https://tracker.dev.opencascade.org/
? bug29355_truncated.fsd (34,862) 2017-12-02 20:02
https://tracker.dev.opencascade.org/
Issue History
2017-11-30 07:13abvNew Issue
2017-11-30 07:13abvAssigned To => abv
2017-11-30 07:13abvFile Added: model.fsd
2017-11-30 07:13abvAdditional Information Updatedbug_revision_view_page.php?rev_id=18256#r18256
2017-12-02 11:25gitNote Added: 0072665
2017-12-02 19:37gitNote Added: 0072667
2017-12-02 20:01abvFile Deleted: model.fsd
2017-12-02 20:01abvFile Added: bug29355.fsd
2017-12-02 20:02abvFile Added: bug29355_truncated.fsd
2017-12-02 20:02abvSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=18286#r18286
2017-12-02 20:13gitNote Added: 0072668
2017-12-03 09:25abvNote Added: 0072670
2017-12-03 09:25abvAssigned Toabv => snn
2017-12-03 09:25abvStatusnew => resolved
2017-12-03 09:58abvNote Added: 0072671
2017-12-03 10:19abvRelationship addedrelated to 0028564
2017-12-08 10:23snnStatusresolved => reviewed
2017-12-08 13:49bugmasterTest case number => bugs fclasses bug29355
2017-12-08 14:15bugmasterNote Added: 0072858
2017-12-08 14:15bugmasterStatusreviewed => tested
2017-12-08 23:00bugmasterChangeset attached => occt master 472433e2
2017-12-08 23:00bugmasterAssigned Tosnn => bugmaster
2017-12-08 23:00bugmasterStatustested => verified
2017-12-08 23:00bugmasterResolutionopen => fixed
2017-12-11 12:00gitNote Added: 0072897
2018-06-29 21:15aivFixed in Version => 7.3.0
2018-06-29 21:19aivStatusverified => closed

Notes
(0072665)
git   
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   
2017-12-02 19:37   
Branch CR29355 has been updated forcibly by abv.

SHA-1: 2f0d34c00b73a1f5224979ab142d814f45dcbeaf
(0072668)
git   
2017-12-02 20:13   
Branch CR29355 has been updated forcibly by abv.

SHA-1: 727550b7628617df7b33e480633b2ea8b8bfce0d
(0072670)
abv   
2017-12-03 09:25   
Fix pushed to CR29355 and tested (see Jenkins job CR29355-master-abv), please review
(0072671)
abv   
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   
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   
2017-12-11 12:00   
Branch CR29355 has been deleted by kgv.

SHA-1: 727550b7628617df7b33e480633b2ea8b8bfce0d