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+
On pc Debian x86-64 with master sources updated today, I could reproduce this.
windows 5.2 / 100% cpu
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.
(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.
(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.
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
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.
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)
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/
I confirm it is fixed on Linux x86_64 5.2.0.0.alpha0+ Build ID: 53f645a9c959d93bde9230862c415c4ab2e3817b
So let's put VERIFIED then
the bugzilla script is having a bad day was pushed to libreoffice-5-1 for 5.1.4.1 in commit a7435316873335b2d637abff93ffabc9451b5379
*** Bug 100535 has been marked as a duplicate of this bug. ***
*** Bug 99803 has been marked as a duplicate of this bug. ***