[Libreoffice-bugs] [Bug 64690] EDITING: Process hang on find/replace in Basic code involving "\&"

bugzilla-daemon at bugs.documentfoundation.org bugzilla-daemon at bugs.documentfoundation.org
Sat Dec 9 15:01:02 UTC 2017


https://bugs.documentfoundation.org/show_bug.cgi?id=64690

--- Comment #19 from Alex H. <alexhfromnorthholland at gmail.com> ---
Still occurs in this build, which I built myself:

Version: 6.1.0.0.alpha0+ (x64)
Build ID: 7c77ff5dd2d0573a56f8b59dc9113c23e0ea29c9
CPU threads: 4; OS: Windows 10.0; UI render: default; 
Locale: nl-NL (nl_NL); Calc: CL

I looked at this with a debugger and it seems that the problem is that the
"search area", so to speak, doesn't get updated properly to reflect that each
character is replaced by five characters, i.e. there is a net change in size.

In more detail, I think that the problem is in TextView::Replace() in
libo-core\vcl\source\edit\textview.cxx. I found that it works fine on the first
line of the selection, but hangs up on the second line. After it has replaced
the first character, it invokes

pTextEngine->Search( aSel, rSearchOptions );

with aSel containing maStartPaM == {7, 5} and maEndPaM == {7, 4}.

Search(...) does a Justify() that swaps start and end, so that the search range
now begins at 4. This, however, is part of the 5-character string just
inserted. Because the string to find is regexp '.', one of the characters just
inserted now gets replaced again by 5 characters. The overall effect is that
the string keeps on growing.

I'd like to fix this one, but it's a bit beyond my current capability.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20171209/5eea2312/attachment.html>


More information about the Libreoffice-bugs mailing list