http://bugs.winehq.org/show_bug.cgi?id=16585
Summary: Printing document with images crashes wine Product: Wine Version: 1.1.11 Platform: Other OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: tarasov.igor@gmail.com
Created an attachment (id=18107) --> (http://bugs.winehq.org/attachment.cgi?id=18107) WINEDEBUG=+print,+ntprint,+winspool,+driver log
This bug occurs in Watchtower Library 2007. Printing functionality works pretty well, except of one page. All documents in the Library are text files with simple text formatting, no images. However, there are few help pages that also could (and recommended to) be printed that do contain images. I've tried printing various selection parts from these pages, and it is okay until I select image also.
When the application attempts to print these pages wine crashes with:
wine: Unhandled page fault on read access to 0x00000000 at address 0x7d74395c (thread 0009), starting debugger...
WINEDEBUG=+print,+ntprint,+winspool,+driver log attached.
http://bugs.winehq.org/show_bug.cgi?id=16585
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stevie1401@web.de
--- Comment #1 from Vitaliy Margolen vitaliy@kievinfo.com 2008-12-21 11:52:07 --- *** Bug 16583 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=16585
--- Comment #2 from Jeff Zaroyko jeffz@jeffz.name 2008-12-31 18:08:53 --- please install debug symbols or compile wine from source and attach a new backtrace
http://bugs.winehq.org/show_bug.cgi?id=16585
Igor Tarasov tarasov.igor@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #18107|0 |1 is obsolete| |
--- Comment #3 from Igor Tarasov tarasov.igor@gmail.com 2009-01-01 07:02:00 --- Created an attachment (id=18360) --> (http://bugs.winehq.org/attachment.cgi?id=18360) WINEDEBUG=+print,+ntprint,+winspool,+driver log and backtrace
Okay, I have compiled wine and ran it again. Hope this helps.
http://bugs.winehq.org/show_bug.cgi?id=16585
--- Comment #4 from Jeff Zaroyko jeffz@jeffz.name 2009-01-01 07:49:06 --- Created an attachment (id=18364) --> (http://bugs.winehq.org/attachment.cgi?id=18364) hack
hmm, well, the problem seems to be that the cySrc parameter originally passed to OLEPictureImpl_Render is negative which filters down and is used to calculate a buffer size in PSDRV_StretchDIBits for HeapAlloc, which will be some rather large number, hence the crash because it returns 0.
Try this hack, apply with `patch -p1 < hack.diff` then run make again.
http://bugs.winehq.org/show_bug.cgi?id=16585
--- Comment #5 from Jeff Zaroyko jeffz@jeffz.name 2009-01-01 07:50:59 --- oh, and the debug channels you applied before aren't needed, just use +psdrv
http://bugs.winehq.org/show_bug.cgi?id=16585
--- Comment #6 from Igor Tarasov tarasov.igor@gmail.com 2009-01-01 08:34:33 --- Created an attachment (id=18365) --> (http://bugs.winehq.org/attachment.cgi?id=18365) WINEDEBUG=+psdrv log and backtrace
Well, it did not help and introduced new bug: now there are no images in the application at all: http://www.polosatus.ru/wine/wtlib_no_images.png (there were images in these blank squares before patching). Reverting patch puts images back on their place.
And printing that page still leads to crash. Log attached.
http://bugs.winehq.org/show_bug.cgi?id=16585
Jeff Zaroyko jeffz@jeffz.name changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #18364|0 |1 is obsolete| |
--- Comment #7 from Jeff Zaroyko jeffz@jeffz.name 2009-01-01 16:59:25 --- Created an attachment (id=18372) --> (http://bugs.winehq.org/attachment.cgi?id=18372) hack2
Thanks, I was just curious to see what the effect was because I'm not familiar with this area and I don't have the program to test myself.
Try this patch instead.
http://bugs.winehq.org/show_bug.cgi?id=16585
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
http://bugs.winehq.org/show_bug.cgi?id=16585
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #18372|application/octet-stream |text/plain mime type| | Attachment #18372|0 |1 is patch| |
http://bugs.winehq.org/show_bug.cgi?id=16585
--- Comment #8 from Igor Tarasov tarasov.igor@gmail.com 2009-01-02 01:25:57 --- Created an attachment (id=18382) --> (http://bugs.winehq.org/attachment.cgi?id=18382) WINEDEBUG=+psdrv log and backtrace
And another crash...
http://bugs.winehq.org/show_bug.cgi?id=16585
--- Comment #9 from Igor Tarasov tarasov.igor@gmail.com 2009-01-02 16:07:32 --- I think I have figured it out. It's all in dlls/wineps.drv/bitmap.c. This code has a lot of similarities and copypasties from dlls/gdi32/dib.c / dlls/gdi32/bitmap.c. Maybe that code could be somehow combined? AFAIU gdi32 code is much more tested and fixed, and wineps.drv code is pretty buggy. Or it could be at least refactored, esp. in PSDRV_StretchDIBits.
So, I've made it printing and not crashing this way:
As far as I understand it now, PSDRV_StretchDIBits misuses srcHeight and srcWidth. I've been working olny with 32bit image section, and since all other parts have similar code I tend to think that this error is throughout all that function.
http://source.winehq.org/source/dlls/wineps.drv/bitmap.c#L371
I've replaced heightSrc and widthSrc with fullSrcHeight and fullSrcWidth respectevly in all that 'case' section. Since heightSrc sometimes may become negative, and since these heightSrc and widthSrc values are pretty big,
bitmap_size = heightSrc * widthSrc * 3; dst_ptr = bitmap = HeapAlloc(GetProcessHeap(), 0, bitmap_size);
bitmap_size here becomes around -350 000 000, and HeapAlloc just returns 0 and this is one of the reasons for crash.
Also, I've commented out line 375:
src_ptr += (ySrc * widthbytes);
Not sure that this is the most correct way to work this around, but ySrc in my case contains the same value as fullSrcHeight. This means, that pointer gets moved to the end of allocated memory and then in starts iterating it, increasing pointer. Clearly, it leads to crash, since memory manager won't allow getting out of boundaries.
So, there were at least 2 reasons for crash. I post it all here since I am not that good in C and this code to understand why it all works so wrong and how it all should work. So, any help is appreciated. :)
http://bugs.winehq.org/show_bug.cgi?id=16585
Jeff Zaroyko jeffz@jeffz.name changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords|patch |
http://bugs.winehq.org/show_bug.cgi?id=16585
--- Comment #10 from Igor Tarasov tarasov.igor@gmail.com 2009-01-04 02:14:34 --- Well, after a lot of digging, I've found the following:
1. Image display is done through OLE IPicture. 2. Real image size is 467 x 338 (for simplicity, let's talk only about the first one). 3. But size that is being passed to PSDRV_StretchDIBits is 12356 x -8942. 4. OLEPictureImpl_Render may render picture to various devices. 5. ...including winex11 and it passes quite the same parameters to BITBLT_InternalStretchBlt. 6. But it does not crash, and works as expected.
The difference between BITBLT_InternalStretchBlt and PSDRV_StretchDIBits in their handling of incoming data is that BITBLT_InternalStretchBlt converts logical coordinates to device coordinates (via LPtoDP) for source coordinates. See http://source.winehq.org/source/dlls/winex11.drv/bitblt.c#L1285
So, the fix seems to be simple: just add LP2DP conversion for source coordinates to PSDRV_StretchDIBits. But there is one problem: LPtoDP requires source device handle, but it does not being passed to PSDRV_StretchDIBits.
Or, possibly, this conversion should be done somewhere here: http://source.winehq.org/source/dlls/gdi32/bitblt.c#L172
http://bugs.winehq.org/show_bug.cgi?id=16585
--- Comment #11 from Igor Tarasov tarasov.igor@gmail.com 2009-01-27 06:47:34 --- Created an attachment (id=19020) --> (http://bugs.winehq.org/attachment.cgi?id=19020) patch
Okay, I've attempted to implement it, so here is the patch. It works well for me.
http://bugs.winehq.org/show_bug.cgi?id=16585
--- Comment #12 from Austin English austinenglish@gmail.com 2009-01-27 09:47:05 --- (In reply to comment #11)
Created an attachment (id=19020)
--> (http://bugs.winehq.org/attachment.cgi?id=19020) [details]
patch
Okay, I've attempted to implement it, so here is the patch. It works well for me.
A testcase would help. Please send patches to wine-patches@winehq.org.
http://bugs.winehq.org/show_bug.cgi?id=16585
--- Comment #13 from Igor Tarasov tarasov.igor@gmail.com 2009-01-28 03:56:55 --- The patch sent: http://www.winehq.org/pipermail/wine-patches/2009-January/068450.html
What's next?
http://bugs.winehq.org/show_bug.cgi?id=16585
--- Comment #14 from Austin English austinenglish@gmail.com 2009-01-28 09:31:34 --- (In reply to comment #13)
The patch sent: http://www.winehq.org/pipermail/wine-patches/2009-January/068450.html
What's next?
Wait for it to be applied. If it's not, ask for feedback on wine-devel (though, likely the thing you'll hear most is requests for a testcase).
http://bugs.winehq.org/show_bug.cgi?id=16585
--- Comment #15 from Igor Tarasov tarasov.igor@gmail.com 2009-01-28 09:37:35 --- I see it already committed: :)
http://www.winehq.org/pipermail/wine-cvs/2009-January/052444.html
http://bugs.winehq.org/show_bug.cgi?id=16585
--- Comment #16 from Austin English austinenglish@gmail.com 2009-01-28 09:47:17 --- Fixed then?
http://bugs.winehq.org/show_bug.cgi?id=16585
Igor Tarasov tarasov.igor@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |FIXED
--- Comment #17 from Igor Tarasov tarasov.igor@gmail.com 2009-01-28 09:50:17 --- Yep!
http://bugs.winehq.org/show_bug.cgi?id=16585
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #18 from Alexandre Julliard julliard@winehq.org 2009-01-30 11:04:42 --- Closing bugs fixed in 1.1.14.