Bug Hunting Session
Bug 55610 - FILESAVE: CRASH when exporting particular .odt to XHTML
Summary: FILESAVE: CRASH when exporting particular .odt to XHTML
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.5.7.1 rc
Hardware: x86-64 (AMD64) Mac OS X (All)
: medium major
Assignee: Not Assigned
URL:
Whiteboard: target:4.0.0
Keywords:
Depends on:
Blocks:
 
Reported: 2012-10-04 09:43 UTC by callow.mark
Modified: 2012-11-29 11:48 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
Log file from Apple crash report (120.81 KB, text/plain)
2012-10-09 06:54 UTC, callow.mark
Details
Mac OS X log file for LOdev Master 2012-10-09 on Mac OS X 10.6.8 (108.29 KB, text/plain)
2012-10-09 14:47 UTC, Roman Eisele
Details
xhtml export crash trace (105.97 KB, text/plain)
2012-10-10 08:11 UTC, Alex Thurgood
Details
backtrace of crash exporting to ODT to XHTML (246.31 KB, text/plain)
2012-10-10 08:54 UTC, Alex Thurgood
Details

Note You need to log in before you can comment on or make changes to this bug.
Description callow.mark 2012-10-04 09:43:12 UTC
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.
Comment 1 Alex Thurgood 2012-10-04 14:01:10 UTC
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
Comment 2 Roman Eisele 2012-10-04 14:41:46 UTC
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.
Comment 3 callow.mark 2012-10-05 04:57:30 UTC
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.
Comment 4 Julien Nabet 2012-10-06 19:59:05 UTC
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?
Comment 5 Alex Thurgood 2012-10-07 16:22:50 UTC
(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
Comment 6 Julien Nabet 2012-10-07 17:16:23 UTC
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.
Comment 7 Roman Eisele 2012-10-08 07:15:27 UTC
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.
Comment 8 callow.mark 2012-10-09 06:54:15 UTC
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.
Comment 9 callow.mark 2012-10-09 07:09:07 UTC
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.
Comment 10 callow.mark 2012-10-09 07:35:23 UTC
(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.
Comment 11 Roman Eisele 2012-10-09 14:39:54 UTC
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!).
Comment 12 Roman Eisele 2012-10-09 14:47:41 UTC
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...
Comment 13 Roman Eisele 2012-10-09 14:50:23 UTC
> 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.
Comment 14 Julien Nabet 2012-10-09 14:58:19 UTC
(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).
Comment 15 Roman Eisele 2012-10-09 15:23:07 UTC
(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!
Comment 16 Roman Eisele 2012-10-09 15:53:29 UTC
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 ;-)
Comment 17 Julien Nabet 2012-10-09 16:56:31 UTC
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
Comment 18 Julien Nabet 2012-10-09 17:02:22 UTC
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)
Comment 19 Alex Thurgood 2012-10-10 08:07:23 UTC
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
Comment 20 Alex Thurgood 2012-10-10 08:11:51 UTC
Created attachment 68389 [details]
xhtml export crash trace
Comment 21 Alex Thurgood 2012-10-10 08:12:29 UTC
Confirming crash on OSX 10.8.2 with LO master home build from 07/10/2012.
Comment 22 Alex Thurgood 2012-10-10 08:53:59 UTC
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.
Comment 23 Alex Thurgood 2012-10-10 08:54:54 UTC
Created attachment 68391 [details]
backtrace of crash exporting to ODT to XHTML
Comment 24 Alex Thurgood 2012-10-10 08:58:01 UTC
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
Comment 25 Alex Thurgood 2012-10-10 09:08:46 UTC
(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
Comment 26 Roman Eisele 2012-10-10 14:54:19 UTC
@ 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 27 Peter Jentsch 2012-10-10 20:05:10 UTC
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.
Comment 28 Julien Nabet 2012-10-10 20:41:38 UTC
(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 ?
Comment 29 Caolán McNamara 2012-10-12 10:04:24 UTC
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 ?
Comment 30 Roman Eisele 2012-10-12 10:34:33 UTC
(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.
Comment 31 Peter Jentsch 2012-10-12 19:16:25 UTC
I'm able to debug again, is anybody able to produce a sample document that causes a crash on MacOSX?
Comment 32 Peter Jentsch 2012-10-12 21:05:14 UTC
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?
Comment 33 Julien Nabet 2012-10-12 21:58:01 UTC
(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)
Comment 34 Roman Eisele 2012-10-13 07:34:14 UTC
@ 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!
Comment 35 callow.mark 2012-10-30 05:29:49 UTC
(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.
Comment 36 Roman Eisele 2012-10-30 19:50:33 UTC
(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 '
							'!
Comment 37 Roman Eisele 2012-10-30 19:57:27 UTC
@ 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!
Comment 38 Peter Jentsch 2012-10-30 22:51:47 UTC
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.
Comment 39 callow.mark 2012-10-31 01:15:42 UTC
(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.
Comment 40 callow.mark 2012-10-31 01:39:41 UTC
I filed bug #56595 about the ToC issue and bug #56596 about the formatting issue.
Comment 41 Not Assigned 2012-11-25 20:35:53 UTC
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.
Comment 42 callow.mark 2012-11-26 07:23:40 UTC
With the patch in comment #41, the latest build successfully exports the document with only two remaining defects: bugs 56598 and 57538.
Comment 43 callow.mark 2012-11-26 08:03:55 UTC
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.
Comment 44 Peter Jentsch 2012-11-26 20:49:25 UTC
marking as resolved. further issues tracked separately.
Comment 45 Roman Eisele 2012-11-29 11:48:29 UTC
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!