http://bugs.winehq.org/show_bug.cgi?id=7418
cimmo(a)libero.it changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|Juris Data cannot open |Juris Data cannot open
|database (error code 101) |database (error code 101 or
| |103)
--
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.
http://bugs.winehq.org/show_bug.cgi?id=881
------- Additional Comments From 3.14159(a)gmx.net 2007-20-02 05:45 -------
Created an attachment (id=5034)
--> (http://bugs.winehq.org/attachment.cgi?id=5034&action=view)
xtogglecursor.c
as i stil have this problem in 0.9.31 with baldur's gate i created a small
workaround. this small c app sets the mouse cursor to a invisible one. the
window is selected by clicking into it (like xkill). for baldur's gate i do
$ (sleep 10s && ./xtooglecursor) & wine BGMain.exe
when BGMain runs and 10s are over the next click in the (fullscreen) BG window
removes the cursor. This works at least for me.
(though i named it xTOGGLEcursor, it currently only hides!)
--
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.
http://bugs.winehq.org/show_bug.cgi?id=7448
------- Additional Comments From focht(a)gmx.net 2007-20-02 03:49 -------
Hello again,
from what i've seen on the native windows side, the "offending" module
(iframe.dll) makes much more use of the module lock/reference count.
Many browser interface query/addref/releaseref modify it too.
I placed read/write memory log breakpoints to module lock count variable and
refcount ranges between values of 3..15 during whole lifetime.
One the wine side i moved the SHDOCVW_LockModule/UnlockModule() inlines into *.c
module and put some trace output to track usage.
Only one occurrence where it increments then it gets immediately decremented
(early in process) e.g. factory.c: WBCF_AddRef() and WBCF_Release()
This might explain, why the "idle garbage collection" trashes easy any time
thereafter.
Would it sound wrong if the module lock count (which affects the unload time)
should be taken into account/used on that webbrowser_xxx and xxx_ie_window()
stuff too?
At least as long as any webbrowser objects/internal ie frame window/message pump
stuff live.
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.
http://bugs.winehq.org/show_bug.cgi?id=7471
dmitry(a)codeweavers.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC|dmitry(a)codeweavers.com |
------- Additional Comments From dmitry(a)codeweavers.com 2007-20-02 03:14 -------
Is there a smaller test app/case to reproduce the regression?
--
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.
http://bugs.winehq.org/show_bug.cgi?id=430
dmitry(a)codeweavers.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|CLOSED |REOPENED
Resolution|FIXED |
------- Additional Comments From dmitry(a)codeweavers.com 2007-20-02 03:09 -------
That Vitaliy's patch was not correct, I sent a test case proving that,
and a patch reverting that change:
http://www.winehq.org/pipermail/wine-patches/2007-February/036121.html
--
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.
http://bugs.winehq.org/show_bug.cgi?id=7448
------- Additional Comments From focht(a)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.
http://bugs.winehq.org/show_bug.cgi?id=1798
------- Additional Comments From spencercw(a)googlemail.com 2007-20-02 01:19 -------
Bernhard Rosenkraenzer: Nice, that patch fixes this on Age of Mythology. :) Cheers.
--
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.
http://bugs.winehq.org/show_bug.cgi?id=7471
thestig(a)google.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |dmitry(a)codeweavers.com
URL| |http://www.tropico.de/downlo
| |ads/files/Tropico_Demo.exe
Keywords| |download, regression
------- Additional Comments From thestig(a)google.com 2007-20-02 01:00 -------
Regression testing shows this patch (helped to fix bug 6385) introduced the
problem with the corrupt cursor:
http://www.winehq.org/pipermail/wine-patches/2007-January/035014.html
CCing the author of the patch.
--
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.