Apache OpenOffice (AOO) Bugzilla – Issue 16015
Can't load document--get an error message
Last modified: 2013-08-07 14:42:08 UTC
Some documents open without trouble, but one gives me: /Users/martinro/bin/office: line 1: 2794 Abort trap sh /Applications/ OpenOffice.org1.0.1/program/soffice whenever I try to open it. Can I send the document to someone to try to get it to work? It is fairly complex and has equations in it.
Yes, please upload it as an attachment to this issue report. (Click on "Create a new attachment" a couple lines above the "Additional Comments" box. Thanks!
Created attachment 7126 [details] This is the file that will not load. It is a word doc file
I tried loading this in both 1.0.3 and 1.1b2 on Linux just to see if the problem occurs there. No crash in either case. FWIW, 1.1b2 handles this document much nicer than 1.0.3; 1.0.3 has rendering problems on every page, but 1.1 gets most pages reasonably correct (I still see a lot of boxes in the formulae on pages 1 through 5 in ooo1.1beta2). Somebody with a Mac will have to try to reproduce the crash...
On Mac OS X 10.2.3, Dual CPU machine, XDarwin 1.1.1.1/XFree86 4.2.1.1, windowmaker 0.62 Window Manager, OOO 1.0.3GM, I get the following crash when trying to import the document. ********** Date/Time: 2003-06-29 19:21:33 -0700 OS Version: 10.2.3 (Build 6G30) Host: twinpeaks.local. Command: soffice.bin PID: 3504 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x0000000c Thread 0 Crashed: #0 0x004bc80c in SvStream::Seek(unsigned long) #1 0x0057ea44 in UCBStorageStream_Impl::Init(void) #2 0x0057e488 in UCBStorageStream_Impl::UCBStorageStream_Impl(String const &, unsigned short, UCBStorageStream *, unsigned char, ByteString const *) #3 0x005870bc in UCBStorage_Impl::OpenStream(UCBStorageElement_Impl *, unsigned short, unsigned char, ByteString const *) #4 0x00586ec0 in UCBStorage::OpenStream(String const &, unsigned short, unsigned char, ByteString const *) #5 0x00587600 in UCBStorage::OpenStorage_Impl(String const &, unsigned short, unsigned char, unsigned char) #6 0x00587274 in UCBStorage::OpenOLEStorage(String const &, unsigned short, unsigned char) #7 0x005913e0 in Storage::CopyTo(String const &, BaseStorage *, String const &) #8 0x0059e77c in SotStorage::CopyTo(String const &, SotStorage *, String const &) #9 0x02495424 in SvStorage::CopyTo(String const &, SotStorage *, String const &) #10 0x03b4f828 in SvxMSDffManager::CreateSdrOLEFromStorage(String const &, SvStorageRef &, SvStorageRef &, Graphic const &, Rectangle const &, SvStream *, unsigned long) #11 0x079cab1c in SwWW8ImplReader::ImportOleBase(Graphic &, unsigned char, Graphic const *, SfxItemSet const *) #12 0x079ca02c in SwWW8ImplReader::ImportOle(Graphic const *, SfxItemSet const *) #13 0x079b5070 in SwWW8ImplReader::ImportGraf(SdrTextObj *, SwFrmFmt *, unsigned char) #14 0x079b8890 in SwWW8ImplReader::ReadChar(long, long) #15 0x079b82a4 in SwWW8ImplReader::ReadChars(long &, long, long, long) #16 0x079b9064 in SwWW8ImplReader::ReadText(long, long, short) #17 0x079ba1ac in SwWW8ImplReader::LoadDoc1(SwPaM &, WW8Glossary *) #18 0x079bb018 in SwWW8ImplReader::LoadDoc(SwPaM &, WW8Glossary *) #19 0x079bb17c in WW8Reader::Read(SwDoc &, SwPaM &, String const &) #20 0x078dbbc8 in SwReader::Read(Reader const &) #21 0x07a4f80c in SwDocShell::ConvertFrom(SfxMedium &) #22 0x02baf38c in SfxObjectShell::DoLoad(SfxMedium *) #23 0x02af7634 in LoadEnvironment_Impl::Load(SfxObjectFactory const *) #24 0x02af95a0 in LoadEnvironment_Impl::LoadDataAvailable(void) #25 0x02af94b0 in LoadEnvironment_Impl::LoadDataAvailable(void) #26 0x02af66d0 in LoadEnvironment_Impl::Start(void) #27 0x02c1e918 in SfxFrameLoader::load(com::sun::star::uno::Sequence< com::sun::star::beans::PropertyValue> const &, com::sun::star::uno::Reference<com::sun::star::frame::XFrame> const &) #28 0x0546f40c in framework::BaseDispatcher::implts_loadIt(com::sun::star::util::URL const &, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> &, rtl::OUString const &, com::sun::star::uno::Reference< com::sun::star::frame::XFrame> const &, com::sun::star::uno::Any const &) #29 0x0547f588 in framework::BlankDispatcher::dispatch(com::sun::star::util::URL const &, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const & ) #30 0x02aa2b50 in SfxApplication::OpenDocExec_Impl(SfxRequest &) #31 0x02aadb28 in SfxStubSfxApplicationOpenDocExec_Impl(SfxShell *, SfxRequest &) #32 0x02ca95b8 in CallExec__8SfxShellPFPB0R10SfxRequest_vRB2 #33 0x02c8ece0 in SfxDispatcher::Call_Impl(SfxShell &, SfxSlot const &, SfxRequest &, unsigned char) #34 0x02c92374 in SfxDispatcher::PostMsgHandler(SfxRequest *) #35 0x02c92270 in SfxDispatcher::LinkStubPostMsgHandler(void *, void *) #36 0x02cc5400 in SfxHintPoster::Event(SfxHint *) #37 0x02cc5370 in SfxHintPoster::DoEvent_Impl(SfxHint *) #38 0x00e2d234 in Link::Call(void *) const #39 0x00e2c3d0 in ImplHandleUserEvent(ImplSVEvent *) #40 0x00e2d00c in ImplWindowFrameProc(void *, SalFrame *, unsigned short, void const *) #41 0x00e99110 in SalFrameData::Call(unsigned short, void const *) const #42 0x00e970c0 in SalFrameData::HandleClientMessage(XClientMessageEvent *) #43 0x00e97b60 in SalFrameData::Dispatch(_XEvent *) #44 0x00ebefd8 in SalDisplay::Dispatch(_XEvent *) #45 0x00ebecf8 in SalDisplay::Yield(unsigned char) #46 0x00ebac24 in DisplayYield(int, SalDisplay *) #47 0x00eb97f8 in SalXLib::Yield(unsigned char) #48 0x00ec19e4 in SalInstance::Yield(unsigned char) #49 0x00d32924 in Application::Yield(void) #50 0x00d327b0 in Application::Execute(void) #51 0x00008470 in Desktop::Main(void) #52 0x00d36f78 in SVMain(void) #53 0x00eb8960 in main #54 0x000026b0 in _start #55 0x000024e0 in start Thread 1: #0 0x90042688 in semaphore_timedwait_signal_trap #1 0x9003e8b4 in _pthread_cond_wait #2 0x0029ae0c in osl_waitCondition #3 0x0131ae6c in store::OStorePageDaemon_Impl::run(void) #4 0x0131b9b8 in threadFunc #5 0x0029f524 in osl_thread_start_Impl #6 0x90020d48 in _pthread_body Thread 2: #0 0x9003142c in accept #1 0x002aa474 in osl_acceptPipe #2 0x001008a4 in vos::OPipe::accept(vos::OStreamPipe &) #3 0x00017258 in desktop::OfficeIPCThread::run(void) #4 0x000fb550 in vos::_cpp_OThread_WorkerFunction(void *) #5 0x0029f524 in osl_thread_start_Impl #6 0x90020d48 in _pthread_body Thread 3: #0 0x9003eaa8 in semaphore_wait_signal_trap #1 0x9003e8c4 in _pthread_cond_wait #2 0x01bea890 in fileaccess::StatusFiller::run(void *) #3 0x01bea0fc in runThread #4 0x90020d48 in _pthread_body Thread 4: #0 0x90042688 in semaphore_timedwait_signal_trap #1 0x9003e8b4 in _pthread_cond_wait #2 0x0029ae0c in osl_waitCondition #3 0x000f5304 in vos::OCondition::wait(TimeValue const *) #4 0x000feae4 in vos::OTimerManager::run(void) #5 0x000fb550 in vos::_cpp_OThread_WorkerFunction(void *) #6 0x0029f524 in osl_thread_start_Impl #7 0x90020d48 in _pthread_body Thread 5: #0 0x900257ac in select #1 0x0538dd9c in poll(pollfd *, int, int) #2 0x0538c4ec in x11::SelectionManager::dispatchEvent(int) #3 0x0538c648 in x11::SelectionManager::run(void *) #4 0x0029f524 in osl_thread_start_Impl #5 0x90020d48 in _pthread_body PPC Thread State: srr0: 0x004bc80c srr1: 0x0200f930 vrsave: 0x00000000 xer: 0x00000000 lr: 0x0057ea44 ctr: 0x004bc7f4 mq: 0x00000000 r0: 0x0057ea44 r1: 0xbfffd250 r2: 0x00000000 r3: 0x00000000 r4: 0x00000000 r5: 0x00000006 r6: 0x06bee016 r7: 0x00000034 r8: 0x00230010 r9: 0x3bff0000 r10: 0x06def010 r11: 0x005ba7ac r12: 0x004bc7f4 r13: 0xbfffda8c r14: 0x00000000 r15: 0x00000000 r16: 0xbfffd88c r17: 0x00000001 r18: 0xbfffdae0 r19: 0x00000001 r20: 0xbfffd888 r21: 0x00000000 r22: 0xbfffd894 r23: 0x0579cd40 r24: 0xbfffd360 r25: 0x00000000 r26: 0x07303ba0 r27: 0x00000001 r28: 0x07316720 r29: 0x07316720 r30: 0x00000000 r31: 0x0057e160
Thanks for uploading the stack dump! Terry, have you considered joining the OOo QA project? That way you could mark these bugs as 'confirmed' yourself without waiting for someone like me.
Reassigned to MRU
MRU->MBA: crash is also reproducable on Solaris (not only on MacOS). I think, the reason are the loads of OLe objects in the document.
Mikhail, please have a look
The problem take place in case of restriction to number of opened file handles. In such case office must handle the problem gracefully. For OOo2.0 a new caching mechanism may be implemented.
cmc->mav: Is CopyTo leaking a file descriptor ?, using lsof under solaris before and after a CopyTo shows me that an extra fd is used.
Ups, exectly, the UCBStorageStream the destination storage is based on was not closed in time. Fixed. Unfortunatelly this does not really help to load the document, progress handler goes farther now bug the office still crashes because of the same problem. To fix it the maximum allowed number of open filedescryptors is encreased in function main() now. But in case the number of open file descryptors has a linear dependency from number of embedded objects in a document, it will not really fix the problem since it is still possible to create a huge document that will let office crash. A new caching mechanism can be a solution for OOo2.0 in this case.
Excellent, where was the CopyTo leak fixed ? I think the winword import will be able to cut down on the number of open file descriptors it uses during import of objects, but I want to experiment with the CopyTo fix in place. I believe that optimally the applications themselves should only need a fd for each object currently in their ole cache (default 30) and not for every object in the document.
The fix for the leak in CopyTo method is in 'sot' project. It is already commited to the SRX645/fwkrc32 child workspace. Following files are changed M inc/stg.hxx 1.19 -> 1.19.30.1 M source/sdstor/stg.cxx 1.11 -> 1.11.70.1 M source/sdstor/stgcache.cxx 1.2 -> 1.2.76.1 M source/sdstor/stgcache.hxx 1.3 -> 1.3.30.1 M source/sdstor/ucbstorage.cxx 1.78 -> 1.78.22.1 The change of maximal number of file descryptors is commited to this child workspace also ( 'vcl' project ).
Change to target 'OOo 1.1 RC', this task have to bve fixed for final release of OOo 1.1.
Ok, the main problem is fixed. Further investigations will be done for OOo2.0.
Fix reviewed
Just to finalize. This problem take place on any unix system that has restrictions for number of open file descriptors as well as on mac system that has same restriction. To reproduce the problem it is just anough to execute 'limit openfiles 256' in the shell before start of soffice. The bugfix contain fix for the leak in Storage::CopyTo() method and also fix in 'main()' function for unix to increase maximal number of filedescryptors. The fix in vcl project that resets maximal number of filedescryptors is done only for unix systems. It should be ported to mac also, a new issue is created i16969.
Does this mean issue 6991 is also fixed?
Not really. As I mentioned above the fix for this bug fixes problem partially. As I understood Caolan, there are still things to fix for OOo2.0.
Sending for testing.
ATR: checked in cws fwkrc32, fixed.
.
..
atr: checked again in srx645_m14s1, bug is fixed.