Mantis Bug Tracker Workflow

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0031681Community[OCCT] OCCT:Foundation Classespublic2020-07-21 18:492020-08-03 09:42
Assigned Toabv 
PlatformMingw-w64, g++ 10.1OSWindowsOS Version10
Product Version[OCCT] 7.5.0* 
Target Version[OCCT] 7.5.0*Fixed in Version 
Summary0031681: Foundation Classes - Shared Libraries Cannot Be Loaded
DescriptionI use Mingw-w64 and g++ 10.1 on Windows.

Commit ef779ae0da0ded44c5045762768fe5f5eaff6b04 makes the Open CASCADE shared libraries unusable on my configuration. When I try to run my application from a console window, I get a Windows system error message dialog and the application won't start. The dialog has the title "Application Error" and the content "The application could not be started correctly (0xc0000142). Click 'OK' to close the application." (Both are translated from German by myself.)

My IDE shows the exit value -1.073.741.502 when trying to run the application.

I have spotted the reason for that: It are the lines
  // To initialize theRegistry map as soon as possible to be destoryed the latest
  Handle(Standard_Type) theType = STANDARD_TYPE(Standard_Transient);

in Standard_Type.cxx (lines 102 and 103).

As soon as I remove both lines and rebuild, I can again run my application and load the shared libraries without any trouble.
TagsNo tags attached.
Test case number
Attached Fileszip file icon (2,771 bytes) 2020-07-23 17:32
cxx file icon Standard_ErrorHandler.cxx (9,514 bytes) 2020-07-24 10:17

- Relationships
child of 0031075verifiedbugmaster Open CASCADE Application Framework - reading STEP file into TDocStd_Document leads to memory leaks 

-  Notes
mpv (developer)
2020-07-23 13:45

  Dear Benjamin,

We should reproduce the problem to find the solution. I'm afraid it depends on your application, order of libraries load and may be some other environment features. So, we need some more:

- Which exact version of Mingw-w64 and g++ do you use and how did you obtain it? I guess, we need to reproduce your environment precisely...

- Could you provide us simple example-application code which also crashes? It may be "hello world" main function, using Open-Cascade libraries, but it must be crashed.

- And, could you send to us a call-stack output of this crash? You may use just "gdb.exe program.exe" and then "run" in gdb console to launch the application and "where" to see the call-stack.

Kind Regards,
BenjaminBihler (developer)
2020-07-23 16:02

Dear Mikhail,

I am working on creating a minimal reproducible example. It is harder than I have expected, because removing some large libraries stemming from my application makes the error disappear. I will continue working on it.

Until I have more results, I would like to share some of my observations:

The call-stack is

Thread 1 received signal SIGSEGV, Segmentation fault.
0x00007ffa173272a6 in ntdll!RtlDllShutdownInProgress () from C:\Windows\SYSTEM32\ntdll.dll
#0  0x00007ffa173272a6 in ntdll!RtlDllShutdownInProgress () from C:\Windows\SYSTEM32\ntdll.dll
0000001  0x00007ffa1733b576 in ntdll!RtlEnterCriticalSection () from C:\Windows\SYSTEM32\ntdll.dll
0000002  0x00007ffa1733b3c0 in ntdll!RtlEnterCriticalSection () from C:\Windows\SYSTEM32\ntdll.dll
#3  0x0000000004f0077c in Standard_Mutex::Lock (this=0x50703c0 <theMutex>) at C:/Libraries/OpenCASCADE/occt/src/Standard/Standard_Mutex.cxx:58

#4  0x0000000004efcc50 in Standard_ErrorHandler::FindHandler (theStatus=Standard_HandlerVoid, theUnlink=false) 
at C:/Libraries/OpenCASCADE/occt/src/Standard/Standard_ErrorHandler.cxx:220
#5  0x0000000004efcde6 in Standard_ErrorHandler::Callback::RegisterCallback (this=0x50736e0 <Standard_Type::Register(char 
const*, char const*, unsigned long long, opencascade::handle<Standard_Type> const&)::theMutex>) 
at C:/Libraries/OpenCASCADE/occt/src/Standard/Standard_ErrorHandler.cxx:288
#6  0x0000000004f5a90a in Standard_Mutex::Sentry::Lock (this=0x64f0b0) at C:/Libraries/OpenCASCADE/occt/src/Standard/Standard_Mutex.hxx:113

0000007  0x0000000004f5a9c4 in Standard_Mutex::Sentry::Sentry (this=0x64f0b0, theMutex=...) at C:/Libraries/OpenCASCADE/occt/src/Standard/Standard_Mutex.hxx:85

0000008  0x0000000004f06f6d in Standard_Type::Register (theSystemName=0x5038800 <typeinfo name for Standard_Transient> 
"18Standard_Transient", theName=0x501f003 <std::ignore+1> "Standard_Transient", 
theSize=16, theParent=...) at C:/Libraries/OpenCASCADE/occt/src/Standard/Standard_Type.cxx:112
0000009  0x0000000004f4fb20 in opencascade::type_instance<Standard_Transient>::get () at C:/Libraries/OpenCASCADE/occt/src/Standard/Standard_Type.hxx:260

#10 0x0000000004f0689b in Standard_Transient::get_type_descriptor () at C:/Libraries/OpenCASCADE/occt/src/Standard/Standard_Transient.cxx:28

0000011 0x0000000004f078b7 in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) 
at C:/Libraries/OpenCASCADE/occt/src/Standard/Standard_Type.cxx:103
#12 0x0000000004f078f0 in _GLOBAL__sub_I_Standard_Type.cxx(void) () at C:/Libraries/OpenCASCADE/occt/src/Standard/Standard_Type.cxx:140

0000013 0x0000000004f3b272 in __do_global_ctors () from C:\Libraries\OpenCASCADE\InstallNewest\win64\gcc\bin\libTKernel.dll

0000014 0x0000000004ec12cf in __DllMainCRTStartup () from C:\Libraries\OpenCASCADE\InstallNewest\win64\gcc\bin\libTKernel.dll

0000015 0x00007ffa17345021 in ntdll!RtlActivateActivationContextUnsafeFast () from C:\Windows\SYSTEM32\ntdll.dll

0000016 0x00007ffa17389385 in ntdll!LdrGetProcedureAddressEx () from C:\Windows\SYSTEM32\ntdll.dll
0000017 0x00007ffa17389178 in ntdll!LdrGetProcedureAddressEx () from C:\Windows\SYSTEM32\ntdll.dll
0000018 0x00007ffa173891a2 in ntdll!LdrGetProcedureAddressEx () from C:\Windows\SYSTEM32\ntdll.dll
0000019 0x00007ffa173891a2 in ntdll!LdrGetProcedureAddressEx () from C:\Windows\SYSTEM32\ntdll.dll
0000020 0x00007ffa173891a2 in ntdll!LdrGetProcedureAddressEx () from C:\Windows\SYSTEM32\ntdll.dll
0000021 0x00007ffa173891a2 in ntdll!LdrGetProcedureAddressEx () from C:\Windows\SYSTEM32\ntdll.dll
0000022 0x00007ffa173891a2 in ntdll!LdrGetProcedureAddressEx () from C:\Windows\SYSTEM32\ntdll.dll
0000023 0x00007ffa173f45e7 in ntdll!LdrInitShimEngineDynamic () from C:\Windows\SYSTEM32\ntdll.dll
0000024 0x00007ffa173e1d75 in ntdll!memset () from C:\Windows\SYSTEM32\ntdll.dll
0000025 0x00007ffa173917d3 in ntdll!LdrInitializeThunk () from C:\Windows\SYSTEM32\ntdll.dll
#26 0x00007ffa1739177e in ntdll!LdrInitializeThunk () from C:\Windows\SYSTEM32\ntdll.dll
#27 0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Could this already reveal an error?

Standard_Mutex::Sentry::Lock calls Standard_ErrorHandler::Callback::RegisterCallback which calls Standard_ErrorHandler::FindHandler and there the static variable "theMutex" is locked although the comment in lines 42-44 of Standard_ErrorHandler.cxx states "Note that we should NOT use Sentry while in this class".

Anyway, I will continue trying to create a minimal example. Only if I succeed I will tell you how I have built g++ (otherwise you probably won't need that information).

Thanks for having a look at it.

BenjaminBihler (developer)
2020-07-23 17:34

I guess that I have a reproducer now. Please check the uploaded file It contains instructions (MinimalReproducibleExample.txt) and three more files needed for the reproduction.
mpv (developer)
2020-07-24 10:17

Hi Benjamin,

Could you try the attached Standard_ErrorHandler.cxx in your application. It seems the problem is in
static Standard_Mutex theMutex;
which was not initialized before
Handle(Standard_Type) theType = STANDARD_TYPE(Standard_Transient);

The difference between our and your compilation is in definition of OCC_CONVERT_SIGNALS. I was able to see it in your call-stack (it goes to Standard_ErrorHandler.cxx:288). If this flag is enabled, exception can be reproduced also in MSVC compilation just on load of TKernel.dll.

If it is ok and fix resolves your crash, I will integrate it into OCCT.

Best Regards,
BenjaminBihler (developer)
2020-07-27 09:58

Yes, your new version of Standard_ErrorHandler.cxx seems to fix the problem. Thank you for having looked at the issue so quickly.

git (administrator)
2020-07-30 19:28

Branch CR31681 has been created by kgv.

SHA-1: 70b0fbceed9db34c4e642ce24cabe847fda6e7bf

Detailed log of new commits:

Author: mpv
Date: Thu Jul 30 19:30:21 2020 +0300

    0031681: Foundation Classes - Shared Libraries Cannot Be Loaded
    Standard_ErrorHandler now accesses global mutex via proxy function
    instead of a global variable to avoid initialization order issues.
kgv (developer)
2020-08-03 09:42

Patch is ready for review in OCCT branch CR31681. [^]

- Issue History
Date Modified Username Field Change
2020-07-21 18:49 BenjaminBihler New Issue
2020-07-21 18:49 BenjaminBihler Assigned To => mpv
2020-07-21 18:49 BenjaminBihler Relationship added child of 0031075
2020-07-23 13:45 mpv Note Added: 0093260
2020-07-23 13:45 mpv Assigned To mpv => BenjaminBihler
2020-07-23 13:45 mpv Status new => feedback
2020-07-23 16:02 BenjaminBihler Note Added: 0093263
2020-07-23 17:32 BenjaminBihler File Added:
2020-07-23 17:34 BenjaminBihler Note Added: 0093267
2020-07-23 17:34 BenjaminBihler Assigned To BenjaminBihler => mpv
2020-07-24 10:17 mpv Note Added: 0093277
2020-07-24 10:17 mpv File Added: Standard_ErrorHandler.cxx
2020-07-27 09:58 BenjaminBihler Note Added: 0093367
2020-07-30 19:26 kgv Category OCCT:Application Framework => OCCT:Foundation Classes
2020-07-30 19:26 kgv Summary Application Framework - Shared Libraries Cannot Be Loaded => Foundation Classes - Shared Libraries Cannot Be Loaded
2020-07-30 19:28 git Note Added: 0093408
2020-08-03 09:42 kgv Note Added: 0093416
2020-08-03 09:42 kgv Assigned To mpv => abv
2020-08-03 09:42 kgv Status feedback => resolved

Copyright © 2000 - 2020 MantisBT Team
Powered by Mantis Bugtracker