[Interest] calling QMessageBox::warning() may break the DLL detaching on VS2010

[Sascha Cunz]

Am Freitag, 16. November 2012, 09:57:26 schrieb Andrew Xu:
> Sorry, the previous mail is not complete. continue...
> 
> 5. As you memtioned, there is a static local object in the foo(), the
> destructor of MyObj should be called when the program exiting.
>    1) If the QMessageBox::warning() were no't called, the desctructor of
> MyObj will be called normally.
>    2) *If the QMessageBox::warning() were called before the program
> exiting, the destructor of MyObj won't be called. It's ridiculous, isn't it?
> *
> 
> By the way, I checked whether the destructor is called or not by set a
> breakpoint.

Was just about to ask that, since printf() might be buffered and a flush be 
required to make it appear somewhere.

Generally spoken, the concept of global or function-local static objects in 
C++ is fundamentally flawed. The order in which things are called is 
undeterministic. It soley depends on the mood of the linker (for globals) and 
the invocation order (for function-local static objects).
That being said, I'd strongly advice anybody not to use non-POD static 
objects.

However, from the code-snippets and your description, this code _should_ 
world. But there might be some other pitfalls. One that comes to mind:

When running a program
  a) from within VS by pressing F5
  b) from within VS by choosing "Run without debugger" (or whatever it is
     named like in 2010)
  c) from a Shell
  d) from a Power-Shell
  e) from the Gui
Windows uses different loading mechanisms. This is due to the invention of so 
called "Application Domains" and - more generally - to the very different 
nature of the loader for .NET based applications.

Does your example show the same behaviour when run from within cmd.exe?

You might want to download a copy of "depends" (http://dependencywalker.com). 
After opening your .exe inside Dependency Walker, you can press F7 and it will 
run your application, hooking deep into some Windows API and reporting about 
what _really_ happens, even every call to DllMain.

You also said, it doesn't happen on every machine you tested. Might be that on 
your failing machines, some driver pulls in managed code (Verify by looking at 
how "Proccess Explorer", downloadable from Microsoft, colors your process).
This one of the many reasons, why DllMain (thus the static-destructors) would 
not be called correctly.

Hope this helps,
Sascha