Tue, 10/04/2022 - 16:39
Forums:
In MFC application was used part of Opencascade code responsible for read/write IGES files. With OpenCASCADE6.7.1 everithing works fine.
After migration to OpenCASCADE-7.6.0-vc14-64 it was not compiling errors or warnings. But application crashed randomly on Opencascade codes, even on very first one string:
Unhandled exception at 0x00007FFE16B23BFB (TKG3d.dll) in MyApplication.exe: 0xC0000005: Access violation reading location 0xFFFFFFFFFFFFFFFF.
or:
Unhandled exception at 0x00007FFEE2A2C509 (ntdll.dll) in MyApplication.exe: 0xC0000374: A heap has been corrupted (parameters: 0x00007FFEE2A97780).
Can it be some incompatibility between App and OC libraries? For example App used Multi-Byte Character Set, not Unicode?
Tue, 10/04/2022 - 17:25
Did you compile OCCT and App using the same version of Visual Studio?
Wed, 10/05/2022 - 17:47
Yes, I rebild OCCT with vs2019 and with Multi-Byte Character Set. It crashed on the first OCCT string of code. It looks like some incomptibiluty in memory management. My application is qute simple decktop MFC app.
bool IgesIO::ReadShape (CString FileName )
{
try{
if (m_Reader.ReadFile(FileName.GetBuffer()) != IFSelect_RetDone) // It crashed inside ReadFile method.
Wed, 10/05/2022 - 22:37
OCCT is compiled with _UNICODE defined. Yes, it may be the problem if APP is compiled with _MBCS. MBCS is legacy technique and MS encourages to switch new applications on UNICODE.
Thu, 10/06/2022 - 16:03
To switch App on UNICODE I have to be sure that is _UNICODE / _MBCS conflict. And of cource it is quite a lot of work. Can I rebuild OCCT on MBCS and test it first? What should I do for it? Just change _UNICODE to _MBCS in projects and rebuild or something else?
Thu, 10/06/2022 - 16:35
I don't know the possible impact of changing to MBCS in OCCT. Try to do it, and please share your results.
Fri, 10/07/2022 - 10:40
Rebuild OCCT with MBCS - no errors no warnings, but result is same. Look's like OCCT DLL's somehow destroy stack of my application. I try to call it from different location in the programm, but result is more or less same. Any other ideas?
Fri, 10/07/2022 - 12:03
The only idea is to track CRT memory heap validity in various places, may be including in the cascade source code.
BTW, are you sure that you use the same mode (debug or release) for both app and occt binaries?
Sat, 10/08/2022 - 15:36
Alexander Alexanov wrote:
No, if your application uses legacy multi-byte API, your users will be unable to open files with non-Latin characters and will get similar other issues, but not crashes.
This would have no effect as OCCT source code uses directly wide-character APIs and doesn't rely on legacy portability macros like "_UNICODE".
Sat, 10/08/2022 - 15:42
MFC samples often define memory tracking macros overriding new/delete C++ functions in Debug builds. These tricks are very dangerous and indeed might cause memory issues when mixed up with different CRTs.