Bug 78949 - FILEOPEN: terminating with unexpected exception of type com::sun::star::xml::sax::SAXParseException
Summary: FILEOPEN: terminating with unexpected exception of type com::sun::star::xml::...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.2.4.2 release
Hardware: Other macOS (All)
: medium normal
Assignee: Stephan Bergmann
URL:
Whiteboard: BSA target:4.3.0 target:4.2.5
Keywords:
Depends on:
Blocks:
 
Reported: 2014-05-20 07:35 UTC by Christian Kujau
Modified: 2014-05-21 07:21 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
backtrace from the "send to apple" window (68.55 KB, text/plain)
2014-05-20 07:35 UTC, Christian Kujau
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Christian Kujau 2014-05-20 07:35:09 UTC
Created attachment 99392 [details]
backtrace from the "send to apple" window

Problem description: LibreOffice crashes when I try to open a certain .xlsx file.

Note: Unfortunately, I won't be able to share the file as it contains sensitive information. I have not created the file myself, but I can open it in e.g. LibreOffice on Linux just fine. Without any modification done I can save the same file as .xlsx again and transfer the file to the MacOS machine, but then the file open just fine. I suspect the file was created by some MS Office installation and something in that file makes LibreOffice crash.

Steps to reproduce:
1. open file.x
2. LibreOffice crashes
3. The "Send to Apple" report window opens

Current behavior:

LibreOffice crashes

Expected behavior:

LibreOffice should not crash :-)
Operating System: Mac OS X
Version: 4.2.4.2 release
Comment 1 Commit Notification 2014-05-20 09:18:41 UTC
Stephan Bergmann committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=423921b085de43f53e42f957889dd96378d2c3c4

fdo#78949 Handle (SAXParse-)Exception that can't pass getAllRelationships



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 2 Stephan Bergmann 2014-05-20 09:40:00 UTC
requested backport to libreoffice-4-2 towards LO 4.2.5 at <https://gerrit.libreoffice.org/9411>
Comment 3 Commit Notification 2014-05-20 11:52:07 UTC
Stephan Bergmann committed a patch related to this issue.
It has been pushed to "libreoffice-4-2":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=164e10869f91b75db03b09f53e1467098b3e6b93&h=libreoffice-4-2

fdo#78949 Handle (SAXParse-)Exception that can't pass getAllRelationships


It will be available in LibreOffice 4.2.5.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 4 Christian Kujau 2014-05-20 20:36:34 UTC
For the record: only after I reported the bug I discovered the nightly builds and was able to open the .xlsx document with master~2014-05-18_04.57.47_LibreOfficeDev_4.3.0.0.alpha1_MacOS_x86.dmg installed.

Thanks for pulling this into 4.2.5!
Comment 5 Stephan Bergmann 2014-05-21 07:21:33 UTC
(In reply to comment #4)
> For the record: only after I reported the bug I discovered the nightly
> builds and was able to open the .xlsx document with
> master~2014-05-18_04.57.47_LibreOfficeDev_4.3.0.0.alpha1_MacOS_x86.dmg
> installed.

This bug would silently be papered over by builds done with the GCC compiler (that's why it showed neither on Linux nor on OS X x86 builds), but not with the Clang compiler (that's why it showed on OS X x86_64 builds).  I assume the build you originally experienced this with was the LO 4.2.4 OS X x86_64 one (requiring OS X 10.8 or newer), while the nightly you tested with (which doesn't contain the fix) is an OS X x86 one.  But in any event, should be fixed now.