Created attachment 63978 [details] When the file crash.xml.xls is open with LibreOffice, LibreOffice crashes # Problem description: LibreOffice crashes opening 5000-line manually created MS Excel 2003 XML file. # Steps to reproduce: 1. Unzip and open the attached zipped text file with LibreOffice. # Current behavior: Loading indicator hags on 1/3, and LibreOffice quit unexpectedly. # Expected behavior: Should open the file. In fact, if half of the (identical) lines is removed from the file, LibreOffice opens it fine. # Platform (if different from the browser): Browser: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/534.57.2 (KHTML, like Gecko) Version/5.1.7 Safari/534.57.2
Alexey, attached spreadsheet seems to be empty (opens fine in 3.5.3 and 3.6beta2 on linux). Are you sure that you zipped the right file?
Valek, yes, it is empty, i have removed all data from the cells with a text editor. Still it crashes my LibreOffice. Does it work for you? Alexey.
So, if i understood correctly, it works on Ubuntu with 3.5.3. I will attach my Mac OS crash report, it starts with: =============================== Process: soffice [762] Path: /Applications/Custom/LibreOffice.app/Contents/MacOS/soffice Identifier: org.libreoffice.script Version: 3.5.4 (???) Code Type: X86 (Native) Parent Process: launchd [496] Date/Time: 2012-07-09 10:21:43.560 +0200 OS Version: Mac OS X 10.6.8 (10K549) Report Version: 6 Interval Since Last Report: 6062 sec Crashes Since Last Report: 14 Per-App Interval Since Last Report: 773 sec Per-App Crashes Since Last Report: 13 Anonymous UUID: CC406DD9-1931-4D21-B2DC-0729EEE32A1E Exception Type: EXC_BAD_ACCESS (SIGBUS) Exception Codes: KERN_PROTECTION_FAILURE at 0x00000000b05caeec Crashed Thread: 7 Thread 0: Dispatch queue: com.apple.main-thread 0 libSystem.B.dylib 0x94ab2b5a semaphore_timedwait_signal_trap + 10 1 libSystem.B.dylib 0x94ae06e1 _pthread_cond_wait + 1066 2 libSystem.B.dylib 0x94b2926c pthread_cond_timedwait + 47 3 libuno_sal.dylib.3 0x000091c9 osl_waitCondition + 281 4 libxsltfilterlo.dylib 0x1fc4d310 XSLT::XSLTFilter::importer(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&, com::sun::star::uno::Reference<com::sun::star::xml::sax::XDocumentHandler> const&, com::sun::star::uno::Sequence<rtl::OUString> const&) + 3824 5 libxmlfalo.dylib 0x1fb8850f XmlFilterAdaptor::importImpl(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) + 2783 6 libxmlfalo.dylib 0x1fb8ae4e XmlFilterAdaptor::filter(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) + 30 7 libsfxlo.dylib 0x005dac53 SfxObjectShell::ImportFrom(SfxMedium&, bool) + 3139 8 libsfxlo.dylib 0x005dd142 SfxObjectShell::DoLoad(SfxMedium*) + 3698 9 libsfxlo.dylib 0x00621871 SfxBaseModel::load(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) + 385 10 libsfxlo.dylib 0x0066c2fc SfxFrameLoader_Impl::load(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&, com::sun::star::uno::Reference<com::sun::star::frame::XFrame> const&) + 4060 11 libfwklo.dylib 0x198199dd framework::LoadEnv::impl_loadContent() + 3533 12 libfwklo.dylib 0x19819e38 framework::LoadEnv::startLoading() + 136 13 libfwklo.dylib 0x1979aa24 framework::LoadDispatcher::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&) + 436 14 libfwklo.dylib 0x1979b185 framework::LoadDispatcher::dispatchWithReturnValue(com::sun::star::util::URL const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) + 53 15 libcomphelpgcc3.dylib 0x0017cb9c comphelper::SynchronousDispatch::dispatch(com::sun::star::uno::Reference<com::sun::star::uno::XInterface> const&, rtl::OUString const&, rtl::OUString const&, long, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) + 1452 16 libsofficeapp.dylib 0x0008626f desktop::DispatchWatcher::executeDispatchRequests(std::vector<desktop::DispatchWatcher::DispatchRequest, std::allocator<desktop::DispatchWatcher::DispatchRequest> > const&, bool) + 13807 17 libsofficeapp.dylib 0x00092760 desktop::OfficeIPCThread::ExecuteCmdLineRequests(desktop::ProcessDocumentsRequest&) + 1184 18 libsofficeapp.dylib 0x00071086 desktop::Desktop::HandleAppEvent(ApplicationEvent const&) + 1478 19 libvcllo.dylib 0x018f94a3 AquaSalInstance::Yield(bool, bool) + 1011 20 libvcllo.dylib 0x01621000 Application::Yield(bool) + 96 21 libvcllo.dylib 0x016210ec Application::Execute() + 76 22 libsofficeapp.dylib 0x0006bd5d desktop::Desktop::Main() + 6317 23 libvcllo.dylib 0x01628cb8 ImplSVMain() + 376 24 libvcllo.dylib 0x018f81bb AquaSalInstance::handleAppDefinedEvent(NSEvent*) + 75 25 libvcllo.dylib 0x0193c4eb -[VCL_NSApplication sendEvent:] + 315 26 com.apple.AppKit 0x94ff9253 -[NSApplication run] + 917 27 com.apple.AppKit 0x94ff1289 NSApplicationMain + 574 28 libvcllo.dylib 0x018f9b67 ImplSVMainHook(int*) + 343 29 libvcllo.dylib 0x01628d61 SVMain() + 17 30 libsofficeapp.dylib 0x00095575 soffice_main + 245 31 org.libreoffice.script 0x00001f0e main + 30 32 org.libreoffice.script 0x00001872 _start + 216 33 org.libreoffice.script 0x00001799 start + 41 Thread 1: 0 libSystem.B.dylib 0x94ab2b5a semaphore_timedwait_signal_trap + 10 1 libSystem.B.dylib 0x94ae06e1 _pthread_cond_wait + 1066 2 libSystem.B.dylib 0x94b2926c pthread_cond_timedwait + 47 3 libuno_sal.dylib.3 0x00036578 rtl_cache_create + 696 4 libSystem.B.dylib 0x94ae0259 _pthread_start + 345 5 libSystem.B.dylib 0x94ae00de thread_start + 34 Thread 2: Dispatch queue: com.apple.libdispatch-manager 0 libSystem.B.dylib 0x94ad9382 kevent + 10 1 libSystem.B.dylib 0x94ad9a9c _dispatch_mgr_invoke + 215 2 libSystem.B.dylib 0x94ad8f59 _dispatch_queue_invoke + 163 3 libSystem.B.dylib 0x94ad8cfe _dispatch_worker_thread2 + 240 4 libSystem.B.dylib 0x94ad8781 _pthread_wqthread + 390 5 libSystem.B.dylib 0x94ad85c6 start_wqthread + 30 Thread 3: 0 libSystem.B.dylib 0x94ad8412 __workq_kernreturn + 10 1 libSystem.B.dylib 0x94ad89a8 _pthread_wqthread + 941 2 libSystem.B.dylib 0x94ad85c6 start_wqthread + 30 Thread 4: 0 libSystem.B.dylib 0x94b7a096 accept$NOCANCEL$UNIX2003 + 10 1 libSystem.B.dylib 0x94b78eff accept + 32 2 libuno_sal.dylib.3 0x0001280a osl_acceptPipe + 58 3 libsofficeapp.dylib 0x00092ede desktop::OfficeIPCThread::run() + 46 4 libsofficeapp.dylib 0x00094282 threadFunc + 18 5 libuno_sal.dylib.3 0x0000caa9 osl_setThreadName + 569 6 libSystem.B.dylib 0x94ae0259 _pthread_start + 345 7 libSystem.B.dylib 0x94ae00de thread_start + 34 Thread 5: 0 libSystem.B.dylib 0x94ab2b5a semaphore_timedwait_signal_trap + 10 1 libSystem.B.dylib 0x94ae06e1 _pthread_cond_wait + 1066 2 libSystem.B.dylib 0x94b2926c pthread_cond_timedwait + 47 3 libuno_sal.dylib.3 0x000091c9 osl_waitCondition + 281 4 updchk.uno.dylib 0x1fbc3a31 component_getFactory + 881 5 updchk.uno.dylib 0x1fbc17b2 0x1fbb7000 + 42930 6 libuno_sal.dylib.3 0x0000caa9 osl_setThreadName + 569 7 libSystem.B.dylib 0x94ae0259 _pthread_start + 345 8 libSystem.B.dylib 0x94ae00de thread_start + 34 Thread 6: 0 libSystem.B.dylib 0x94ab2b5a semaphore_timedwait_signal_trap + 10 1 libSystem.B.dylib 0x94ae06e1 _pthread_cond_wait + 1066 2 libSystem.B.dylib 0x94b2926c pthread_cond_timedwait + 47 3 libuno_sal.dylib.3 0x000091c9 osl_waitCondition + 281 4 libfwklo.dylib 0x197bb6b0 framework::WakeUpThread::run() + 96 5 libsofficeapp.dylib 0x00094282 threadFunc + 18 6 libuno_sal.dylib.3 0x0000caa9 osl_setThreadName + 569 7 libSystem.B.dylib 0x94ae0259 _pthread_start + 345 8 libSystem.B.dylib 0x94ae00de thread_start + 34 Thread 7 Crashed: 0 libSystem.B.dylib 0x94abec86 __vfprintf + 12 1 libSystem.B.dylib 0x94ac7bc5 snprintf + 377 2 libxml2.2.dylib 0x91613298 xmlXPathCastNumberToString + 597 3 libxml2.2.dylib 0x91616339 xmlXPathWrapCString + 242 4 libxml2.2.dylib 0x91616426 xmlXPathStringFunction + 101 5 libxml2.2.dylib 0x91616480 xmlXPathConcatFunction + 68 6 libxml2.2.dylib 0x9161efc8 xmlXPathRoot + 5909 ...
Created attachment 64008 [details] Mac OS crash report for LibreOffice
On pc Debian x86-64, with master sources updated today, I had no crash but these logs : warn:legacy.osl:6571:1:/home/julien/compile-libreoffice/libo/sc/source/filter/xml/XMLStylesImportHelper.cxx:447: something wents wrong warn:legacy.osl:6571:1:/home/julien/compile-libreoffice/libo/sc/source/filter/xml/XMLStylesImportHelper.cxx:358: to much columns (the typo is fixed now on master :-))
REPRODUCIBLE on MacOS X 10.6.8 (Intel) German UI with * LibreOffice 3.5.4.2, Build-ID: 165a79a-7059095-e13bb37-fef39a4-9503d18 * LibreOffice 3.6.0.0.beta3 (Build ID: 3e2b862) When I try to open Alexey's sample file ("crash.xml.xls") with these LibreOffice versions, LibreOffice takes a long time to open the file and crashes while still in progress of opening the file, before opening a document window. Additionally, on MacOS X 10.6.8 (Intel) German UI with * LibreOffice 3.4.0, OOO340m1 (Build:12) * LibreOffice 3.4.6, OOO340m1 (Build:602) just report a "General input/output error." when I try to open the file. However, Apache OpenOffice (AOO) 3.4.0 on the same machine opens the file without problems (but it takes a long time!). The log files generated by MacOS X 10.6.8 for the crash with LibreOffice 3.5.4.2 and 3.6.0.0.beta3 both look just like Alexey's crash report, but I will attach the crash log file for 3.6.0.0.beta3 for the sake of confirmation and completeness. NB: Changing the file name (e.g., to "crash.xml") does not change the situation.
Created attachment 64061 [details] MacOS X log file created for the crash with LibreOffie 3.6 beta 3
Looks like this is a file size/row count problem: if I delete almost all rows from the file, so that there are only three rows (with 5 cells each) left, LibreOffice 3.6.0.0.beta3 (Build ID: 3e2b862) opens the file without any problems. And all the rows are identical (empty), of course, no strange invalid UTF-8 characters or something similar (I have checked with a text editor). But I don't understand why this file is so "big" that this should cause any problems for LibreOffice: there are only 710 rows with 5 cells each. This is much for a human being but should be easy to handle for a modern computer application ;-) At least, there should not be any crash.
Hello Kohei, hello Markus, hello Thorsten, I have added your e-mail address to the CC list of this bug report because you are our Calc (Kohei, Markus) or Mac (Thorsten) experts, and this is a (appearently) MacOS-only Calc issue. But even if it is confined to a single platform, the bug is still of some importance because it leads to a crash and it is hard to say why LibreOffice crashes on this big, but very simple file (AOO does NOT crash, but opens the file without problems!). So it would be very nice if you could take a look at this issue. Thank you very much in advance!
I had the same issue and when I was going to open a new case I have seen that it is already openend here. I have put in dropbox two examples, One that open because it is a small file: http://dl.dropbox.com/u/30880870/prueba.xls One that won't open becuase it is big: http://dl.dropbox.com/u/30880870/prueba2.xls I have tested with the same behaviour in XP and W7. and in LibreOffice 3.5 and 3.6.0.4
*** This bug has been marked as a duplicate of bug 44969 ***