Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | Crash on exit | ||
---|---|---|---|
Product: | General | Reporter: | pavel |
Component: | code | Assignee: | oc |
Status: | CLOSED FIXED | QA Contact: | issues@framework <issues> |
Severity: | Trivial | ||
Priority: | P2 | CC: | carsten.driesner, issues, mdxonefour, stephan.bergmann.secondary |
Version: | OOO330m14 | ||
Target Milestone: | OOo 3.3 | ||
Hardware: | All | ||
OS: | Mac OS X 10 | ||
Issue Type: | DEFECT | Latest Confirmation in: | --- |
Developer Difficulty: | --- | ||
Issue Depends on: | |||
Issue Blocks: | 111112 |
Description
pavel
2010-11-10 11:13:54 UTC
@pjanik: An unstripped build (configure --disable-strip, IIRC) would probably help show more precisely what goes wrong. @mav: Please have a look (libpackage2.dylib). Another one (in the meantime, I built sal with debug): Date/Time: 2010-11-10 13:40:00.440 +0100 OS Version: 10.4.11 (Build 8S2167) Report Version: 4 Command: soffice Path: /Users/pavel/Desktop/OpenOffice.org.app/Contents/MacOS/soffice Parent: WindowServer [61] Version: 3.3.0 (???) PID: 8587 Thread: 0 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x0000003d Thread 0 Crashed: Thread 0 Crashed: 0 libuno_sal.dylib.3 0x002423e0 _gnu_cxx::hashtable<_rtl_uString*, _rtl_uString*, (anonymous namespace)::UStringHash, std::_Identity<_rtl_uString*>, (anonymous namespace)::UStringEqual, rtl::Allocator<_rtl_uString*> >::erase(_rtl_uString* const&) + 86 1 libuno_sal.dylib.3 0x00221c6a rtl_str_hash_remove + 26 2 libuno_sal.dylib.3 0x002254e6 internRelease + 55 3 libpackage2.dylib 0x25317d6c 0x252d2000 + 286060 4 libpackage2.dylib 0x252d6a46 0x252d2000 + 19014 5 libpackage2.dylib 0x25303f53 0x252d2000 + 204627 6 libpackage2.dylib 0x25304120 0x252d2000 + 205088 7 libvclmxi.dylib 0x028ac1e4 std::_List_base<std::pair<rtl::OUString, com::sun::star::uno::Reference<com::sun::star::container::XNameAccess> >, std::allocator<std::pair<rtl::OUString, com::sun::star::uno::Reference<com::sun::star::container::XNameAccess> > > >::_M_clear() + 38 8 libvclmxi.dylib 0x0265d4c2 ImplImageTree::~ImplImageTree [in-charge]() + 124 9 libvclmxi.dylib 0x025ac62b AllSettings::GetLayoutRTL() const + 965 10 libvclmxi.dylib 0x025a64e9 0x25a4000 + 9449 11 libSystem.B.dylib 0x9000ff21 __cxa_finalize + 226 @pjanik: Thank you for the stacks. It would be interesting what goes wrong in the package component ( package module ). Could you please build it with debug and provide a stack with the info. Thanks in advance. OK, here we go: Date/Time: 2010-11-10 15:31:32.029 +0100 OS Version: 10.4.11 (Build 8S2167) Report Version: 4 Command: soffice Path: /Users/pavel/Desktop/OpenOffice.org.app/Contents/MacOS/soffice Parent: WindowServer [61] Version: 3.3.0 (???) PID: 9116 Thread: 0 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x0000003d Thread 0 Crashed: 0 libuno_sal.dylib.3 0x002423e0 _gnu_cxx::hashtable<_rtl_uString*, _rtl_uString*, (anonymous namespace)::UStringHash, std::_Identity<_rtl_uString*>, (anonymous namespace)::UStringEqual, rtl::Allocator<_rtl_uString*> >::erase(_rtl_uString* const&) + 86 1 libuno_sal.dylib.3 0x00221c6a rtl_str_hash_remove + 26 2 libuno_sal.dylib.3 0x002254e6 internRelease + 55 3 libpackage2.dylib 0x2531cf18 _gnu_cxx::hashtable<std::pair<rtl::OUString const, ZipEntry>, rtl::OUString, rtl::OUStringHash, std::_Select1st<std::pair<rtl::OUString const, ZipEntry> >, eqFunc, std::allocator<ZipEntry> >::clear() + 90 4 libpackage2.dylib 0x252d7604 ZipFile::~ZipFile [in-charge]() + 22 5 libpackage2.dylib 0x25308177 OZipFileAccess::dispose() + 163 6 libpackage2.dylib 0x25308344 OZipFileAccess::~OZipFileAccess [in-charge deleting]() + 116 7 libvclmxi.dylib 0x028ac1e4 std::_List_base<std::pair<rtl::OUString, com::sun::star::uno::Reference<com::sun::star::container::XNameAccess> >, std::allocator<std::pair<rtl::OUString, com::sun::star::uno::Reference<com::sun::star::container::XNameAccess> > > >::_M_clear() + 38 8 libvclmxi.dylib 0x0265d4c2 ImplImageTree::~ImplImageTree [in-charge]() + 124 9 libvclmxi.dylib 0x025ac62b AllSettings::GetLayoutRTL() const + 965 10 libvclmxi.dylib 0x025a64e9 0x25a4000 + 9449 11 libSystem.B.dylib 0x9000ff21 __cxa_finalize + 226 12 libSystem.B.dylib 0x9000fe28 exit + 24 13 com.apple.AppKit 0x9342dd1a -[NSApplication terminate:] + 683 14 com.apple.AppKit 0x933947cc -[NSApplication sendAction:to:from:] + 107 15 com.apple.AppKit 0x9344268b -[NSMenu performActionForItemAtIndex:] + 455 16 com.apple.AppKit 0x934423cd -[NSCarbonMenuImpl performActionWithHighlightingForItemAtIndex:] + 103 17 com.apple.AppKit 0x93442024 -[NSMenu performKeyEquivalent:] + 766 18 libvclmxi.dylib 0x0283e6ae SalData::~SalData [not-in-charge]() + 3052 19 libvclmxi.dylib 0x0283b523 AquaSalInstance::Yield(bool, bool) + 1287 20 libvclmxi.dylib 0x025b081c Application::Yield(bool) + 86 21 libvclmxi.dylib 0x025b08f6 Application::Execute() + 84 22 libsofficeapp.dylib 0x00415811 0x3fe000 + 96273 23 libvclmxi.dylib 0x025b6795 ImplSVMain() + 373 24 libvclmxi.dylib 0x0283aacc AquaSalInstance::handleAppDefinedEvent(NSEvent*) + 82 25 libvclmxi.dylib 0x0283e44e SalData::~SalData [not-in-charge]() + 2444 26 com.apple.AppKit 0x932a08e7 -[NSApplication run] + 547 27 com.apple.AppKit 0x93294820 NSApplicationMain + 573 28 libvclmxi.dylib 0x0283b8b0 ImplSVMainHook(unsigned char*) + 342 29 libvclmxi.dylib 0x025b6821 SVMain() + 17 30 libsofficeapp.dylib 0x00433158 soffice_main + 160 31 org.openoffice.script 0x00001f0e main + 30 32 org.openoffice.script 0x0000187e start + 258 33 org.openoffice.script 0x000017a5 start + 41 Ok, I can now reproduce. Open some .doc file by clicking on it in Finder and Apple+Q (Quit) very soon after the document is displayed, but the cursor is not yet shown, ie. very fast once you see the contents of the document. Easier to reproduce on 3 page document than on one page. Due to stripped VCL, it is still not clear exactly which static VCL object is destroyed, but it looks like that static object is destroyed "too late," after the static StringHashTable in getHashTable() at sal/rtl/source/hash.cxx l. 68 has already been destroyed. Best fix would probably be to let getHashTable() leak the StringHashTable instance. Now with libvcl: Date/Time: 2010-11-10 16:36:26.043 +0100 OS Version: 10.4.11 (Build 8S2167) Report Version: 4 Command: soffice Path: /Users/pavel/Desktop/OpenOffice.org.app/Contents/MacOS/soffice Parent: WindowServer [61] Version: 3.3.0 (???) PID: 21157 Thread: 0 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x0000003d Thread 0 Crashed: 0 libuno_sal.dylib.3 0x002423e0 _gnu_cxx::hashtable<_rtl_uString*, _rtl_uString*, (anonymous namespace)::UStringHash, std::_Identity<_rtl_uString*>, (anonymous namespace)::UStringEqual, rtl::Allocator<_rtl_uString*> >::erase(_rtl_uString* const&) + 86 1 libuno_sal.dylib.3 0x00221c6a rtl_str_hash_remove + 26 2 libuno_sal.dylib.3 0x002254e6 internRelease + 55 3 libpackage2.dylib 0x25305f18 _gnu_cxx::hashtable<std::pair<rtl::OUString const, ZipEntry>, rtl::OUString, rtl::OUStringHash, std::_Select1st<std::pair<rtl::OUString const, ZipEntry> >, eqFunc, std::allocator<ZipEntry> >::clear() + 90 4 libpackage2.dylib 0x252c0604 ZipFile::~ZipFile [in-charge]() + 22 5 libpackage2.dylib 0x252f1177 OZipFileAccess::dispose() + 163 6 libpackage2.dylib 0x252f1344 OZipFileAccess::~OZipFileAccess [in-charge deleting]() + 116 7 libvclmxi.dylib 0x028b6c62 std::_List_base<std::pair<rtl::OUString, com::sun::star::uno::Reference<com::sun::star::container::XNameAccess> >, std::allocator<std::pair<rtl::OUString, com::sun::star::uno::Reference<com::sun::star::container::XNameAccess> > > >::_M_clear() + 38 8 libvclmxi.dylib 0x0265ff74 ImplImageTree::~ImplImageTree [in-charge]() + 124 9 libvclmxi.dylib 0x025ac3ab __tcf_0 + 73 10 libvclmxi.dylib 0x025a6269 cxa_atexit_wrapper + 115 11 libSystem.B.dylib 0x9000ff21 __cxa_finalize + 226 12 libSystem.B.dylib 0x9000fe28 exit + 24 13 com.apple.AppKit 0x9342dd1a -[NSApplication terminate:] + 683 14 com.apple.AppKit 0x933947cc -[NSApplication sendAction:to:from:] + 107 15 com.apple.AppKit 0x9344268b -[NSMenu performActionForItemAtIndex:] + 455 16 com.apple.AppKit 0x934423cd -[NSCarbonMenuImpl performActionWithHighlightingForItemAtIndex:] + 103 17 com.apple.AppKit 0x93442024 -[NSMenu performKeyEquivalent:] + 766 18 libvclmxi.dylib 0x02846d4c -[VCL_NSApplication sendEvent:] + 898 19 libvclmxi.dylib 0x0284382b AquaSalInstance::Yield(bool, bool) + 1287 20 libvclmxi.dylib 0x025b0636 Application::Yield(bool) + 86 21 libvclmxi.dylib 0x025b0710 Application::Execute() + 84 22 libsofficeapp.dylib 0x00415811 0x3fe000 + 96273 23 libvclmxi.dylib 0x025b6cf3 ImplSVMain() + 373 24 libvclmxi.dylib 0x02842dd4 AquaSalInstance::handleAppDefinedEvent(NSEvent*) + 82 25 libvclmxi.dylib 0x02846aec -[VCL_NSApplication sendEvent:] + 290 26 com.apple.AppKit 0x932a08e7 -[NSApplication run] + 547 27 com.apple.AppKit 0x93294820 NSApplicationMain + 573 28 libvclmxi.dylib 0x02843bb8 ImplSVMainHook(unsigned char*) + 342 29 libvclmxi.dylib 0x025b6d7f SVMain() + 17 30 libsofficeapp.dylib 0x00433158 soffice_main + 160 31 org.openoffice.script 0x00001f0e main + 30 32 org.openoffice.script 0x0000187e start + 258 33 org.openoffice.script 0x000017a5 start + 41 @pl: Ah, the ImplImageTreeSingletonRef instance is the problem. As ImplImageTree::shutDown() is already documented as "a crude form of life cycle control (called from DeInitVCL; otherwise, if the ImplImageTree singleton were destroyed during exit that would be too late for the destructors of the bitmaps in m_iconCache)," the best fix after all might be to fix the Mac-specific exit via Desktop::QueryExit (see issue 114937) to call ImplImageTree::shutDown. I could call DeInitVCL I guess, I'm just not sure that's good enough. Especially this might pull objects out from under static objects in layers above vcl, since now the order of destruction of global instances would be different. tentative target With the latest 3.3 RC build I'm getting this crash often but not reproducible :( No Crash Reporter is showing up. actually you don't but a different stacktrace. Anyway the workaround sb suggested would be completely harmless and could well go into 3.3. committed the workaround "ImplImageTree::shutdown" plus the other crash fix in CWS calc63 For 3.4 I should do some better way for cleanup together with cd in issue 114937 please verify in CWS calc63 steps to reproduce: - open calc - enter content in a cell - copy cell - Cmd-Q (or select OOo->Quit) -> crash (quite reliably) checked with install set from CWS calc63. Issue is fixed now. I can't see this crash on exit anymore. marking issue as "verified" |