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

Fri Nov 16 03:57:22 CET 2012

Hi Sascha,

I know the orders of those desctructors is undeterministic, but, at least,
they should be called.

Anyway, there is the result of depends:
--------------------------------------------------------------------------------
Starting profile on 2012/11/16 at 10:36:43

Operating System: Microsoft Windows NT/2000/XP/2003/Vista based Ultimate
(64-bit), version 6.01.7601 Service Pack 1
Program Executable: c:\users\xulei\desktop\qttest\debug\QTTEST.EXE
Program Arguments:
Starting Directory: C:\Users\Xulei\Desktop\QtTest\Debug\
Search Path: C:\Program Files\Common Files\Microsoft Shared\Windows
Live;C:\Program Files (x86)\Common Files\Microsoft Shared\Windows
Live;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program
Files (x86)\Windows Live\Shared;C:\Program Files (x86)\ATI
Technologies\ATI.ACE\Core-Static;D:\Program
Files\Perforce\;D:\projects\wxWidgets-2.9.3\lib\vc_dll;D:\Program Files
(x86)\Perforce\;D:\Program Files (x86)\Perforce;C:\Program Files
(x86)\Perforce;C:\Program Files
(x86)\Tencent\QQPCMgr\6.8.2396.401;C:\Program Files
(x86)\Tencent\QQPCMgr\6.8.2396.401;D:\Program Files (x86)\Perforce\Server

Options Selected:
     Simulate ShellExecute by inserting any App Paths directories into the
PATH environment variable.
     Log DllMain calls for process attach and process detach messages.
     Log DllMain calls for all other messages, including thread attach and
thread detach.
     Hook the process to gather more detailed dependency information.
     Log LoadLibrary function calls.
     Log GetProcAddress function calls.
     Log thread information.
     Use simple thread numbers instead of actual thread IDs.
     Log first chance exceptions.
     Log debug output messages.
     Use full paths when logging file names.
     Log a time stamp with each line of log.
     Automatically open and profile child processes.
--------------------------------------------------------------------------------

00:00:00.000: Started "c:\users\xulei\desktop\qttest\debug\QTTEST.EXE"
(process 0x554) at address 0x00280000 by thread 1.  Successfully hooked
module.
00:00:00.000: Loaded "c:\windows\syswow64\NTDLL.DLL" at address 0x77A80000
by thread 1.  Successfully hooked module.
00:00:00.624: Loaded "c:\program files\avast software\avast\SNXHK.DLL" at
address 0x72530000 by thread 1.  Successfully hooked module.
00:00:00.624: Loaded "c:\windows\syswow64\KERNEL32.DLL" at address
0x76750000 by thread 1.  Successfully hooked module.
00:00:00.639: Loaded "c:\windows\syswow64\KERNELBASE.DLL" at address
0x755E0000 by thread 1.  Successfully hooked module.
00:00:00.639: DllMain(0x755E0000, DLL_PROCESS_ATTACH, 0x00000000) in
"c:\windows\syswow64\KERNELBASE.DLL" called by thread 1.
00:00:00.639: DllMain(0x755E0000, DLL_PROCESS_ATTACH, 0x00000000) in
"c:\windows\syswow64\KERNELBASE.DLL" returned 1 (0x1) by thread 1.
00:00:00.639: DllMain(0x76750000, DLL_PROCESS_ATTACH, 0x00000000) in
"c:\windows\syswow64\KERNEL32.DLL" called by thread 1.
00:00:00.639: DllMain(0x76750000, DLL_PROCESS_ATTACH, 0x00000000) in
"c:\windows\syswow64\KERNEL32.DLL" returned 1 (0x1) by thread 1.
00:00:00.639: Injected "c:\users\xulei\desktop\depends22_x86\DEPENDS.DLL"
at address 0x08370000 by thread 1.
00:00:00.639: DllMain(0x72530000, DLL_PROCESS_ATTACH, 0x00000000) in
"c:\program files\avast software\avast\SNXHK.DLL" called by thread 1.
00:00:00.655: DllMain(0x08370000, DLL_PROCESS_ATTACH, 0x00000000) in
"c:\users\xulei\desktop\depends22_x86\DEPENDS.DLL" called by thread 1.
00:00:00.655: DllMain(0x08370000, DLL_PROCESS_ATTACH, 0x00000000) in
"c:\users\xulei\desktop\depends22_x86\DEPENDS.DLL" returned 1 (0x1) by
thread 1.
00:00:00.655: GetProcAddress(0x76750000 [c:\windows\syswow64\KERNEL32.DLL],
"FlsAlloc") called from "c:\program files\avast software\avast\SNXHK.DLL"
at address 0x7254827D and returned 0x76764F13 by thread 1.
00:00:00.655:
00:00:00.655: STATUS_STACK_BUFFER_OVERRUN encountered
00:00:00.655: Entrypoint reached. All implicit modules have been loaded.
00:00:00.655: Exited "c:\users\xulei\desktop\qttest\debug\QTTEST.EXE"
(process 0x554) with code -1073740791 (0xC0000409) by thread 1.

I checked the DLLs loaded with another machines which no issue, and the
difference is the no-issue machine loaded more DLLs (they are several
nvidia driver DLLs).

Thanks,
Andrew

2012/11/16 Sascha Cunz <sascha-ml at babbelbox.org>

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20121116/ff32ebbc/attachment.html>