Apache OpenOffice (AOO) Bugzilla – Issue 19065
OO1.1 Beta2 crashes with PDF Export, 1.0.3.1 with the same document when printing
Last modified: 2004-05-13 10:31:16 UTC
I put the document (doc with corrupted OLE object) on http://alt.quaxi.com/docs/notprintable.sxw When printing: * We tested it on: Windows2000 with OpenOffice.org 1.0.3.1 german -> crash with Error: "to few RAM" Linux / OO.O 1.1Beta2 German: Printing OK PDF Export: Same Problem
reproduced with Sparc / PDF-Export. It seems that the filter tries to scale a bitmap and fails. =>[1] _libc_poll(0xffbfb2f0, 0x2, 0x258, 0x0, 0x0, 0x0), at 0xff31ae00 [2] _libc_select(0x258, 0xff33d19c, 0x0, 0xff33d19c, 0xffbfb640, 0x0), at 0xff2cd474 [3] _ti_select(0x3a, 0xffbfb640, 0x0, 0xffbfb5c0, 0xffbfb5b8, 0x2000), at 0xff35ec7c [4] SalXLib::Yield(0x9e128, 0xffbfb5b8, 0xfb842, 0x0, 0xf4240, 0xfeef7968), at 0xfee89998 [5] Application::Yield(0xfef08a3c, 0x2194, 0xfece5a3c, 0xfeef7968, 0xfef0889c, 0x2000), at 0xfece5a3c [6] Dialog::Execute(0xffbfb840, 0xfebddf78, 0xfef0889c, 0x1, 0x0, 0xfeef7968), at 0xfedbfcb0 [7] SfxNewHdl::MemoryWarning(0x1f8618, 0x3328, 0xffbfb840, 0xfb486900, 0x10ac4c, 0x2100000), at 0xfb37bd4c [8] operator new(0xfffffad4, 0x0, 0x13950, 0xfecf44e0, 0xff1c9ad8, 0xfb37bca8), at 0xff1b6200 [9] BitmapReadAccess::ImplCreate(0x700cd8, 0xffbfbcc4, 0x58bc90, 0x2000, 0x1eab14, 0xfffffeb5), at 0xfed0d0ec [10] Bitmap::AcquireWriteAccess(0xffbfbcc4, 0x2000, 0x2021d0, 0xfecf4994, 0xfeef7968, 0x700cd8), at 0xfecf57cc [11] Bitmap::ImplScaleFast(0xffbfc06c, 0xffbfbe10, 0xffbfbe08, 0xff3c2a6c, 0x400, 0x59799c), at 0xfed0127c [12] BitmapEx::Scale(0xffbfc06c, 0xffbfbe10, 0xffbfbe08, 0x1, 0x5984d8, 0x6), at 0xfed0a8ac [13] BitmapEx::Scale(0xffbfc06c, 0xffbfc008, 0x1, 0x64, 0x164, 0xfff8b8b8), at 0xfed0a98c [14] 0xf7a61cb0(0xffbfc03c, 0x3b49a0, 0x0, 0x1, 0x5769f4, 0x5769fc), at 0xf7a61caf [15] 0xf7a611cc(0xffbfca10, 0x3b49a0, 0x5769f4, 0xffbfc550, 0x1, 0x1), at 0xf7a611cb [16] 0xf7a603f8(0xffbfca10, 0x3b49a0, 0xffbfc77c, 0x1, 0x5d, 0xffbfc550), at 0xf7a603f7 [17] 0xf7a5fa54(0x4c0, 0xf7a62c68, 0x1, 0xf7a78a0c, 0xf7a62c40, 0x0), at 0xf7a5fa53 [18] 0xf7a5d938(0xf7efe4f0, 0xf7a5dffc, 0xd8, 0x0, 0xf7a78a0c, 0xf7a77638), at 0xf7a5d937 [19] 0xf7a5db3c(0xf7efe4f0, 0xffbfcb34, 0x0, 0xfb21dc64, 0x57a84, 0xfb49b7ec), at 0xf7a5db3b [20] SfxObjectShell::ExportTo(0xf8366950, 0x5b3b68, 0x0, 0xfb486900, 0xfb22113c, 0xfb49be68), at 0xfb21dcc8 [21] SfxObjectShell::SaveTo_Impl(0x39d508, 0x5b3b68, 0x0, 0x2a72b0, 0x0, 0xfb486900), at 0xfb21ab30 [22] SfxObjectShell::PreDoSaveAs_Impl(0x39d508, 0xffbfce68, 0xffbfcdd0, 0x5b3b68, 0x35c110, 0xffbfcdd4), at 0xfb21f494 [23] SfxObjectShell::CommonSaveAs_Impl(0x39d508, 0xffbfded0, 0x3, 0x569fa0, 0xffbfceb4, 0x1), at 0xfb21ec6c [24] SfxObjectShell::GUISaveAs_Impl(0x115538, 0xffbfd024, 0x1, 0x39d508, 0xffbfd0c4, 0xffbfd0f4), at 0xfb22b950 [25] SfxObjectShell::ExecFile_Impl(0x39d508, 0xffbfebe4, 0x2400, 0xfc11f38c, 0xffbfe200, 0x1a11), at 0xfb22d988 [26] SfxDispatcher::Call_Impl(0x393608, 0x39d508, 0xfb4a46a4, 0xffbfebe4, 0x0, 0x29c468), at 0xfb2be25c [27] SfxBindings::Execute_Impl(0x29c468, 0xffbfebe4, 0xfb4a46a4, 0x39d508, 0x0, 0x0), at 0xfb2d0188 [28] SfxBindings::Execute_Impl(0x29c468, 0x1a11, 0x0, 0x0, 0x0, 0xc97b0), at 0xfb2cfcc4 [29] SfxBindings::Execute(0x29c468, 0x1a11, 0x0, 0x0, 0x0, 0x0), at 0xfb2cf834 [30] SfxVirtualMenu::Select(0x63ff50, 0x48f0a8, 0x11f8, 0x19dc50, 0x125b, 0xfebddf78), at 0xfb2e910c [31] Menu::Select(0x48f0a8, 0x48f0a8, 0xd, 0xf7efc540, 0xd0, 0x1a11), at 0xfedc59d0 [32] Menu::ImplCallSelect(0x48f0a8, 0x0, 0xfedc5980, 0xfee0cb24, 0x12ea4c, 0xfef1189c), at 0xfedc8f4c [33] 0xfee0cb24(0xc9788, 0xfedc8f18, 0x4, 0x1, 0xff14fc50, 0xffffff58), at 0xfee0cb23 [34] ImplWindowFrameProc(0x396fd0, 0xfee0cf60, 0x16, 0xc9788, 0x4d8, 0x54), at 0xfee0d438 [35] SalFrameData::HandleClientMessage(0xfee0cfe0, 0xffbff160, 0x2, 0x944b0, 0xff14fbc8, 0x1), at 0xfee634f4 [36] SalFrameData::Dispatch(0x397238, 0xffbff160, 0xfee63964, 0x700, 0x7c, 0xfeef7968), at 0xfee64068 [37] SalDisplay::Dispatch(0xaad60, 0xffbff160, 0x21, 0x0, 0xff1b36d8, 0xfef08a3c), at 0xfee8fcec [38] SalDisplay::Yield(0xaad60, 0x0, 0x9e128, 0x1, 0x587e60, 0x5), at 0xfee8f9ac [39] 0xfee8ad0c(0x2194, 0xaad60, 0xff170f54, 0xfee8ac38, 0xfeef7968, 0x2000), at 0xfee8ad0b [40] SalXLib::Yield(0xfee8acbc, 0xfef1f3d4, 0x1, 0x0, 0xfee89818, 0xfeef7968), at 0xfee89818 [41] Application::Yield(0xfef08a3c, 0x2194, 0xfece5a3c, 0xfeef7968, 0xfef0889c, 0x2000), at 0xfece5a3c [42] Application::Execute(0xfef08a3c, 0x2194, 0x99518, 0xfeef7968, 0x212090, 0x2000), at 0xfece590c [43] desktop::Desktop::Main(0x9ad14, 0xfc596174, 0xfc6f8, 0x15ed70, 0xffbff624, 0xffbff640), at 0x2a930 [44] SVMain(0x2194, 0x2000, 0x99518, 0xfeef7968, 0xfef0889c, 0x1), at 0xfeceb2e0 [45] main(0x2, 0xffbff7bc, 0xffbff7c8, 0x9ac00, 0x0, 0x0), at 0x4ede4
Hm, looks consistent with the user comment (too few RAM). Only question is, is the RAM request unjustified (i.e. way too large), or did the box simply run out of memory?
I have 768MB RAM plus 1,5GB swap, so I guess the request is wrong
I think the reason may be the corrupted OLE object that perhaps contains a Bitmap that is 489632623x457567832 or some such - i'm guessing here but that would certainly lead to the Bitmap code requesting too much memory. Question is: should the bitmap code check the values or the one who calls it ? Or both ?
I think the bug is not shown when printing with OO.o1.1 beta2, the bug is still left in the PDF export (also in rc). So it should be a known problem, isn't it.
The stuff above the Bitmap code is actually in the pdffilter library, that's true.
-
Got it. Problem was that for the OutputDevice, negative bitmap sizes can happen and have the meaning of "mirror the bitmap in that direction". Only that the Bitmap/BitmapEx interface does not care about that, and happily tried to generate a _really_ large bitmap (signed int interpreted as unsigned).
.
Please verify.
set to fixed
Verified in cws thb07 on Lin, Win.
The fix is integrated in OOo1.1.1 on Sols, Lin, Win. This version will be available soon.
*** Issue 21301 has been marked as a duplicate of this issue. ***