[Bug 7448] MSDN academic alliance downloader hangs

[Wine Bugs]

http://bugs.winehq.org/show_bug.cgi?id=7448





------- Additional Comments From focht at gmx.net  2007-20-02 01:47 -------
Created an attachment (id=5033)
 --> (http://bugs.winehq.org/attachment.cgi?id=5033&action=view)
crash log showing problem

Hello,

you are right, the inlines in header file slipped thru and they are used.
So forget the "unimpl refcount part" ;-)

But i think i'm on right track though.
Even if SHDOCVW_LockModule() and SHDOCVW_UnlockModule() are correctly used,
someone releases interfaces and class factory thereby forcing the module
reference count go down.
When it reaches zero shdocvw is unloaded due to peridoc calls to
CoFreeUnusedLibraries() = COMPOBJ_DllList_FreeUnused() (some idle "garbage
collector")

It definitely happens.
The window class is unregistered as well when it happens.
This leads to crash on first message (WM_SETCURSOR, ...) that gets routed to
that window proc (due to dangling window proc pointer).

I verified the class/window proc it's the L"IEFrame" one from shdocvw.
See the following log snippets generated by using:

WINEDEBUG=+seh,+shell,+shdocvw,+loaddll,+process,+tid,+ole,+class

---- from log ---
0009:trace:class:CLASS_RegisterClass atom=0xc03f hinst=0x61730000 style=0x80
clExtr=0x0 winExtr=0x0
0009:trace:class:RegisterClassExW atom=c03f wndproc=0x617348f0 hinst=0x61730000
bg=0x6 style=00000080 clsExt=0 winExt=0 class=0x16d8d0
0009:trace:class:CLASS_GetClassLong 0x10030 -26
0009:trace:class:CLASS_GetClassLong 0x10030 -26
....
0014:trace:shdocvw:DllMain 0x61730000 0x3 (nil)
0014:trace:ole:DllMain 0x60640000 0x3 (nil)
0009:trace:ole:COMPOBJ_DllList_FreeUnused 
0009:fixme:shell:DllCanUnloadNow stub
0009:trace:ole:COMPOBJ_DllList_FreeUnused freeing 0x61730000
0009:trace:shdocvw:DllMain 0x61730000 0x0 (nil)
0009:trace:class:UnregisterClassW L"IEFrame" 0x61730000 c03c
0009:trace:class:CLASS_FreeClass 0x16ee90

....
0009:trace:loaddll:free_modref Unloaded module
L"c:\\windows\\system32\\shdocvw.dll" : builtin

---- from log ---

later in crash call stack

---- from log ---

 2 0x6039577e call_window_proc+0x6e(hwnd=<register EDI not in topmost frame>,
msg=0x20, wp=0x10046, lp=0x2000001, result=0x34e584, arg=0x617348f0)
[/home/focht/wine-0.9.31/dlls/user32/winproc.c:452] in user32 (0x0034e550)
  3 0x6039a873 CallWindowProcW+0x53(func=0x617348f0, hwnd=0x10030, msg=0x20,
wParam=<register ESI not in topmost frame>, lParam=0x2000001)
[/home/focht/wine-0.9.31/dlls/user32/winproc.c:2257] in user32 (0x0034e590)
...
---- from log ---

Notice the hwnd=0x10030 and window proc address = 0x617348f0 before the crash.
They come from shdocvw module.

I patched the shdocvw's DllCanUnloadNow() to prevent the module from being
unloaded just to verify and it definitely works.
No crashes.

As a sidenote: in native windows i placed breakpoints to
CoFreeUnusedLibraries() and on event "module unload".
It gets called but none of the modules are unloaded in fact.
This is different behaviour from wine, maybe some aggressive object lifetime
management somewhere?

Regards

-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.