Writer crashes part way through exporting my .odt file to html. I don't know if it is only this one file or a more general problem. It may be only the MacOS X (Lion) version that is affected. A colleague exported the same document using Windows a couple of weeks ago. Since this is a public list, I cannot attach the source of my document here but I'll be happy to send it to whoever works one this bug.
Without the bug inducing document, this is going to be impossible to nail down or even confirm. Do you think you could produce an anonymised version of the document and then post it here ? Alex
Alternatively, you could send your document via private e-mail either to Alex Thurgood or to me, then we can try to confirm the issue. If we can confirm it, we can send it then (again privately) to the developer who takes this bug. However, this is a bit complicated, and so Alex’ proposal (to create an anonymized version of your document) would be preferred, if possible.
This appears to be a regression. My colleague exported without crashing using LibreOffice 3.5.5.3 build 7122e39-92ed229-498d286-15e43b4-d70da21 on, I think, Windows 7. The document in question is a specification so anonymizing it is not an applicable course. Unfortunately the organization which publishes it does not wish to release the source publicly. I will send it privately to one of the suggested people once I have confirmation from the organization that it is OK to do so. It crashes for me every time so I don't think you'll have any trouble reproducing the problem, once I send you the document. By the way, I'm using 3.6.1.2 on Mac OS X 10.7.5.
callow.mark: Could you try with a brand new file? I would have proposed you to retrieve an useful backtrace but I don't know how to retrieve a bt on MacOs and nothing is indicated there: http://wiki.documentfoundation.org/BugReport You can email me the doc too so I test on Debian x86-64 (I've got 3.5, 3.6 and master sources) Roman/Alex: Is there a link to explain how to retrieve a bt with symbols (even without) on MacOs?
(In reply to comment #4) Hi Julien, > > Roman/Alex: Is there a link to explain how to retrieve a bt with symbols > (even without) on MacOs? No explanation, because it works the same way (apart from the paths) as on Linux, BUT, you do need a debug build with symbols, and as yet no-one provides them, and I can only manage to successfully build one every now and then, what with all the changes going into master, which tend to screw up the build process on Mac until someone has the time to fix it. For example, I haven't been able to build a debug version successfully since last weekend (around 01/10). Alex
Alex: I learnt quite recently that a backtrace even without symbols may help. (of course it's less helpful than with symbols). I took a look here: http://tinderbox.libreoffice.org/MASTER/status.html There's only 1 mac tinderbox ok :( However, is this link should be ok for debug build? http://dev-builds.libreoffice.org/daily/MacOSX-Intel@1-built_no-moz_on_10.6.8/master/current/ Finally, don't hesitate to ask some help on dev mailing list (I know you've already done) and just in case, i've just checked on http://wiki.documentfoundation.org/FindTheExpert that Thorsten was the MacOs expert for LO.
If you allow me to jump in: (In reply to comment #6) > I learnt quite recently that a backtrace even without symbols may help. (of > course it's less helpful than with symbols). So, it is even easier: When an application crashes, Mac OS X asks the user if he wants to send a report about that to Apple. In this dialog, there is a button like “Show details”. If you click it, you get a large dialog window which contains a long text report including a simple stack trace (w/o symbols) and many more useful information about system configuration. The user can just click in th elong report, press Command+A to select all the text, then Command+C to copy it, and then switch to any text editor (e.g. Apple’s TextEdit) and press Command+V to insert the text. Then the user can save the log file, best would be to use a text only (.txt) format. This is the way it is on Mac OS X 10.4 - 10.6. @ Alex: can you confirm that it is still the same on Mac OS X 10.7 and .8? Then we should add such a simple explanation to http://wiki.documentfoundation.org/BugReport (we can improve and expand it later, if necessary). > However, is this link should be ok for debug build? > http://dev-builds.libreoffice.org/daily/MacOSX-Intel@1-built_no-moz_on_10.6.8/master/current/ This is the default daily build we (at least, me) use for all master testing. Using it and the approach descibed above, you can receive the stack traces w/o symbols, because this build does not include full symbols.
Created attachment 68317 [details] Log file from Apple crash report Here is the information from the Apple crash report collected by the method described in comment #7, which works on OS X 10.7.5.
Note: the crash only happens when I pick "Export ..." from the File menu and then XHTML as the file type. If I pick save as HTML instead, LO does not crash but the saved HTML has a large number of layout issues.
(In reply to comment #4) > callow.mark: > > Could you try with a brand new file? I created a new "Text" file, and copied and pasted the document text into it. I got the same result - crash. > > I would have proposed you to retrieve an useful backtrace but See comment 8. > You can email me the doc too so I test on Debian x86-64 (I've got 3.5, 3.6 > and master sources) I sent it to you, Roman and Alex.
Thank you very much for the sample file! We will keep it private. REPRODUCIBLE on Mac OS X 10.6.8 (Intel) with * LibreOffice 3.5.7.1 * LibreOffice 3.6.2.2 * LibreOffice/LOdev 3.6.3.0+ (build ID: a00d5c5, pull time: 2012-10-09 04:00:19) * LOdev 3.7.0.0.alpha0+ (build ID: 1ae1bca; pull time: 2012-10-09 04:37:06) I can confirm that, while “File > Save as...” to HTML format works (with some layout problems), “File >Export...” to XHTML format crashes LibreOffice; this is 100% reproducible with all versions mentioned above. Adjusted Summary to reflect new condition (XHTML, not HTML) and set Version to first version in which bug is known to exist (as usual!).
Created attachment 68347 [details] Mac OS X log file for LOdev Master 2012-10-09 on Mac OS X 10.6.8 This is my Mac OS X log file for the crash with current LOdev Master (pull time: 2012-10-09) on Mac OS X 10.6.8. It differs a little bit from the reporter’s one, but this may be simply due to the Mac OS X version (all my log files for this crash look the same, from LibO 3.5.7 to 3.7 master). @ callow.mark: I forgot: thank you very much for the log file (comment #8)! @ Alex: And now, as I have done the “boring” part ;-): could you manage to get a stack trace with full debug symbols for this crash? This would help our developers much, as you know ... (But if it is too difficult, sorry, I just wanted to ask ;-) And the other thing we can do now is cutting the file into pieces, in the hope to isolate a specific section which causes the crash (I am not sure if there is one). Hm...
> And the other thing we can do now is cutting the file into pieces, in the > hope to isolate a specific section which causes the crash (I am not sure if > there is one). ... because the stack trace contains stuff like XSLT::XSLTFilter::endDocument() which seems (but I may be completely wrong!) that the crash happens not somewhere in the processing of the document contents, but in the final steps of the whole export process.
(In reply to comment #12) > @ Alex: > > And now, as I have done the “boring” part ;-): could you manage to get a > stack trace with full debug symbols for this crash? This would help our > developers much, as you know ... (But if it is too difficult, sorry, I just > wanted to ask ;-) ... Roman: Mark Callow sent the file to me too. I'll try to send the bt tonight (after my day time job).
(In reply to comment #14) > Roman: Mark Callow sent the file to me too. I'll try to send the bt tonight > (after my day time job). Wonderful! Thank you very much in advance!
While waiting for the full bt, I have played around with the file. As I have suspected, it seems not so easy to blame a specific element of the document for the crash. By making copies and deleting sections, I have managed to verify that the crash seems related to the 1st half of the document (corresponding to section 0-6), and, more closely, to section 1-5; i.e., if I create a copy and delete everything before section 1 (title and TOC) and after section 5, this file fragment still crashes, while a document containing sections 6 to 13 does NOT crash. But I did non succeed in locating the crash *within* sections 1-5: if I split it into sections 1-3 and 4-5, *both* files can be exported without the crash; but when I copy both parts together again, the re-united sections 1-5 file crashes again. And if I just delete sections 1 and 5, so that sections 2-4 remain, the file does not crash, either. So the reason for the crash seems to be related to something “in, with, or about” sections 1 to 5, but I can not isolate that “something”. If somebody got a better idea, please let us know ;-)
On pc Debian x86-64 with master sources updated yesterday (8f14c8a61) + brand new LO profile, I don't reproduce the crash. I made: - File export - Select XHTML LO creates an html file (not xhtml file) During the opening of the file, I noticed these logs: warn:i18npool.langtag:5083:1:/home/julien/compile-libreoffice/libo/i18npool/source/languagetag/languagetag.cxx:518: LanguageTag::getRegionFromLangtag: pRegionT==NULL 2 times + a lot of these: warn:legacy.osl:5083:1:/home/julien/compile-libreoffice/libo/sw/source/core/access/acccontext.cxx:1130: context should have a size warn:legacy.osl:5083:1:/home/julien/compile-libreoffice/libo/sw/source/core/access/acccontext.cxx:1171: child context should have a size
I reproduce neither with 3.6 branch nor 3.5 both updated yesterday. Either I missed something or perhaps a specific MacOs bug? (I'll try to find some time to test on Windows)
All, I've noticed that the document contains a lot of hidden OLE objects (you can see them listed in the document object Navigator), wondering whether this might be a problem for the XHTML export. Alex
Created attachment 68389 [details] xhtml export crash trace
Confirming crash on OSX 10.8.2 with LO master home build from 07/10/2012.
In gdb, when exporting, I get a exc_bad_access and kernel protection failure and the app goes into an endless loop. Note that just opening the file causes all sorts of SVRect warnings to be displayed. Backtrace enclosed.
Created attachment 68391 [details] backtrace of crash exporting to ODT to XHTML
I seem to recall that the XSLT stuff is Peter Jensch's area. Will also add Caolan to CC. @Peter, Caolan : this your area ? Alex
(In reply to comment #19) > All, > > I've noticed that the document contains a lot of hidden OLE objects (you can > see them listed in the document object Navigator), wondering whether this > might be a problem for the XHTML export. > Forget that comment, the objects appear greyed out in the Navigator object tree under OLE objects, and until you happen to put the cursor on such an object, either because you know where it is, or you just happen to select one by accident, the objects remain unreachable via the Navigator object tree. This is, IMHO, a problem for a separate bug report. Alex
@ Julien: (In reply to comment #18) > ... or perhaps a specific MacOs bug? Yes, seems probable. Thank you for debugging, anyway! @ Alex: Thank you for the debugging work! I hope it helps ...
Comment on attachment 68389 [details] xhtml export crash trace I'm currently unable to debug on MacOSX because I foolishly upgraded both MacOS (to 10.8) and Xcode (whatever), which broke the build for me. I wonder if the problem occurs with our bundled libxslt, I think I have an older build with that lying around somewhere, will get to have a look later this week.
(In reply to comment #27) > Comment on attachment 68389 [details] > xhtml export crash trace > > I'm currently unable to debug on MacOSX because I foolishly upgraded both > MacOS (to 10.8) and Xcode (whatever), which broke the build for me. > > I wonder if the problem occurs with our bundled libxslt, I think I have an > older build with that lying around somewhere, will get to have a look later > this week. Was looking at libxslt too, just naive question: is the line 156 ok in libxslt/makefile? 153 .IF "$(OS)" == "MACOSX" 154 CONFIGURE_FLAGS += \ 155 --prefix=/@.__________________________________________________$(EXTRPATH) 156 .END Isn't it .ENDIF ?
re: "Isn't it .ENDIF ?" END is the same as ENDIF for our dmake. Although ENDIF is more common. Is it possible to attach an .odt than when exported triggers this problem ? Does it happen only on MacOSX or any sign of the same problem under Windows ?
(In reply to comment #29) > Is it possible to attach an .odt than when exported triggers this problem ? The original file is confidential, but I think callow.mark@artspark.co.jp can it send to you by private mail, as he did send it to us ... > Does it happen only on MacOSX or any sign of the same problem under Windows ? A quick test with the file and LibO 3.5.7.1 on WinXP does not show the crash, while LibO 3.5.7.1 on Mac OS X crashes. So the crash seems to be Mac-only ... Can’t test Linux, of couse.
I'm able to debug again, is anybody able to produce a sample document that causes a crash on MacOSX?
It'd be interesting to see how xsltproc proceses the flat odf export of the original file using the xsl scripts under share/xslt/export/xhtml example Save As: OpenDocument Text (flat xml) testdoc.fodt cd /Applications/LibreOffice.app/Contents/share/xslt/export/xhtml xsltproc opendoc2xhtml.xsl testdoc.fodt Does it process correctly? Does it give any warnings / errors?
(In reply to comment #29) > re: "Isn't it .ENDIF ?" > END is the same as ENDIF for our dmake. Although ENDIF is more common. Ok. Just in case, I changed to .ENDIF so we don't have a mix of both notations. (see http://cgit.freedesktop.org/libreoffice/core/commit/?id=c25269446f80e4333fdefa6e96151757a74d894c)
@ Mark Callow: Can you please send the confidential document also to Peter Jentsch <pjotr@guineapics.de>? He is our XSLT expert, and can probably get valuable insights from that file (and, I hope, fix the bug ;-). Thank you!
(In reply to comment #34) > Can you please send the confidential document also to Peter Jentsch > <pjotr@guineapics.de>? I sent the document to Peter Jentsch on 10/15. I have heard nothing since. Perhaps he never received it.
(In reply to comment #32) > It'd be interesting to see how xsltproc proceses the flat odf export of the > original file using the xsl scripts under share/xslt/export/xhtml > > example > Save As: OpenDocument Text (flat xml) testdoc.fodt > > cd /Applications/LibreOffice.app/Contents/share/xslt/export/xhtml > xsltproc opendoc2xhtml.xsl testdoc.fodt > > Does it process correctly? Does it give any warnings / errors? It does process correctly (even if the results, i.e. the XHTML page, looks somewhat strage/has bad formatting). I have tested this with LibreOffice 3.6.3.2 on Mac OS X 10.6.8 (Intel). The terminal prints the following hints and warnings (no errors!): Using default element rule for ODF element 'text:variable-decls'. Using default element rule for ODF element 'text:variable-decl'. Using default element rule for ODF element 'text:variable-decl'. Using default element rule for ODF element 'text:variable-decl'. Using default element rule for ODF element 'text:index-title'. Using default element rule for ODF element 'text:bookmark-ref'. Using default element rule for ODF element 'text:bookmark-ref'. Using default element rule for ODF element 'text:bookmark-ref'. Using default element rule for ODF element 'text:bookmark-ref'. Using default element rule for ODF element 'text:bookmark-ref'. Using default element rule for ODF element 'text:bookmark-ref'. Using default element rule for ODF element 'text:bookmark-ref'. Using default element rule for ODF element 'text:bookmark-ref'. Accessibility Warning: No alternate text ('svg:title' element) set for image ' '! Accessibility Warning: No alternate text ('svg:title' element) set for image ' '! Accessibility Warning: No alternate text ('svg:title' element) set for image ' '! Accessibility Warning: No alternate text ('svg:title' element) set for image ' '! Accessibility Warning: No alternate text ('svg:title' element) set for image ' '! Accessibility Warning: No alternate text ('svg:title' element) set for image ' '! Accessibility Warning: No alternate text ('svg:title' element) set for image ' '! Accessibility Warning: No alternate text ('svg:title' element) set for image ' '! Accessibility Warning: No alternate text ('svg:title' element) set for image ' '! Accessibility Warning: No alternate text ('svg:title' element) set for image ' '! Accessibility Warning: No alternate text ('svg:title' element) set for image ' '! Accessibility Warning: No alternate text ('svg:title' element) set for image ' '! Accessibility Warning: No alternate text ('svg:title' element) set for image ' '! Accessibility Warning: No alternate text ('svg:title' element) set for image ' '! Accessibility Warning: No alternate text ('svg:title' element) set for image ' '! Accessibility Warning: No alternate text ('svg:title' element) set for image ' '! Accessibility Warning: No alternate text ('svg:title' element) set for image ' '! Using default element rule for ODF element 'text:bookmark-ref'. Using default element rule for ODF element 'text:bookmark-ref'. Accessibility Warning: No alternate text ('svg:title' element) set for image ' '! Accessibility Warning: No alternate text ('svg:title' element) set for image ' '! Accessibility Warning: No alternate text ('svg:title' element) set for image ' '! Accessibility Warning: No alternate text ('svg:title' element) set for image ' '! Accessibility Warning: No alternate text ('svg:title' element) set for image ' '! Accessibility Warning: No alternate text ('svg:title' element) set for image ' '! Accessibility Warning: No alternate text ('svg:title' element) set for image ' '! Accessibility Warning: No alternate text ('svg:title' element) set for image ' '! Accessibility Warning: No alternate text ('svg:title' element) set for image ' '! Accessibility Warning: No alternate text ('svg:title' element) set for image ' '! Accessibility Warning: No alternate text ('svg:title' element) set for image ' '! Accessibility Warning: No alternate text ('svg:title' element) set for image ' '! Accessibility Warning: No alternate text ('svg:title' element) set for image ' '! Accessibility Warning: No alternate text ('svg:title' element) set for image ' '! Accessibility Warning: No alternate text ('svg:title' element) set for image ' '! Accessibility Warning: No alternate text ('svg:title' element) set for image ' '! Accessibility Warning: No alternate text ('svg:title' element) set for image ' '! Accessibility Warning: No alternate text ('svg:title' element) set for image ' '! Accessibility Warning: No alternate text ('svg:title' element) set for image ' '! Accessibility Warning: No alternate text ('svg:title' element) set for image ' '! Accessibility Warning: No alternate text ('svg:title' element) set for image ' '! Accessibility Warning: No alternate text ('svg:title' element) set for image ' '! Accessibility Warning: No alternate text ('svg:title' element) set for image ' '! Accessibility Warning: No alternate text ('svg:title' element) set for image ' '! Accessibility Warning: No alternate text ('svg:title' element) set for image ' '! Accessibility Warning: No alternate text ('svg:title' element) set for image ' '! Accessibility Warning: No alternate text ('svg:title' element) set for image ' '! Accessibility Warning: No alternate text ('svg:title' element) set for image ' '! Accessibility Warning: No alternate text ('svg:title' element) set for image ' '! Accessibility Warning: No alternate text ('svg:title' element) set for image ' '!
@ Peter Jentsch: (In reply to comment #35) > I sent the document to Peter Jentsch on 10/15. I have heard nothing since. > Perhaps he never received it. Hi Peter, can you please answer directly to Mark Callow <callow.mark@artspark.co.jp> and clear up how you can get the document in question from him? Thank you very much!
XSLT script causes very deep call stack, which seems to be a problem specifically on MacOSX. Interesting enough, the xslt script runs through xsltproc: try it: * save file as "fodt". * goto /Application/LibreOffice.app/Contents/share/xslt/export/xhtml * xsltproc --maxdepth 1000 opendoc2xhtml.xsl /path/to/file.fodt I'll try to rewrite the XSLT templates to use iteration instead of recursion and limit the maximum recursion depth on MacOSX platforms. Anyone with MacOSX wizardry to help extend the maximum stack depth available to LibO? As I said, xsltproc processes the document just fine.
(In reply to comment #36) > It does process correctly (even if the results, i.e. the XHTML page, looks > somewhat strage/has bad formatting). I have tested this with LibreOffice I've seen those same formatting issues with an OpenOffice export as well. (Peter sent me the document exported via the steps in comment #35.) It's a fairly minor problem with a few of the CSS. I'll file a separate bug about it. There is also an issue with the links in the ToC which I'll file an additional bug about.
I filed bug #56595 about the ToC issue and bug #56596 about the formatting issue.
Peter Jentsch committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=c8836e0b6d67ff7f4be04fe72ca9834fc5b5b0b7 fix: fdo#55610 - FILESAVE: CRASH when exporting particular .odt to XHTML 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.
With the patch in comment #41, the latest build successfully exports the document with only two remaining defects: bugs 56598 and 57538.
A big thank you to Peter Jentsch for fixing this and two of the other export issues I filed. There are actually 3 remaining defects in the way of a perfect export. I just filed bug 57539.
marking as resolved. further issues tracked separately.
VERIFIED as FIXED with LOdev 4.0.0.0.alpha1+ (Build ID: 519c947f213ec69b0c92d3ea76193270644263e; pull time: 2012-11-28 04:07:39). Export of sample .odt file to XHTML no longer crashes. @ Peter Jentsch: Thank you for fixing this issue!