Steps to reproduce: ( 1) Run Writer. Program presentes document "Untitled 1" ( 2) Menu options Insert > "Indexes and Tables" > "Bibliography Entry...". Program presents dialog "Insert Bibliography Entry". ( 3) Select Entry "From document content" and click <New> button. Program presents dialog "Define Bibiliography Entry". ( 4) In "Short name" type "AA14", in dropdown list Type select Article, and click <OK> button. Program returns focus to dialog "Insert Bibliography Entry". ( 5) Click <Insert> and <Close> buttons. Program returns focus to "Untitled 1"; the document area shows field (i.e., grey background) "[AA14]". ( 6) Menu options Insert > "Indexes and Tables" > "Indexes and Tables...". Program presents dialog "Insert Index/Table". ( 7) In dropdown list Type select Bibliography. Program changes Title to "Bibliography". ( 8) Click <OK> button. Program closes the dialog and returns focus to "Untitled 1". The document area has heading "Bibliography" followed by one line starting "AA14". ( 9) Menu options File > "Save As". Program presents dialog Save. (10) In untitled dropdown list which shows default value "All Formats", select "Microsoft Word 2007/2010/2013 XML (.docx)". (11) In Name, type the pathname minus ".docx" extension to identify a ew file, and click <Save> button. Program presents dialog "Confirm File Format". (12) Click the button <Use Microsoft Waord 2007/2010/2013 XML Format>. Program crashes. Watch for typescript coming soon. These observations are from master commit 295bc87, fetched 2014-02-24, configured with: --enable-option-checking=fatal --enable-dbgutil --enable-crashdump --without-system-postgresql --without-myspell-dicts --with-extra-buildid --without-doxygen --with-external-tar=/home/terry/lo_hacking/git/src built and running of debian-wheezy 64-bit. By the way, this happened as I tried to see whether bug 58300 "FILEOPEN: lost bibliography entries/empty bibliography index when saveing as .doc or .docx" is still happening. Note to self: go back there when this bug is fixed.
Created attachment 94925 [details] typescript with backtrace with symbols line 399 : assertion raised line 410 : backtrace full, failing thread, first 22 frames line 560 : thread apply all backtrace
Terrence - as this is your bug I'm just moving it to NEW ;) If you want independent confirmation let us know
Actually changed my mind - requesting expert opinion here :)
The recipe from comment 0 no longer executes the relevant code since integration of <http://cgit.freedesktop.org/libreoffice/core/commit/?id=598d02d71f40901eab9275704c8bc0e1641b56e3> "fdo#75133: Preseved bibliography after round trip," where AttributeOutputBase::StartTOX (sw/source/filter/ww8/ww8atr.cxx) has a dedicated case TOX_AUTHORITIES now. But the line rText = aIt->sText.copy( 0, 5 ); // #i21237# is still there in lcl_CheckForm (sw/source/filter/ww8/ww8atr.cxx), and there may still be other scenarios that might call that with aIt->sText.getLength() < 5? (Before <http://cgit.freedesktop.org/libreoffice/core/commit/?id=f4fd558ac9d61fe06aa0f56d829916ef9e5ee7b9> "String to OUString and some reduction of scope," that code used tools String::Copy(0, 5), which would silently reduce "5" to the given string's actual length, unlike rtl::OUString::copy, which asserts that the requested length does not exceed the actual length. The reference to <https://issues.apache.org/ooo/show_bug.cgi?id=21237> "Q-PCD MSInteroperability-16" got added with <http://cgit.freedesktop.org/libreoffice/core/commit/?id=1c1e93fabc5b840877d118220f0d65363747ffbd> "INTEGRATION: CWS hbqea101 (1.76.76); FILE MERGED: 2004/05/05 09:30:40 hbrinkm 1.76.76.1: #i21237# TOX patterns are vectors of tokens now" and is unrelated to the copy(0, 5) part, which was there since the initial import.) Miklos, do you know whether that copy(0, 5) could ever legitimately be called with a string of length < 5 (and should thus be adapted to rtl::OUString::copy semantics)?
No, sorry, I don't know. I assume if this ever happens after <http://cgit.freedesktop.org/libreoffice/core/commit/?id=598d02d71f40901eab9275704c8bc0e1641b56e3> "fdo#75133: Preseved bibliography after round trip,", then the crash-testing script will catch this, and we can adjust the second argument of OUString::copy() as necessary. But right now I don't have such a reproducer.
With commit 806f4d8, fetched 2014-03-04 15:19 UTC, the does not happen. I am setting bug status VERIFIED because I am the original reporter and resolution FIXED because comment 4 points to commit 598d02d... .
Migrating Whiteboard tags to Keywords: (needsDevEval) [NinjaEdit]