Thanks for reporting this bug!
I created an issue at GitHub about this here :
https://github.com/salvadordf/CEF4Delphi/issues/108
Disclosure Statement: This site contains affiliate links, which means that I may receive a commission if you make a purchase using these links. As an eBay Partner, I earn from qualifying purchases.
Access Violations on App Shutdown
- salvadordf
- Posts: 4057
- Joined: Thu Feb 02, 2017 12:24 pm
- Location: Spain
- Contact:
- salvadordf
- Posts: 4057
- Joined: Thu Feb 02, 2017 12:24 pm
- Location: Spain
- Contact:
Re: Access Violations on App Shutdown
This is an elusive bug that only happens in some occasions.
It's difficult to replicate with the demos and even more difficult to catch in a debugger.
I did a lot of tests with the demos but I didn't test it on new apps without browsers.
Your report makes me think that the bug is present in the classes used by GlobalCEFApp to initialize and finalize CEF, which rules out all other theories about TChromium destruction, etc.
It's difficult to replicate with the demos and even more difficult to catch in a debugger.
I did a lot of tests with the demos but I didn't test it on new apps without browsers.
Your report makes me think that the bug is present in the classes used by GlobalCEFApp to initialize and finalize CEF, which rules out all other theories about TChromium destruction, etc.
Re: Access Violations on App Shutdown
to share the knowledge with the community, because of a similar problem in our application:
we did to things in the .dpr-file:
1) add the line
GlobalCEFApp.MustFreeLibrary := False;
2) instead of GlobalCEFApp.Free we use
FreeAndNil(GlobalCEFApp);
our CEF Version: 3.3325.1758.g9aea513 (April 14, 2018)
we did to things in the .dpr-file:
1) add the line
GlobalCEFApp.MustFreeLibrary := False;
2) instead of GlobalCEFApp.Free we use
FreeAndNil(GlobalCEFApp);
our CEF Version: 3.3325.1758.g9aea513 (April 14, 2018)
- salvadordf
- Posts: 4057
- Joined: Thu Feb 02, 2017 12:24 pm
- Location: Spain
- Contact:
Re: Access Violations on App Shutdown
Hi,
Some users reported shutdown problems that can be avoided if "FreeLibrary" is not called. I added the GlobalCEFApp.MustFreeLibrary property to skip the FreeLibrary call when GlobalCEFApp is destroyed.
Some more suggestions to avoid shutdown problems :
Some users reported shutdown problems that can be avoided if "FreeLibrary" is not called. I added the GlobalCEFApp.MustFreeLibrary property to skip the FreeLibrary call when GlobalCEFApp is destroyed.
Some more suggestions to avoid shutdown problems :
- Follow the "destruction sequence" described in the code comments found in many demos. Delay your app destruction until ALL your browsers received the TChromium.OnBeforeClose event.
- The GlobalCEFApp destruction should be the last code line in the DPR. This is even more important if your app has a complex destruction. In some cases, freeing all our forms before destroying GlobalCEFApp can help too.
Re: Access Violations on App Shutdown
Are there any disadvantages to MustFreeLibrary := False? I have had this problem (~5% of the time) despite following the shutdown sequence patterns. I just realized I should try MustFreeLibrary := False. Since doing this I have not seen any shutdown errors, but I am wondering if there is any reason to ever let MustFreeLibrary := True?
- salvadordf
- Posts: 4057
- Joined: Thu Feb 02, 2017 12:24 pm
- Location: Spain
- Contact:
Re: Access Violations on App Shutdown
Setting GlobalCEFApp.MustFreeLibrary to FALSE forces CEF4Delphi to skip the FreeLibrary call when GlobalCEFApp is destroyed.
I always use LoadLibrary (or LoadLibraryEx) with FreeLibrary to decrement the library's reference count but Windows also unloads the module when the process terminates.
I found several web pages reporting access violations when they try to call FreeLibrary in Delphi applications.
I'm not sure why is this happening but I found this :
https://sourceforge.net/p/fastmm/discus ... /?limit=25
Delphi uses FastMM as the defulat memory manager in Windows applications :
http://docwiki.embarcadero.com/RADStudi ... Management
Perhaps this is a rare FastMM issue. I'll add more checks and probably change the default value of MustFreeLibrary.
I always use LoadLibrary (or LoadLibraryEx) with FreeLibrary to decrement the library's reference count but Windows also unloads the module when the process terminates.
I found several web pages reporting access violations when they try to call FreeLibrary in Delphi applications.
I'm not sure why is this happening but I found this :
https://sourceforge.net/p/fastmm/discus ... /?limit=25
Delphi uses FastMM as the defulat memory manager in Windows applications :
http://docwiki.embarcadero.com/RADStudi ... Management
Perhaps this is a rare FastMM issue. I'll add more checks and probably change the default value of MustFreeLibrary.