Apache OpenOffice (AOO) Bugzilla – Issue 15401
rotated jpg crashes draw
Last modified: 2003-09-08 16:52:24 UTC
Crash occurs after the following procedure: 1 Start a new draw document. Do not draw anything. 2 Insert a jpg graphic into the document. 3 Right click on the image, select Position and Size. 4 Select the Rotation tab 5 Change the rotation angle (e.g. 90 degrees) 5 Print the document. Draw crashes with 'unrecoverable error' If you start the draw document and draw something in it before inserting the jpg, sometimes it won't crash, but I can't consistently reproduce this behaviour. .gif and .bmp files seem to be ok.
Hi, I confirmed this using Windows XP Home and different printer drivers and could reproduce the problem. Kelvin
Exactly the same thing happens if you insert a jpg graphic into a new Impress presentation, rotate it and then try to print out the page.
Excellent catch, thanks. I've reproduced this on Linux. Here's a valgrind stack dump (see http://kegel.com/openoffice/#dump): Invalid memory access of size 1 at 0x40352546: (within libvcl644li.so) by 0x4035434E: Printer::GetPreparedMetaFile(GDIMetaFile const&, GDIMetaFile&, long, long) (in libvcl644li.so) by 0x40307629: ImplQPrinter::ImplPrintHdl(Timer*) (in libvcl644li.so) by 0x4030741C: ImplQPrinter::LinkStubImplPrintHdl(void*, void*) (in libvcl644li.so) by 0x402C13DB: Timer::Timeout() (in libvcl644li.so) by 0x402C10DF: ImplTimerCallbackProc() (in libvcl644li.so) by 0x4045ECB1: SalData::Timeout() const (in libvcl644li.so) by 0x4045E71E: SalXLib::CheckTimeout(bool) (in libvcl644li.so) by 0x4045EAE9: SalXLib::Yield(unsigned char) (in libvcl644li.so) by 0x4046786B: SalInstance::Yield(unsigned char) (in libvcl644li.so) by 0x402BB772: Application::Yield() (in libvcl644li.so) by 0x402BB674: Application::Execute() (in libvcl644li.so) by 0x8065846: desktop::Desktop::Main() (in soffice.bin) by 0x402C0486: SVMain() (in libvcl644li.so) by 0x4045D719: main (in libvcl644li.so) by 0x41508913: __libc_start_main (in /lib/libc-2.2.93.so) by 0x805EAA0: (within soffice.bin) Address 0x0 is not stack'd, malloc'd or free'd sh: line 1: crash_report: command not found
Reassigned to Thorsten. Please have a look at the stack. The crash was only reproduceable once here. Thanks.
Changed priority to p2.
John, Dan, thanks a lot for bringing this up. I have severe problems reproducing the bug, both on Linux and Windows. Does it only happen occasionally for you? Or always? If always, could you share details regarding specific JPEG file and printer used? I presume you used an English beta 2, correct?
Created attachment 6768 [details] jpg file that crashes beta2 draw
Created attachment 6769 [details] draw file with inserted jpg
Created attachment 6770 [details] draw file with rotated jpg
English edition of beta2, set to UK English I have attached files: carrot.jpg is one of the jpg files I used to test (yes, I am a keen gardener) draw1.sxd is the draw file with the inserted jpg, no modifications made. draw2.sxd is the same file, with the carrot rotated 90 degrees. Trying to print draw2.jpg results in a crash. The printer is a samsung ML6060 on Windows NT. Additional information: I tried the same procedure on my copy of Staroffice 6.1beta2, and the same crash occurred. I then allowed the staroffice crash report to be sent back to Sun - at 11:32 0n 10-06-03. There's no referrer code on the return email from Sun so I can't specify it any closer, though the address sent to is john@kingshome.co.uk, and not my posting address on gmane.comp.openoffice.questions. Also check out the thread of a posting I made on officesuite.com. betatest.draw on 08-06-03. There's someone else with a similar problem (the program didn't crash but hung up) I can confirm that it happens **every time** a jpg is rotated in an new draw file.
Thanks for the quick followup, John. I'm now able to reproduce the crash, but only for OOo beta 2 . Anyway, that's all I need for debugging.
Ah, I already fixed this one with internal bugid #109548# about a month ago. If anybody needs an urgent fix: update vcl/source/gdi/print2.cxx to at least version 1.17. Reason was a wrong palette access to a bitmap which didn't have a palette. Reason that this was triggered by rotation is that rotation always adds a transparency mask to bitmaps (although strictly speaking, this could be optimized away for multiple-of-90- degree rotations).
Issue already fixed with bugid #109548#.
Please verify.
*** Issue 15445 has been marked as a duplicate of this issue. ***
Verified.
Fix will be included in 1.1 RC. Thank you very much for your help!! Closed.
*** Issue 16289 has been marked as a duplicate of this issue. ***