Bug 98224 - Drawing objects make Find-And-Replace HANG in Writer
Summary: Drawing objects make Find-And-Replace HANG in Writer
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) Master
Hardware: All All
: high major
Assignee: Not Assigned
Whiteboard: target:5.2.0 target:5.1.4
Keywords: bibisected, regression
: 99803 100535 (view as bug list)
Depends on:
Reported: 2016-02-27 12:14 UTC by Jim Avera
Modified: 2019-05-14 07:17 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:

test.odt (11.96 KB, application/vnd.oasis.opendocument.text)
2016-02-27 12:14 UTC, Jim Avera

Note You need to log in before you can comment on or make changes to this bug.
Description Jim Avera 2016-02-27 12:14:50 UTC
Created attachment 123031 [details]

Find-and-Replace HANGS with 100% CPU when drawing objects are present (or so it seems).


1. Open attached test.odt
2. Control-H (opens Find & Replace)
3. Set Search For to "Page" (without quotes)
4. Click Replace All

RESULTS: Libre Office hangs
EXPECTED: Substitution occurs

Reproduced with and master (

This is a regression, as the problem does not occur using
Comment 1 Julien Nabet 2016-02-27 21:51:13 UTC
On pc Debian x86-64 with master sources updated today, I could reproduce this.
Comment 2 raal 2016-02-28 09:39:58 UTC
windows 5.2 / 100% cpu
Comment 3 Oliver Specht (CIB) 2016-03-02 12:14:05 UTC
The endless loop is in lcl_FindSelection() in swcrsr.cxx
At the beginning there are two ShellCursors in the Ring of cursors.
One is the starting point and the second is used as end point. In the process of search/replace when the drawing is selected that second cursor is removed and thus can not be reached anymore.
ATM I don't know how to solve it
- should there only be one cursor in the beginning because there is no multiple selection
- should the second one not be removed when the drawing is selected
- should the search loop detect the removal of that cursor and leave

I guess in some older version the first was true.
Comment 4 Julien Nabet 2016-03-02 12:35:40 UTC
(In reply to Oliver Specht (CIB) from comment #3)
> ...
> ATM I don't know how to solve it
I suppose someone might respond about this in dev mailing list or on IRC.
Comment 5 Oliver Specht (CIB) 2016-03-03 08:42:00 UTC
(In reply to Oliver Specht (CIB) from comment #3)
> - should there only be one cursor in the beginning because there is no
> multiple selection
> - should the second one not be removed when the drawing is selected
> - should the search loop detect the removal of that cursor and leave
The second point makes the difference. Probably with 
commit bdc1824ea7acfa2fe9d71cdbe57882acce155577
Author: Miklos Vajna <vmiklos@collabora.co.uk>
Date:   Tue May 19 17:20:10 2015 +0200

    SwPaM::Find: search in shapes anchored to the range

that includes shapes into the search/replace the behavior changed.
Older versions ignored the shape and didn't loop.
The fix in http://ci.libreoffice.org/job/lo_gerrit_master/12624/ stops the loop. 
The text in the drawing is (still) not replaced and if more occurrences of the search text were in the document (on top of the page) they wouldn't be found either.
Comment 6 raal 2016-03-03 09:23:46 UTC
This seems to have begun at the one of below commits.

This one?
author	Miklos Vajna <vmiklos@collabora.co.uk>	2015-05-19 15:20:10 (GMT)
committer	Miklos Vajna <vmiklos@collabora.co.uk>	2015-05-19 15:35:03 (GMT)
commit bdc1824ea7acfa2fe9d71cdbe57882acce155577 (patch)
tree 71e05a16d88715ee9127817e3043758d20c03832
parent b97fb340b23e1b6a48c5c95c8d42e9f10ece1748 (diff)
SwPaM::Find: search in shapes anchored to the range

author	Miklos Vajna <vmiklos@collabora.co.uk>	2015-05-19 15:19:14 (GMT)
committer	Miklos Vajna <vmiklos@collabora.co.uk>	2015-05-19 15:35:02 (GMT)
commit b97fb340b23e1b6a48c5c95c8d42e9f10ece1748 (patch)
tree 00e89dc118cf804a0364d59b49e7cc22ca0f466e
parent 0549f250aac361075287d8acae9b7ee73c66256d (diff)
Add sw::DocumentDrawModelManager::Search()

 bae6d3e6ffdd28bb6cc2b20789d531b3b19b8510 is the first bad commit
commit bae6d3e6ffdd28bb6cc2b20789d531b3b19b8510
Author: Norbert Thiebaud <nthiebaud@gmail.com>
Date:   Fri Jun 5 10:13:43 2015 -0500

    source 97b643ac862d0d6d0a305a7fd82fd20dfb3dbf72

    source 97b643ac862d0d6d0a305a7fd82fd20dfb3dbf72
    source d4085dbf35c95cd030bc4b74c7235e90d7c2bff4
    source 3430d2c2b2c4e24b2757015addada9256e399012
    source 564fc483931c0aa2872a33023473c7ac36bfedf1
    source e1b1f9537a299e5cdb4bd824513b41ee903b4bda
    source c922776fdde4801af51ea3840c62f2fa3b8bc552
    source 2dd61975f16c42df4babe59d8f22c652a9d6a7e5
    source 3ebb9a26c26d78c9d1605264503b1d3f276b8729
    source 15a7ae3e8008ef7dbafdcb4b7604cac1fe1f9061
    source eb5850d63acfd3077a4c5c62d45dff48bc6a6137
    source 8d17b7e3a91fee6211b884e2e991a654c56fe8b4
    source 93571a90b3c2e61f3c6ab9c4c42a8ce4f7fd87b2
    source 2d1abfff0156c17cdaabf27c01e92b5e3f0bbbf4
    source 697d49cbb43c7d12bb88ba4f67dafe069cb1c5bd
    source 7a7f73cebcd84a03a5db85d3b423b65c897651f4
    source bdc1824ea7acfa2fe9d71cdbe57882acce155577
    source b97fb340b23e1b6a48c5c95c8d42e9f10ece1748
    source 0549f250aac361075287d8acae9b7ee73c66256d
    source 1349491d48a2f8a130f1b8b840383d31e7927252
    source 0da6ba6d3ccf736ba10bb98ca9b955736a83c5a4
    source 4f0ee1e0514c29a11eb74fd8fa29f594032d1660
    source b717bda1f6484905aebc571c4538165a1fbfd2bb
    source 9c9db85643866ea57757a532d232e05a88de5fb8
    source bbefb58c13f470cdf4e5d0d7d81c7ce95536a6a0
    source b46e0d5dcef20118028a0b4bbd3afb75492d9ec0
    source 3828a18f5f4134daea616121b6df5f06b463e3bb
Comment 7 Commit Notification 2016-03-03 11:34:17 UTC
Oliver Specht committed a patch related to this issue.
It has been pushed to "master":


tdf#98224: endless loop in replace all stopped

It will be available in 5.2.0.

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:

Affected users are encouraged to test the fix and report feedback.
Comment 8 Jim Avera 2016-03-05 08:19:10 UTC
Could someone point me to the x86_64 builds which have this fix?
(please post exact URL)

I looked all around under the location posted 
and see nothing built since February 24 for x86_64

(I looked in the libreoffice-5-1 and master branches, in *x86_64* subdirs)
Comment 9 Timur 2016-03-17 08:27:33 UTC
Looks like fixed, so I mark so. 
Oliver, please backport, as Miklos proposed in Bug 98458. 

Could someone please explain, if regression commit is bdc1824ea7acfa2fe9d71cdbe57882acce155577, how can LO version it's in be found?

PS Jim, it's there: http://dev-builds.libreoffice.org/daily/master/Win-x86_64@62-TDF/current/
Comment 10 Jim Avera 2016-03-17 22:05:28 UTC
I confirm it is fixed on Linux x86_64 Build ID: 53f645a9c959d93bde9230862c415c4ab2e3817b
Comment 11 Julien Nabet 2016-03-17 22:39:48 UTC
So let's put VERIFIED then
Comment 12 Michael Stahl (allotropia) 2016-05-10 09:04:20 UTC
the bugzilla script is having a bad day

was pushed to libreoffice-5-1 for in commit a7435316873335b2d637abff93ffabc9451b5379
Comment 13 Aron Budea 2016-06-22 15:28:04 UTC
*** Bug 100535 has been marked as a duplicate of this bug. ***
Comment 14 Buovjaga 2019-05-14 07:17:35 UTC
*** Bug 99803 has been marked as a duplicate of this bug. ***