Created attachment 64343 [details] Document that causes crash Problem description: Open a specific docx file (created with Libreoffice itself) always crashes the application. Steps to reproduce: 1. Open attached File (by double clicking it for example) Current behavior: soffice.bin crashed with SIGSEGV in writerfilter::dmapper::DomainMapper::lcl_text() Expected behavior: File opened, no crash Platform: Ubuntu 12.04 LTS
Hello Christopher Penalver, please leave a short comment whenever you confirm a bug -- without any additional comments, the bug report looks like "confirmed" by the original reporter himself/herself, and we all don't want this. Thank you very much!
Created attachment 64379 [details] MacOS X log file for LibO 3.5.5.3 crash Thank you very much for your bug report! REPRODUCIBLE with LibreOffice 3.5.5.3 (Build ID: 7122e39-92ed229-498d286-15e43b4-d70da2), German langpack installed, on MacoS X 10.6.8 (Intel). The log file created by MacOS X for the crash is attached. But NOT REPRODUCIBLE with LibreOffice 3.6.0.1 (Build ID: 73f9fb6), German langpack installed, on MacOS X 10.6.8 (Intel). So the problem seems to be fixed in LibO 3.6.x, but not in the 3.5.x branch.
Hello Luboš, hello Miklós, I insert your mail address into the CC list of this bug because you are our experts for .docx import/export. This bug is reproducible with LibreOffice 3.5.x, but (at least for me) NOT with 3.6.0.1, so it seems the problem is already fixed on the 3.6 branch. But is there anything we can do for the 3.5 branch, I mean, is it possible to add some band-aid fix to 3.5.x to prevent the crash? Thank you very much in advance!
Created attachment 64405 [details] console msgs + bt on 3.5 branch On pc Debian x86-64, with 3.5 branch updated today, I reproduced the problem. I attached bt + console msgs. With master sources, I don't reproduce the problem.
David: the cherry pick of dfe0baa281d9d4701e9b3846880334213ccb05f5 resolves the problem. I made the test, it's ok. I never tried gerrit for the moment so any idea to retrieve enough reviews quickly to include your commit in 3.5 branch?
Forgot to say 3.6 doesn't have the problem. would it be possible to include the commit in 3.5.6 rc2 if too late for 3.5.6 rc1?
(In reply to comment #5) > David: the cherry pick of dfe0baa281d9d4701e9b3846880334213ccb05f5 resolves the > problem. I made the test, it's ok. > I never tried gerrit for the moment so any idea to retrieve enough reviews > quickly to include your commit in 3.5 branch? You can post a review request to the mailing list. IIRC there are still nearly 2 weeks till 3.5.6 rc1, so there is enough time. OTOH, the mentioned patch just avoids a segfault on importing broken RTF file, so it should not be applicable for OpenXML import. It probably just hides the problem.
(In reply to comment #7) > (In reply to comment #5) > > David: the cherry pick of dfe0baa281d9d4701e9b3846880334213ccb05f5 resolves the > > problem. I made the test, it's ok. > > I never tried gerrit for the moment so any idea to retrieve enough reviews > > quickly to include your commit in 3.5 branch? > > You can post a review request to the mailing list. IIRC there are still nearly > 2 weeks till 3.5.6 rc1, so there is enough time. > > OTOH, the mentioned patch just avoids a segfault on importing broken RTF file, > so it should not be applicable for OpenXML import. It probably just hides the > problem. Thank you for the feedback David, I sent this post on dev mailing list : http://nabble.documentfoundation.org/REVIEW-3-5-6-Cherry-pick-straightforward-patch-td3996585.html
On pc Debian x86-64, with 3.5 sources updated today, I don't reproduce the problem. I checked here:http://cgit.freedesktop.org/libreoffice/core/log/?h=libreoffice-3-5-6 the fix has been pushed by David (search for "do not crash when opening rtf file with unclosed field group") QA/dev guys: do we let the status to New for the moment?
Looks ok in 3-5 series now, so lets mark it as resolved
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.