http://bugs.winehq.org/show_bug.cgi?id=11259
Summary: Passwordmanager crashes Product: Wine Version: CVS/GIT Platform: PC URL: http://www.cp-lab.com/Files/PwdManager-Setup.exe OS/Version: Linux Status: NEW Keywords: download Severity: normal Priority: P2 Component: comctl32 AssignedTo: wine-bugs@winehq.org ReportedBy: xerox_xerox2000@yahoo.co.uk
Hi, a user submitted this app to appdb, with garbage results. It crashes for me too, with a message box: "Access Violation in password.dll". From a debug log it looks as if something goes wrong in comctl32.ImageList_Draw(). Using native comctl32 it starts fine for me. I'll attach debug trace
http://bugs.winehq.org/show_bug.cgi?id=11259
--- Comment #1 from Louis Lenders xerox_xerox2000@yahoo.co.uk 2008-01-19 01:57:24 --- Created an attachment (id=10356) --> (http://bugs.winehq.org/attachment.cgi?id=10356) last 3000 lines before the crash
http://bugs.winehq.org/show_bug.cgi?id=11259
--- Comment #2 from Louis Lenders xerox_xerox2000@yahoo.co.uk 2008-01-19 02:01:17 --- Created an attachment (id=10357) --> (http://bugs.winehq.org/attachment.cgi?id=10357) snapshot of the error message
snapshot of the error message, you can look for this message in the attached debuglog
http://bugs.winehq.org/show_bug.cgi?id=11259
--- Comment #3 from Lei Zhang thestig@google.com 2008-01-22 18:40:57 --- It didn't work with a native comctl32.dll for me...
http://bugs.winehq.org/show_bug.cgi?id=11259
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |focht@gmx.net
--- Comment #4 from Anastasius Focht focht@gmx.net 2008-01-23 16:26:06 --- Hello,
nice one :-) Combination of application bug and wine's <censored> DIB engine which finally kills it.
The app builds several toolstrips. It does this by creating in-memory toolbar strips and merging toolbar images into the dibs. For the 24 bit case, a 240x24 toolstrip DIB gets allocated with bits buffer size = 0x4380 bytes (240*24*3). At virtual memory (OS) level, DIB sections always end up rounded to page size. When the DIB buffer is allocated, it gets registered to internal dibs list, the page protection flags are changed accordingly and vectored SEH is setup if not already done.
At some point the app accesses the DIB beyond the dib_bits_base[0...0x437F] boundary, writing a DWORD signature to dib_bits_base[0x4380]. This is succeeds with Windows because DIB (virtual) memory ends up rounded to page size too and there is no fancy page protection trickery.
In wine, the dreaded vectored DIB SEH gets pulled by the write. The handler walks the dib list, doesn't find any registered bitmap in that address range and finally gives up, leaving exception to next handler in chain, which doesn't know about wine's on-purpose page protection.
There is currently no way to work around such broken apps (besides waiting for new DIB engine to arrive...) Though for detection purposes one could add some diagnostic code to X11DRV_DIB_FaultHandler which takes rounded page size into account (e.g. ((int)physBitmap->base + physBitmap->size + getpagesize()-1) & ~(getpagesize()-1)) and prints some ERR.
Regards
http://bugs.winehq.org/show_bug.cgi?id=11259
--- Comment #5 from Anastasius Focht focht@gmx.net 2008-01-24 08:21:09 --- Hello,
this recent commit should fix the problem by allowing access to bits past the valid physical bits range: http://source.winehq.org/git/wine.git/?a=commit;h=a7cdf6e110e8d5caaafd59e4f8...
The X11DRV_DIB_FaultHandler now includes size of last touched page when calculating phys bitmap memory range.
--- snip --- ... 0009:trace:bitmap:X11DRV_DIB_Unlock Unlocked 0xe78 0009:trace:seh:raise_exception code=c0000005 flags=0 addr=0x6e10e4 0009:trace:seh:raise_exception info[0]=00000001 0009:trace:seh:raise_exception info[1]=00ab4380 0009:trace:seh:raise_exception eax=00000083 ebx=00ab4380 ecx=0000003e edx=00000078 esi=00000001 edi=00000018 0009:trace:seh:raise_exception ebp=000000fa esp=0034f91c cs=0073 ds=007b es=007b fs=0033 gs=003b flags=00010212 0009:warn:bitmap:X11DRV_DIB_FaultHandler 0xe78: access to 0xab4380 beyond the end of the DIB ... --- snip ---
A warn is printed now to detect broken apps.
Regarding "no way to work around such broken apps" .. forget it ;-) The solution was already there (see calculation formula in detection/diagnosis comment)... all that needs to be done is to allow the DIB access even in "bad guy" case. I just overlooked it, maybe it was a bit late :-)
The DIB update works as expected even if bits past the valid physbitmap range are touched because the underlying bits buffer is technically page size rounded (like windows).
This bug can be closed because it's fixed in GIT and the apps starts now.
Regards
http://bugs.winehq.org/show_bug.cgi?id=11259
Louis Lenders xerox_xerox2000@yahoo.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #6 from Louis Lenders xerox_xerox2000@yahoo.co.uk 2008-01-24 10:05:36 ---
This bug can be closed because it's fixed in GIT and the apps starts now.
Yeah, it's fixed. Cool. Closing
http://bugs.winehq.org/show_bug.cgi?id=11259
Louis Lenders xerox_xerox2000@yahoo.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #7 from Louis Lenders xerox_xerox2000@yahoo.co.uk 2008-01-24 10:07:46 --- Closing
http://bugs.winehq.org/show_bug.cgi?id=11259
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|CVS/GIT |unspecified
http://bugs.winehq.org/show_bug.cgi?id=11259
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |a7cdf6e110e8d5caaafd59e4f8e | |ba117fbc3cd12 Component|comctl32 |winex11.drv Version|unspecified |0.9.53.
-
wine-bugs＠winehq.org