Apache OpenOffice (AOO) Bugzilla – Issue 14968
crasher race condition loading 'bad' URIs ...
Last modified: 2004-11-19 17:03:33 UTC
For some reason, my OO.o doesn't like https:// URIs of a certain form; thus if you run: soffice.bin https://foo.com/test.doc & soffice.bin https://foo.com/baa.ppt It will SEGV for you; this seems to be due to a message coming in in the time that we're waiting for the Application::Quit to finish, and it seems to be fixed by NULLing some pointers in Deinitialize; patch attached; here are the traces: Find where ~SfxFilterManager is called: (gdb) bt #0 0xffffe002 in ?? () #1 0x46702fde in ~SfxFilterMatcher (this=0x81ee090) at /opt/OpenOffice/OOO_1_0_3/sfx2/source/bastyp/fltfnc.cxx:801 #2 0x464f5e20 in SfxApplication::Deinitialize() (this=0x8106248) at /opt/OpenOffice/OOO_1_0_3/sfx2/source/appl/appquit.cxx:319 #3 0x464e6430 in SfxTerminateListener_Impl::notifyTermination(com::sun::star::lang::EventObject const&) (this=0x4747bce0, aEvent=@0xbfffdfd0) at /opt/OpenOffice/OOO_1_0_3/sfx2/source/appl/appinit.cxx:229 #4 0x48687ff4 in framework::Desktop::impl_sendNotifyTerminationEvent() () from ./libfwk641li.so #5 0x48681b58 in framework::Desktop::terminate() () from ./libfwk641li.so #6 0x08075923 in desktop::DispatchWatcher::executeDispatchRequests(_STL::vector<desktop::DispatchWatcher::DispatchRequest, _STL::allocator<desktop::DispatchWatcher::DispatchRequest> > const&) () #7 0x08069c17 in desktop::OfficeIPCThread::ExecuteCmdLineRequests(desktop::ProcessDocumentsRequest const&) () #8 0x08067d42 in desktop::ProcessEventsClass_Impl::ProcessDocumentsEvent(desktop::ProcessEventsClass_Impl*, void*) () #9 0x40335128 in ImplHandleUserEvent(ImplSVEvent*) () from ./libvcl641li.so #10 0x403358ef in ImplWindowFrameProc(void*, SalFrame*, unsigned short, void const*) () from ./libvcl641li.so #11 0x40391f60 in SalFrameData::HandleClientMessage(XClientMessageEvent*) () from ./libvcl641li.so #12 0x403925f3 in SalFrameData::Dispatch(_XEvent*) () from ./libvcl641li.so #13 0x403bcb18 in SalDisplay::Dispatch(_XEvent*) () from ./libvcl641li.so #14 0x403bc84f in SalDisplay::Yield(unsigned char) () from ./libvcl641li.so #15 0x403b87dd in DisplayYield(int, SalDisplay*) () from ./libvcl641li.so #16 0x403b7099 in SalXLib::Yield(unsigned char) () from ./libvcl641li.so #17 0x403bfdae in SalInstance::Yield(unsigned char) () from ./libvcl641li.so #18 0x40233b77 in Application::Yield() () from ./libvcl641li.so #19 0x40233aa7 in Application::Execute() () from ./libvcl641li.so #20 0x080601c4 in Desktop::Main() () #21 0x40235ec7 in SVMain() () from ./libvcl641li.so #22 0x403b5fc8 in main () from ./libvcl641li.so #23 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6 After continuing from here we get: Program received signal SIGSEGV, Segmentation fault. 0x4053b9d8 in CBlock::Count() const (this=0x11) at ../../inc/impcont.hxx:109 109 ../../inc/impcont.hxx: No such file or directory. in ../../inc/impcont.hxx (gdb) bt #0 0x4053b9d8 in CBlock::Count() const (this=0x11) at ../../inc/impcont.hxx:109 #1 0x4053b2eb in Container::GetObject(unsigned long) const (this=0x81d9d9c, nIndex=0) at /opt/OpenOffice/OOO_1_0_3/tools/source/memtools/contnr.cxx:1411 #2 0x46708d8c in SfxFContainerList_Impl::GetObject(unsigned long) const (this=0x81d9d9c, nIndex=0) at /opt/OpenOffice/OOO_1_0_3/sfx2/source/bastyp/fltfnc.cxx:759 #3 0x4670528a in SfxFilterMatcher::GetFilter4EA(String const&, unsigned long, unsigned long) const (this=0x81ef518, rStr=@0xbfffcc60, nMust=1, nDont=917504) at /opt/OpenOffice/OOO_1_0_3/sfx2/source/bastyp/fltfnc.cxx:1369 #4 0x465fa5d1 in SfxFrameLoader::detect(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue>&) (this=0x48855f68, lDescriptor=@0xbfffd400) at /opt/OpenOffice/OOO_1_0_3/sfx2/source/view/frmload.cxx:586 #5 0x4880eaa9 in framework::TypeDetection::queryTypeByDescriptor(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue>&, unsigned char) () from ./libfwl641li.so #6 0x4866f0ad in framework::BaseDispatcher::implts_detectType(com::sun::star::util::URL const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue>&, unsigned char) () from ./libfwk641li.so #7 0x48678f82 in framework::BlankDispatcher::dispatch(com::sun::star::util::URL const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) () from ./libfwk641li.so #8 0x4866d956 in framework::BaseDispatcher::dispatchWithNotification(com::sun::star::util::URL const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&, com::sun::star::uno::Reference<com::sun::star::frame::XDispatchResultListener> const&) () from ./libfwk641li.so #9 0x48683a98 in framework::Desktop::loadComponentFromURL(rtl::OUString const&, rtl::OUString const&, long, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) () from ./libfwk641li.so #10 0x080740a1 in desktop::DispatchWatcher::executeDispatchRequests(_STL::vector<desktop::DispatchWatcher::DispatchRequest, _STL::allocator<desktop::DispatchWatcher::DispatchRequest> > const&) () #11 0x08069c17 in desktop::OfficeIPCThread::ExecuteCmdLineRequests(desktop::ProcessDocumentsRequest const&) () #12 0x080622d2 in Desktop::OpenClients() () #13 0x0806064b in Desktop::OpenClients_Impl(void*) () #14 0x08060636 in Desktop::LinkStubOpenClients_Impl(void*, void*) () #15 0x40335128 in ImplHandleUserEvent(ImplSVEvent*) () from ./libvcl641li.so #16 0x403358ef in ImplWindowFrameProc(void*, SalFrame*, unsigned short, void const*) () from ./libvcl641li.so #17 0x40391f60 in SalFrameData::HandleClientMessage(XClientMessageEvent*) () from ./libvcl641li.so #18 0x403925f3 in SalFrameData::Dispatch(_XEvent*) () from ./libvcl641li.so #19 0x403bcb18 in SalDisplay::Dispatch(_XEvent*) () from ./libvcl641li.so #20 0x403bc84f in SalDisplay::Yield(unsigned char) () from ./libvcl641li.so #21 0x403b87dd in DisplayYield(int, SalDisplay*) () from ./libvcl641li.so #22 0x403b7099 in SalXLib::Yield(unsigned char) () from ./libvcl641li.so #23 0x403bfdae in SalInstance::Yield(unsigned char) () from ./libvcl641li.so #24 0x40233b77 in Application::Yield() () from ./libvcl641li.so #25 0x40233aa7 in Application::Execute() () from ./libvcl641li.so #26 0x080601c4 in Desktop::Main() () #27 0x40235ec7 in SVMain() () from ./libvcl641li.so #28 0x403b5fc8 in main () from ./libvcl641li.so #29 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6 (gdb) quit [ a different trace, but it's operating on the free'd filter manager] The attached patch stops the crash.
Created attachment 6473 [details] minimal patch
Since this seems to be triggered only by my VFS ucp + disabled OpenSSL - presumably causing some fairly unusual failure inside the loading logic, this is going to be ~impossible for you to repeat I think; I've tried with misc. other odd URIs eg. ldap: slot: etc. but can't repeat it for you. Nevertheless the patch is obviously not harmful so ...
.
Could this be the same underlying bug as issue 16270 ?
TM->MH: Please have a look at this issue and the patch.
mh->mba: please review.
Sorry, I don't understand what you're doing. I tested it on Linux (with a src680.m3 build) and I got an error message without any crash. I don't think that such a patch is useful in any way, because it only cures the symptoms, not the root cause. But I can't investigate any root cause if I can't reproduce the issue. I think if it happens only with the VFS UCP it is obviously a problem there and should be fixed there. Could you explain where in the code anybody waits for Application::Quit to finish and why?
Matthias: > I tested it on Linux (with a src680.m3 build) and I got an error > message without any crash. I don't think that such a patch is useful > in any way, because it only cures the symptoms, not the root cause. > But I can't investigate any root cause if I can't reproduce the issue. Well; if you install our VFS UCP, and build that, and disable https:// in Gnome VFS and then do as above it's 100% repeatable. > I think if it happens only with the VFS UCP it is obviously a > problem there and should be fixed there. It's completeley clear to me that this isn't a problem in the UCP. Since it would be hard for you to repeat I spent a long time carefully tracking down where and (probably what) the problem is. The two stack traces I think make it extremely clear that this has nothing to do with the UCP per-se but is likely to be a (possibly X specific) event ordering / emission problem. > Could you explain where in the code anybody waits for > Application::Quit to finish and why? Certainly - Application::Execute is constantly waiting for pSVData->maAppData.mbAppQuit to be true; during this time it calls Application::Yield. Application::Quit posts a user event 'ImplQuitMsg' - ie. it does not immediately quit. This queues the event on the default window; at some stage - we hit Yield:: again when the event is processed. Of course - while this is all waiting to happen, it seems we continue processing events / incoming requests somehow, and after Desktop::terminate -> SfxApplication::Deinitialize has been called, we then somehow again get another loadComponentFromURL coming in that uses the free'd object. At least - that is my hyopthesis; I can try and reproduce this in 1.1.0 but I would have imagined that with some more knowledge of the code it'd be obvious what is happening.
So let me summarize: there is a "Quit" request being executed (I assume because "File Exit" was called?). Immediately after that a "loadComponent" call shall be executed, but that is the *real* problem: it should be rejected. Obviously there is no control over the framework code that prevents this (or OTOH stops the shutdown, what would be an option too). Do you know, what causes the "loadComponent" request after "Quit"? It's pretty obvious that there is a bug, but I'd like to see where. The patch in SfxApplication::Deinitialize_Impl() seems to be a last resort, first I'd like to have a deeper investigation. Andreas Bille already played around with the VFS-UCP. I hope that he can reproduce the problem.
Sorry, but we couldn't reproduce the problem. I apply the patch anyway, it shouldn't create a problem.
I applied the patch (only for one pointer, the other two have been removed anyway). I'm still interested in looking into the real problem instead of just fixing the symptom. Maybe we can investigate that later.
This issue wasn't reproducable here, so applying the patch is all we can do. Setting the pointer to a deleted object to "0" is correct and so can't do any harm