Description: Version: 6.4.7.2, Mac OS 10.13.6, can be reproduced EXPORTING Steps to Reproduce: 1.Open LO Spreadsheet File 2.Choose Export from File-Menu 3.Choose MS Excel 2003 XML (xml;xls) as export format 4.Crash Actual Results: as described above, crash can be reproduced Expected Results: Crash Reproducible: Always User Profile Reset: No Additional Info: First 40 lines of Crash report: Path: /Applications/LibreOffice.app/Contents/MacOS/soffice Identifier: soffice Version: 6.4.7002 (6.4.7002) Code Type: X86-64 (Native) Parent Process: ??? [1] Responsible: soffice [2417] User ID: 501 Date/Time: 2021-04-01 11:25:48.716 +0200 OS Version: Mac OS X 10.13.6 (17G14042) Report Version: 12 Anonymous UUID: F4CB1DBD-95CF-8A8C-0B14-88B3C205CD95 Time Awake Since Boot: 8800 seconds System Integrity Protection: enabled Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_CRASH (SIGILL) Exception Codes: 0x0000000000000000, 0x0000000000000000 Exception Note: EXC_CORPSE_NOTIFY Termination Signal: Illegal instruction: 4 Termination Reason: Namespace SIGNAL, Code 0x4 Terminating Process: soffice [2417] Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x00007fff64084a16 __psynch_cvwait + 10 1 libsystem_pthread.dylib 0x00007fff6424d589 _pthread_cond_wait + 732 2 libuno_sal.dylib.3 0x0000000108286651 osl_waitCondition + 225 3 libxsltfilterlo.dylib 0x000000014249f55f XSLT::XSLTFilter::endDocument() + 31 4 libxolo.dylib 0x000000010e40b19d SvXMLExport::exportDoc(xmloff::token::XMLTokenEnum) + 3005 5 libsclo.dylib 0x000000013dcd5432 ScXMLExport::exportDoc(xmloff::token::XMLTokenEnum) + 754 6 libxolo.dylib 0x000000010e406e76 SvXMLExport::filter(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) + 374 7 libsclo.dylib 0x000000013dcd5836 ScXMLExport::filter(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) + 70 8 libxmlfalo.dylib 0x0000000142011a1c XmlFilterAdaptor::exportImpl(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) + 2924 9 libxmlfalo.dylib 0x0000000142012133 non-virtual thunk to XmlFilterAdaptor::filter(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) + 19 10 libsfxlo.dylib 0x0000000108ddd0bd SfxObjectShell::ExportTo(SfxMedium&) + 3341 11 libsfxlo.dylib 0x0000000108dd9297 SfxObjectShell::SaveTo_Impl(SfxMedium&, SfxItemSet const*) + 3431 12 libsfxlo.dylib 0x0000000108de24d1 SfxObjectShell::PreDoSaveAs_Impl(rtl::OUString const&, rtl::OUString const&, SfxItemSet const&) + 945 13 libsfxlo.dylib 0x0000000108de1c77 SfxObjectShell::CommonSaveAs_Impl(INetURLObject const&, rtl::OUString const&, SfxItemSet&) + 1927 14 libsfxlo.dylib 0x0000000108dce9e4 SfxObjectShell::APISaveAs_Impl(rtl::OUString const&, SfxItemSet&) + 628 15 libsfxlo.dylib 0x0000000108e02802 SfxBaseModel::impl_store(rtl::OUString const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&, bool) + 2130 16 libsfxlo.dylib 0x0000000108e04b80 SfxBaseModel::storeToURL(rtl::OUString const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) + 528 17 libsfxlo.dylib 0x0000000108db1c3e SfxStoringHelper::GUIStoreModel(com::sun::star::uno::Reference<com::sun::star::frame::XModel> const&, rtl::OUString const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue>&, bool, SignatureState) + 6558 18 libsfxlo.dylib 0x0000000108dc9385 SfxObjectShell::ExecFile_Impl(SfxRequest&) + 10789 19 libsfxlo.dylib 0x0000000108c5a367 SfxDispatcher::Call_Impl(SfxShell&, SfxSlot const&, SfxRequest&, bool) + 631 20 libsfxlo.dylib 0x0000000108c56172 SfxBindings::Execute_Impl(SfxRequest&, SfxSlot const*, SfxShell*) + 578 21 libsfxlo.dylib 0x0000000108cac340 SfxDispatchController_Impl::dispatch(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&) + 4544 22 libsfxlo.dylib 0x0000000108caae6f SfxOfficeDispatch::dispatch(com::sun::star::util::URL const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) + 79 23 libfwklo.dylib 0x000000013aea0128 framework::MenuBarManager::Select(Menu*) + 1496 24 libfwklo.dylib 0x000000013ae9fb49 framework::MenuBarManager::LinkStubSelect(void*, Menu*) + 9 25 libvcllo.dylib 0x000000010ab99975 Menu::Select() + 165 26 libvcllo.dylib 0x000000010ac115f2 ImplWindowFrameProc(vcl::Window*, SalEvent, void const*) + 2642 27 libvclplug_osxlo.dylib 0x000000010f0d8707 non-virtual thunk to AquaSalInstance::ProcessEvent(SalUserEventList::SalUserEvent) + 39 28 libvcllo.dylib 0x000000010aed7162 SalUserEventList::DispatchUserEvents(bool) + 866 29 libvclplug_osxlo.dylib 0x000000010f0d8d12 AquaSalInstance::DoYield(bool, bool) + 82 30 libvcllo.dylib 0x000000010af12f5e Application::Execute() + 334 31 libsofficeapp.dylib 0x00000001082cf0e1 desktop::Desktop::Main() + 3473 32 libvcllo.dylib 0x000000010af197bb ImplSVMain() + 139 33 libvclplug_osxlo.dylib 0x000000010f0d879b AquaSalInstance::handleAppDefinedEvent(NSEvent*) + 91 34 libvclplug_osxlo.dylib 0x000000010f10ebfd -[VCL_NSApplication sendEvent:] + 77 35 com.apple.AppKit 0x00007fff394bd87d -[NSApplication run] + 812 36 com.apple.AppKit 0x00007fff3948ca3a NSApplicationMain + 804 37 libvclplug_osxlo.dylib 0x000000010f0da8d9 AquaSalInstance::SVMainHook(int*) + 169 38 libvcllo.dylib 0x000000010af1979d ImplSVMain() + 109 39 libsofficeapp.dylib 0x00000001082fc488 soffice_main + 248 40 org.libreoffice.script 0x0000000108256f60 main + 16 41 libdyld.dylib 0x00007fff63f34015 start + 1
Thank you for reporting the bug. To be certain the reported issue is not related to corruption in the user profile, could you please reset your Libreoffice profile ( https://wiki.documentfoundation.org/UserProfile ) and re-test? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the issue is still present
As recommended, I have restarted LO in save mode. The bug persists, LO crashes instantly when trying to export a Calc-file to Exel 2003 XML
no repro in Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 78c33a4c3d1633b97049874305b3b49b820395a2 CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: threaded
Hello Emanuel, Could you please try to reproduce it with version 7.1.3.2 of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
Created attachment 171834 [details] crash report export LO spreadsheet to Excel 2003
bug persists in LO 7.1.3.2
no repro in Version: 7.3.0.0.alpha0+ / LibreOffice Community Build ID: 9c15dea0b2192d231b65175291a7655122c2e24c CPU threads: 4; OS: Mac OS X 10.16; UI render: default; VCL: osx Locale: ru-RU (ru_RU.UTF-8); UI: en-US Calc: threaded can you attach your file that you tried to export?
Created attachment 173777 [details] To reproduce excel export crash
Hi there, I have the same problem than Emmanuel has. Same OS. Almost same LibreOffice version. I just attached a file to reproduce the crash. Version: 7.1.4.2 / LibreOffice Community Build ID: a529a4fab45b75fefc5b6226684193eb000654f6 CPU threads: 12; OS: Mac OS X 10.14.6; UI render: default; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: en-US Calc: threaded
(In reply to julien+bugzilla from comment #9) > Hi there, > I have the same problem than Emmanuel has. > Same OS. Almost same LibreOffice version. > > I just attached a file to reproduce the crash. > > Version: 7.1.4.2 / LibreOffice Community > Build ID: a529a4fab45b75fefc5b6226684193eb000654f6 > CPU threads: 12; OS: Mac OS X 10.14.6; UI render: default; VCL: osx > Locale: fr-FR (fr_FR.UTF-8); UI: en-US > Calc: threaded Still no repro in Windows Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 0d4cbdbc9cd4ab06056cec66cffd292b41615b6e CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: threaded I'll try on macOS later
So, I rerpo crash finally with example from attach in Version: 7.1.3.1 / LibreOffice Community Build ID: fa76d07d7006a0e2866c3247cef2d5eb55ae8369 CPU threads: 4; OS: Mac OS X 10.16; UI render: GL; VCL: osx Locale: ru-RU (ru_RU.UTF-8); UI: en-US Calc: threaded and in Version: 7.3.0.0.alpha0+ / LibreOffice Community Build ID: 9c15dea0b2192d231b65175291a7655122c2e24c CPU threads: 4; OS: Mac OS X 10.16; UI render: default; VCL: osx Locale: ru-RU (ru_RU.UTF-8); UI: en-US Calc: threaded
Created attachment 173825 [details] Crash report by macOS
reproducible in 7.3.5 and master (apple silicon) libxslt goes into deep recursion that ultimately causes error on stack allocation(?). No difference between system libxml/libxslt and self-built version (macOS Monterey) Wonder why there is a platform difference/why the same crash doesn't occur on linux... Roman's crash is on intel, so not arm specific...
changing sal/osl/unx/thread.cxx and flip the ENABLE_RUNTIME_OPTIMIZATIONS condition (the build by default is configured with YES) to use the custom stacksize fixes the problem/allows the export to succeed.
https://developer.apple.com/library/archive/qa/qa1419/_index.html : only main thread gets 8MB stack, other threads only get 512kB (confirmed by querying in code, still true for current macOS) 1MB stacksize is already enough (640kB would be enough for this export, 576kB would still be too little)
Christian Lohmaier committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/1844326df477eb379f281e6f027fc8e6475f28bf tdf#141421 xml export: default stacksize for threads on macOS is too small It will be available in 7.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Christian Lohmaier committed a patch related to this issue. It has been pushed to "libreoffice-7-4": https://git.libreoffice.org/core/commit/13d08e0fbe644ed2ebf1e21a68456313939f475f tdf#141421 xml export: default stacksize for threads on macOS is too small It will be available in 7.4.0.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Christian Lohmaier committed a patch related to this issue. It has been pushed to "libreoffice-7-3": https://git.libreoffice.org/core/commit/ec8485dec71fe27908f25eaa3186af2d17215b64 tdf#141421 xml export: default stacksize for threads on macOS is too small It will be available in 7.3.6. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Clop, can this be considered fixed, or is something still left to do?
from my POV it is fixed, I can not produce it anymore :-) Feel free to reopen in case there still is a problem, but likely would need a different sample document/or is not the same cause as this one...
*** Bug 139073 has been marked as a duplicate of this bug. ***