Bug Hunting Session
Bug 98224 - Drawing objects make Find-And-Replace HANG in Writer
Summary: Drawing objects make Find-And-Replace HANG in Writer
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.0.0.0.alpha0+ Master
Hardware: All All
: high major
Assignee: Not Assigned
URL:
Whiteboard: target:5.2.0 target:5.1.4
Keywords: bibisected, regression
: 99803 100535 (view as bug list)
Depends on:
Blocks:
 
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:


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

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]
test.odt

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

STEPS TO REPRODUCE:

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 5.0.5.2 and master (5.2.0.0.alpha0+)

This is a regression, as the problem does not occur using  4.4.6.0.0+
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 sha:97b643ac862d0d6d0a305a7fd82fd20dfb3dbf72

    source sha:97b643ac862d0d6d0a305a7fd82fd20dfb3dbf72
    source sha:d4085dbf35c95cd030bc4b74c7235e90d7c2bff4
    source sha:3430d2c2b2c4e24b2757015addada9256e399012
    source sha:564fc483931c0aa2872a33023473c7ac36bfedf1
    source sha:e1b1f9537a299e5cdb4bd824513b41ee903b4bda
    source sha:c922776fdde4801af51ea3840c62f2fa3b8bc552
    source sha:2dd61975f16c42df4babe59d8f22c652a9d6a7e5
    source sha:3ebb9a26c26d78c9d1605264503b1d3f276b8729
    source sha:15a7ae3e8008ef7dbafdcb4b7604cac1fe1f9061
    source sha:eb5850d63acfd3077a4c5c62d45dff48bc6a6137
    source sha:8d17b7e3a91fee6211b884e2e991a654c56fe8b4
    source sha:93571a90b3c2e61f3c6ab9c4c42a8ce4f7fd87b2
    source sha:2d1abfff0156c17cdaabf27c01e92b5e3f0bbbf4
    source sha:697d49cbb43c7d12bb88ba4f67dafe069cb1c5bd
    source sha:7a7f73cebcd84a03a5db85d3b423b65c897651f4
    source sha:bdc1824ea7acfa2fe9d71cdbe57882acce155577
    source sha:b97fb340b23e1b6a48c5c95c8d42e9f10ece1748
    source sha:0549f250aac361075287d8acae9b7ee73c66256d
    source sha:1349491d48a2f8a130f1b8b840383d31e7927252
    source sha:0da6ba6d3ccf736ba10bb98ca9b955736a83c5a4
    source sha:4f0ee1e0514c29a11eb74fd8fa29f594032d1660
    source sha:b717bda1f6484905aebc571c4538165a1fbfd2bb
    source sha:9c9db85643866ea57757a532d232e05a88de5fb8
    source sha:bbefb58c13f470cdf4e5d0d7d81c7ce95536a6a0
    source sha:b46e0d5dcef20118028a0b4bbd3afb75492d9ec0
    source sha: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":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=83dccbadc2c6caa804039199915d4a8c1f3f2d5a

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:
http://wiki.documentfoundation.org/Testing_Daily_Builds

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 
(http://dev-builds.libreoffice.org/daily/)
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
 5.2.0.0.alpha0+ Build ID: 53f645a9c959d93bde9230862c415c4ab2e3817b
Comment 11 Julien Nabet 2016-03-17 22:39:48 UTC
So let's put VERIFIED then
Comment 12 Michael Stahl (CIB) 2016-05-10 09:04:20 UTC
the bugzilla script is having a bad day

was pushed to libreoffice-5-1 for 5.1.4.1 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. ***