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