Thu, 05/17/2007 - 15:33
Hello all,
i am developing a certain software with OCC 6.2/MSVC 8 (Visual Studio 2005) and i am using OCC capability of importing IGES files. I have stumbled over an IGS file which consistently breaks OCC somewhere inside with heap corruption, that is something like:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
HEAP[IGESReadTest.exe]: Heap block at 04FFC140 modified at 04FFC210 past requested size of c8
Windows has triggered a breakpoint in IGESReadTest.exe.
This may be due to a corruption of the heap, and indicates a bug in IGESReadTest.exe or any of the DLLs it has loaded.
The output window may have more diagnostic information
Before diving into OCC source for hours, i am trying to ask in this forum. Maybe even the OCC developers may have an eye on it.
Due to lack of possibility to attach files in forum, i had to host the file on
http://www.studioface.cz/tempstore/occ/heapcorrupt.igs
There is also the same file which i loaded into Rhinoceros (without problem) and then re-exported as IGES. That file is loaded by OCC without problem.
http://www.studioface.cz/tempstore/occ/corrected.igs
Changing the compilation model (debug/release) or memory model (MD/MT) does not help.
The program itself is nothing fancy, but for completeness of the case, i am posting a minimal Win32 program which exposes the problem. The return statements and overall meaning of the code is not crucial.
Thanks in advance for any feedback,
Pavel Zdenek
int _tmain(int argc, _TCHAR* argv[])
{
IGESControl_Reader Reader;
Standard_Integer status = 0;
try {
status = Reader.ReadFile("heapcorrupt.igs"); //
} catch( Standard_Failure ) {
return IFSelect_RetFail;
}
if (status == IFSelect_RetDone)
{
Reader.TransferRoots();
TopoDS_Shape shape = Reader.OneShape();
}
return status;
}
Thu, 05/17/2007 - 16:05
Hi
This is the error in TEst Harness:
Draw[5]> igesread e:/downloads/OCCForum/heapcorrupt.igs
Unknown entity D0....
Total number of loaded entities 477.
Mode (0 End, 1 Visible Roots, 2 All Roots, 3 Only One Entity, 4 Selection) :3
Only One Entity
spline_continuity (read) : 1 (0 : no modif, 1 : C1, 2 : C2)
To modify : command param read.iges.bspline.continuity
give the number of the Entity : 0
Mode (0 End, 1 Visible Roots, 2 All Roots, 3 Only One Entity, 4 Selection) :0
File IGES to read : e:/downloads/OCCForum/heapcorrupt.igs
-- Names of variables BREP-DRAW prefixed by : heapcorrupt
Transfer entity n0 0 : no result
Bye and good luck!
It is not working.
==================================
Mon, 05/21/2007 - 23:56
I would be completely happy if the call to IGESControl_Reader::ReadFile would behave the same, i.e. return with some nice value, although zero. But it corrupts the heap instead. Do you have any idea what may be the difference between DRAWEXE and the test code?
Sat, 05/19/2007 - 11:51
Hello, I tested your broken file using
IGESControl_Reader activeIgesReader ;
Standard_Integer status = activeIgesReader.ReadFile (fileName.GetBuffer());
if (status != IFSelect_RetDone) return false ;
activeIgesReader.TransferRoots();
viewShape = activeIgesReader.OneShape();
and no problems using open cascade 6.1. filename is a CString. I wonder if your string in quotes is not being passed as a CString.....
Mon, 05/21/2007 - 23:50
I have tried using CString. I had to #include (because there was no reference to MFC so far) and #undef UNICODE to obtain char* as output of CString::GetBuffer(), because that's what ReadFile() is expecting (as typedef Standard_Cstring). Anyway, it still corrupts. I wonder if you have the file really in place where the code is expecting it. Because on nonexistent file, ReadFile() exits correctly but with IFSelect_RetError. Have you actually debugged the code?
Tue, 05/22/2007 - 05:44
Your header record is bigger than expect buffer size.
Change line 11 of interface_paramset.cxx from
thelnres = 100; // *20; // 10 caracteres par Param (\0 inclus) : raisonnable
to
thelnres = 200; // *20; // 10 caracteres par Param (\0 inclus) : raisonnable
and recompile the TKXSBase library. That'll fix it!
Pete
Tue, 05/22/2007 - 13:06
I thought that reply was a bit terse, so here's a bit more explanation. from what I can tell the IGES reader code uses a byffer initially sets a character buffer, arbitraly chosen at 100 characters. As the buffer increases the code doubles the size of the buffer. What it doesn't do is test that this doubling will accomodate the new string value. In your IGES file you have a filename encoded with 152 characters - (you'll see it prefixed with 152H). When the buffer runs its first doubling it increases from 100 to 200 chars, but this is still not suffiecient to contain the filename so I think you're causing a buffer overrun. I arbitrarily increased the initial size to 200 chars which work OK.
A simpler fix, if you have control over its, is to force the filename to less 100 chars when its originally written - then you have a do nothing option.
Oh and by the way, total debugging time was about 15 minutes. And I resproduced the error easily withh a Qt framework, so all the MFC CString stuff was a red-herring.
Pete
Pete
Tue, 05/22/2007 - 13:27
And you'd never guess that English is my first (and only) language - typing too fast.
Pete