Access Violations on App Shutdown

[salvadordf]

Thanks for reporting this bug!

I created an issue at GitHub about this here :
https://github.com/salvadordf/CEF4Delphi/issues/108

[salvadordf]

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.

[Christoph]

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)

[salvadordf]

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 :

• 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.

[rgdawson]

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]

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.