sw subsequentcheck fails in getBookmarksHash() at sw/qa/complex/writer/CheckBookmarks.java:80 with a com.sun.star.container.NoSuchElementException when it calls getByName with sBookmarkname being something like "__UnoMark__1910_1361181355".
<http://cgit.freedesktop.org/libreoffice/core/commit/?id=37e5910c13746cc3514a9e1443893dab306eb988> "fdo#40819# Disabled failing complex.writer.CheckBookmarks test for now." Please re-enable once the problem is fixed.
Finally rootcaused this down to: http://cgit.freedesktop.org/libreoffice/core/commit/?id=693b095ee8b7406c4aa0fd5b2bd0221bdcab304f which is just very, very wrong. It caused all marks to be exported, not just bookmarks. These include -- among other interesting things -- the internal UnoMarks, that should never, ever be visible via API (and whose lifetime is handled internally: they are transient). As the temporary UnoMarks are generated internally whenever somebody even creates an UnoCursor (which everyone doing stuff working with Bookmarks/Fieldmarks/whatever does: for example to create a Bookmark), this horribly breaks the whole Bookmark/Fieldmark-API. I will revert that commit tomorrow and suggest to find a clean solution instead of this dangerous hack.
Fixed with: http://cgit.freedesktop.org/libreoffice/core/commit/?id=54edd57f21519ab283fc1e0fb85b47b0beb59486 and reenabled test with: http://cgit.freedesktop.org/libreoffice/core/commit/?id=650592cf0181e219921d5e6bc3ffe007c95dc192 The WW8 roundtrip hash changed from DEV300m41 which could suggest a regression, but it is hard to check now where this has been introduced, as this has been broken by 37e5910c13746cc3514a9e1443893dab306eb988 since 2010-09-14 (so basically since the beginning of LO time).
It seems that the WW8 roundtrip hash is unstable and depends on the host machine. On the machine where I did the fix the has was a stable: -53193413016049203700369483764549874348805475606 On Stephans machine it was: -695324166077686916184159880737496820414325627762 On a second machine I get: 310040393867209726240857852469457261967873594728 This should not happen of course, as it indicates a defect that either the export or import via WW8 is lossy/systemdependent.
Likely related (thanks vmiklos): https://issues.apache.org/ooo/show_bug.cgi?id=116193 Disabled WW8 roundtrip for now: http://cgit.freedesktop.org/libreoffice/core/commit/?id=fe7026d72b1b88f60e009fd4de2f53306e0d1c4e
after investigation resolving as WORKSFORME by dropping ww8 roundtrips from the test. One option would be run the test with a lot fewer marks for the ww8 roundtrip, but thats not worth the effort for now.
closing