Ubuntu

CheckBookmarks fails with NoSuchElementException on names __UnoMark__1910_1361181355

Reported by Björn Michaelsen on 2011-10-05
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
LibreOffice Productivity Suite
Invalid
Medium
libreoffice (Ubuntu)
Undecided
Björn Michaelsen

Bug Description

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".

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.

Changed in libreoffice (Ubuntu):
assignee: nobody → Björn Michaelsen (bjoern-michaelsen)
Changed in df-libreoffice:
importance: Unknown → Medium
status: Unknown → Confirmed
tags: added: lo33

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).

Changed in libreoffice (Ubuntu):
milestone: none → ubuntu-12.04
status: New → Fix Committed

fixed upstream

Changed in df-libreoffice:
milestone: none → 3.5.0

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.

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.

Changed in df-libreoffice:
status: Confirmed → Invalid
Changed in libreoffice (Ubuntu):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.