https://bugs.documentfoundation.org/show_bug.cgi?id=173432
--- Comment #6 from Alex <[email protected]> --- I have filed tdf#173798 with what looks like the same underlying defect, reached from a different direction: Linux rather than Windows, and --headless --convert-to rather than an interactive open. It carries a 1.1 KB reproducer built from scratch, so a bibisect on it costs seconds per build rather than minutes. Three findings from over there that are relevant to this report: 1. The trigger is a legacy Unicode bidirectional control character sitting in the cached result of a REF field. Neither part does anything on its own: the character in ordinary text converts fine, a REF field without one converts fine, and the same character in a PAGE field converts fine. All seven legacy bidi controls behave identically — U+200E, U+200F, U+202A, U+202B, U+202C, U+202D, U+202E — while the Unicode 6.3 isolates (U+2066, U+2069) and non-directional invisibles (U+200B, U+200D, U+2060, U+00AD) are harmless. Word inserts U+200E by itself when it writes cross-references, which is why this turns up in ordinary documents. 2. Two suspects can be ruled out for the file attached here. Replacing the two charts — the ones carrying the unresolvable external Target="Book1" mentioned in comment 2 — changes nothing, and neither does replacing the WMF, the OLE object, the JPEG, numbering.xml, styles.xml, stylesWithEffects.xml, settings.xml, fontTable.xml or theme1.xml. Each was stubbed out one at a time and the file still blew up every time. Bisecting the body instead isolates it to a single paragraph out of 361 top-level blocks, and that paragraph carries a REF field whose cached result contains a U+200E. 3. 26.8.1.1, the current release of the branch, behaves exactly like 26.8.0.3 — measured, not inferred from the changelog. 24.8.4.2 and 26.2.6.3 both convert attachment 208431 in about 2.3 s using under 210 MB. -- You are receiving this mail because: You are the assignee for the bug.
