Download it now!
Bug 64690 - EDITING: Process hang on find/replace in Basic code involving "\&"
Summary: EDITING: Process hang on find/replace in Basic code involving "\&"
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
(earliest affected)
Inherited From OOo
Hardware: All All
: medium critical
Assignee: Not Assigned
Whiteboard: BSA
Keywords: haveBacktrace
Depends on:
Blocks: Find-Search
  Show dependency treegraph
Reported: 2013-05-16 22:42 UTC by Jim Avera
Modified: 2018-12-13 17:32 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:

Demo (8.49 KB, application/vnd.oasis.opendocument.spreadsheet)
2013-05-16 22:46 UTC, Jim Avera
gdb backtrace, produced from Control-C at the hang (16.60 KB, text/x-log)
2013-05-16 22:54 UTC, Jim Avera

Note You need to log in before you can comment on or make changes to this bug.
Description Jim Avera 2013-05-16 22:42:57 UTC
Certain "Find & Replace" operations in Basic-language macro code cause the process to hang (must be killed externally).

It seems to happen when Regular Expressions are enabled and the replacement text is "something\&".   Note that & is supposed to be a magic replacement token when using Regular Expressions, but not, presumably, with a backslash.

Regardless, the process should never hang permanently.

1. Open the attached demo spreadsheet (ReplaceBug.ods)
   It is NOT necessary to enable macro execution.

2. Tools->Macros->Organize Macros-LibreOffice Basic
   Navigate to the "BugDemo" module in the document
   (ReplaceBug.ods was the name used to attach it to this bug)
   Click "Edit" to view the code.

3. Follow the instructions shown in the comments, which are as follows:


'  1. Select the two comment lines above ('abc and 'def)
'  2. Edit->Find and Replace (or Control-H)
'  3. Click "More Options" and 
'       check "Selection Only"
'       check "Regular Expressions"
'  4. In the "Find" box, enter "."
'  5. In the "Replace" box, enter "ABC\&"
'  6. Click ReplaceAll
'  (process hangs)

NOTE: The hang does not occur when editing cell content (rather than Basic source code). or if the replacement text is "\&" by itself (rather than "ABC\&").
Operating System: Ubuntu
Version: release
Comment 1 Jim Avera 2013-05-16 22:46:53 UTC
Created attachment 79445 [details]
Comment 2 Jim Avera 2013-05-16 22:53:39 UTC
Attaching a gdb backtrace produced by running 
  localc --backtrace ReplaceBug.ods
and running the procedure to cause the hang, then typing Control-C in the terminal.
Comment 3 Jim Avera 2013-05-16 22:54:31 UTC
Created attachment 79446 [details]
gdb backtrace, produced from Control-C at the hang
Comment 4 Julien Nabet 2013-05-17 19:30:31 UTC
On pc Debian x86-64 with master sources updated today, I haven't reproduced the problem.

Joren: Do you have 4.0.3? If yes, would you have some time to give it a try?
Comment 5 Jorendc 2013-05-17 22:20:34 UTC
Thanks for reporting.

I can reproduce this behavior using Mac OSX 10.8.3 with Versie .3.3 (Bouw-id: 0eaa50a932c8f2199a615e1eb30f7ac74279539); Dutch UI;

I have to force quit LibreOffice after I hit the Replace All button.

Kind regards,
Comment 6 Julien Nabet 2013-05-20 17:07:18 UTC
Thank you Joren for having confirmed this one! :-)

Noel: one for you? (perhaps just a matter of cherry-picking 1 or some specific changes from master)
Comment 7 Noel Power 2013-05-21 08:54:49 UTC
(In reply to comment #6)
> Thank you Joren for having confirmed this one! :-)
> Noel: one for you? (perhaps just a matter of cherry-picking 1 or some
> specific changes from master)
I can still reproduce this on master ( although it seems a little random, sometimes can take a number of attempts to reproduce it )

I don't know why this is happening in the Basic editor only ( maybe it is just luck ( or bad luck ) ) I don't see this as anything really specific to basic ( or in this case the IDE ) The backtrace shows this is happening somewhere in the guts of i18n/transliteration stuff ( initiated from the text engine ) I am pretty unfamiliar with this area, don't think I can help with this at the moment. Possibly Eike might have an idea
Comment 8 Julien Nabet 2015-03-19 16:21:38 UTC
Any update with recent LO version?
Indeed, bt must be useless.
Comment 9 Jim Avera 2015-03-19 17:19:26 UTC
The bug is still there in the daily build
LibreOfficeDev ce8aba4da2a287c2b51d1d34a290284b2f754dc2
Comment 10 QA Administrators 2015-10-14 19:50:31 UTC Comment hidden (obsolete)
Comment 11 Jim Avera 2015-10-16 02:54:23 UTC
Bug is still there -- reproduced using
Happens every time on my system.

Julian ( You marked this bug "NEEDINFO".  Would you please update further, or post a note indicating what info you need?

Comment 12 Julien Nabet 2015-10-16 05:08:12 UTC
Since you reproduced this on master sources updated recently, I don't need more info for the moment.
Comment 13 Joel Madero 2015-10-18 18:23:47 UTC
Moving to NEW as it seems more than confirmed.
Comment 14 QA Administrators 2016-11-08 11:24:09 UTC Comment hidden (obsolete)
Comment 15 Jim Avera 2016-11-08 19:27:31 UTC
Confirmed bug is still there in

Build ID: 7a864d8825610a8c07cfc3bc01dd4fce6a9447e5
CPU Threads: 4; OS Version: Windows 6.2; UI Render: default; 
Locale: en-US (en_US); Calc: group
Comment 16 QA Administrators 2017-11-09 07:44:17 UTC Comment hidden (obsolete)
Comment 17 Jim Avera 2017-11-10 01:07:51 UTC
Bug still there in master.   Locks up immediately, 100% CPU.

Build ID: cfbb8b5090537e79ba70e250ddee86d53facbe15
CPU threads: 8; OS: Linux 4.10; UI render: default; VCL: gtk2; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2017-10-18_22:54:20
Locale: en-US (en_US.UTF-8); Calc: group
Comment 18 Jim Avera 2017-11-10 01:12:00 UTC
Tried LO 3.3 and the bug is not there, works as expected (each character is replaced by "ABC&").

Added "regression" keyword
Comment 19 Alex H. 2017-12-09 15:01:02 UTC
Still occurs in this build, which I built myself:

Version: (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.
Comment 20 Michael Meeks 2017-12-12 10:32:49 UTC
Xisco - any chance of a bisection if this is indeed a high prio. regression (it is rather an old one).
Comment 21 Xisco Faulí 2017-12-12 10:52:23 UTC
I can also reproduce it on Linux

LibreOffice 3.3.0 
OOO330m19 (Build:6)
tag libreoffice-

and on Win

LibreOffice 3.3.0 
OOO330m19 (Build:6)
tag libreoffice-
Comment 22 QA Administrators 2018-12-13 03:50:47 UTC Comment hidden (obsolete)
Comment 23 Jim Avera 2018-12-13 17:25:56 UTC
Bug still there in master.   Do you need a new backtrace?

It is easy to reproduce, so may be bisection is feasible.

Build ID: b15b1a2a90fa4c239ff8a6a33e73ff50ea422abf
CPU threads: 12; OS: Linux 4.15; UI render: default; VCL: gtk3; 
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2018-11-28_06:21:05
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded
Comment 24 Jim Avera 2018-12-13 17:32:39 UTC
> It is easy to reproduce, so may be bisection is feasible.

Sorry, I realize now the bug was inherited from OO