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. STEPS TO REPRODUCE: 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: 'abc 'def ' ' 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: 4.0.3.3 release
Created attachment 79445 [details] Demo
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.
Created attachment 79446 [details] gdb backtrace, produced from Control-C at the hang
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?
Thanks for reporting. I can reproduce this behavior using Mac OSX 10.8.3 with Versie 4.0.3.3 .3.3 (Bouw-id: 0eaa50a932c8f2199a615e1eb30f7ac74279539); Dutch UI; I have to force quit LibreOffice after I hit the Replace All button. Kind regards, Joren
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)
(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
Any update with recent LO version? Indeed, bt must be useless.
The bug is still there in the daily build LibreOfficeDev 4.4.2.0.0 ce8aba4da2a287c2b51d1d34a290284b2f754dc2
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INVALID due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/FDO/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team This NEEDINFO message was generated on: 2015-10-14
Bug is still there -- reproduced using 5.1.0.0.alpha1+ Happens every time on my system. Julian (serval2412@yahoo.fr): You marked this bug "NEEDINFO". Would you please update further, or post a note indicating what info you need? Thanks.
Since you reproduced this on master sources updated recently, I don't need more info for the moment.
Moving to NEW as it seems more than confirmed.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.1.6 or 5.2.3 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20161108
Confirmed bug is still there in Version: 5.1.5.2 Build ID: 7a864d8825610a8c07cfc3bc01dd4fce6a9447e5 CPU Threads: 4; OS Version: Windows 6.2; UI Render: default; Locale: en-US (en_US); Calc: group
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Bug still there in master. Locks up immediately, 100% CPU. Version: 6.0.0.0.alpha0+ 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
Tried LO 3.3 and the bug is not there, works as expected (each character is replaced by "ABC&"). Added "regression" keyword
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.
Xisco - any chance of a bisection if this is indeed a high prio. regression (it is rather an old one).
I can also reproduce it on Linux LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4 and on Win LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4
Bug still there in master. Do you need a new backtrace? It is easy to reproduce, so may be bisection is feasible. Version: 6.3.0.0.alpha0+ 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
> It is easy to reproduce, so may be bisection is feasible. Sorry, I realize now the bug was inherited from OO
Created attachment 157435 [details] Flamegraph On pc Debian x86-64 with master sources updated today, I could reproduce the hang. Here's a Flamegraph.
It seems there's an infinite loop in this part: #5 0x00007ffff7f49933 in rtl_uString_newReplaceStrAt(rtl_uString**, rtl_uString*, sal_Int32, sal_Int32, rtl_uString*) (ppThis=0x7fffffff0010, pStr=0x7fffd45b8010, nIndex=4, nCount=0, pNewSubStr=0x55555a6bae00) at /home/julien/lo/libreoffice/sal/rtl/strtmpl.cxx:1603 #6 0x00007ffff0544df2 in rtl::OUString::replaceAt(int, int, rtl::OUString const&) const (this=0x55555a4f29e0, index=4, count=0, newStr="ABC\\&") at /home/julien/lo/libreoffice/include/rtl/ustring.hxx:2298 #7 0x00007ffff0765825 in TextNode::InsertText(int, rtl::OUString const&) (this=0x55555a4f29e0, nPos=4, rText="ABC\\&") at /home/julien/lo/libreoffice/vcl/source/edit/textdoc.cxx:267 #8 0x00007ffff0766b45 in TextDoc::InsertText(TextPaM const&, rtl::OUString const&) (this=0x55555a2bc890, rPaM=..., rStr="ABC\\&") at /home/julien/lo/libreoffice/vcl/source/edit/textdoc.cxx:479 #9 0x00007ffff077c4ec in TextEngine::ImpInsertText(TextSelection const&, rtl::OUString const&) (this=0x55555a42af50, rCurSel=..., rStr="ABC\\&") at /home/julien/lo/libreoffice/vcl/source/edit/texteng.cxx:772 #10 0x00007ffff07a8f67 in TextView::Replace(i18nutil::SearchOptions const&, bool, bool) (this=0x55555a50ca20, rSearchOptions=..., bAll=true, bForward=true) at /home/julien/lo/libreoffice/vcl/source/edit/textview.cxx:2206 #11 0x00007fffd49d76ca in basctl::ModulWindow::StartSearchAndReplace(SvxSearchItem const&, bool) (this=0x55555a447bd0, rSearchItem=..., bFromStart=false) at /home/julien/lo/libreoffice/basctl/source/basicide/baside2.cxx:1254 #12 0x00007fffd49f03d9 in basctl::Shell::ExecuteSearch(SfxRequest&) (this=0x55555a38e3e0, rReq=...) at /home/julien/lo/libreoffice/basctl/source/basicide/basides1.cxx:142 #13 0x00007fffd4a032e9 in SfxStubbasctl_ShellExecuteSearch(SfxShell*, SfxRequest&) (pShell=0x55555a38e3e0, rReq=...) at /home/julien/lo/libreoffice/workdir/SdiTarget/basctl/sdi/basslots.hxx:156
The infinite loop occurs at: https://opengrok.libreoffice.org/xref/core/vcl/source/edit/textview.cxx?r=be53f326#2205
I can even reproduce it without any ampersand (&) in the replace clause. Just search for the dot (.) and replace it with ABC. At the end of the search string, the selection will not be expanded, and therefore an infinite loop occurs at https://opengrok.libreoffice.org/xref/core/vcl/source/edit/textview.cxx?r=be53f326#2205.
https://gerrit.libreoffice.org/c/core/+/93432
Andreas Heinisch committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/e7f3731b8d3e930f85e7df0c0e55bbb1aaea191b tdf#64690 - Extend selection on find/replace It will be available in 7.0.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Andreas Heinisch committed a patch related to this issue. It has been pushed to "libreoffice-6-4": https://git.libreoffice.org/core/commit/d936d5658aba2ab921fe144f5240f42304e1c5ff tdf#64690 - Extend selection on find/replace It will be available in 6.4.5. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Thanks for fixing the hang. However matching start-of-line using a lone ^ does not work, or not correctly. It seems impossible to prepend anything to a group of lines, for example, to make them into a block comment by prepending "' " in Basic code. Maybe now that someone who knows how Find & Replace works is here, this can be looked at. The problem is that ^ by itself does not match unless the line contains something after the start-of-line position (i.e. it is not completely empty). 1. Open the ReplaceBug.ods demo and navigate to the Basic code as described in the original comment. 2. Select lines 3-5, i.e., the empty sub declaration ("Sub Main", the empty line, and "End Sub") 3. Control-H. Check "Regular expressions" Set Find: to the single character ^ (should match starts of lines) Set Replace: to the character ' (the Basic comment-starter char) Click Replace All RESULTS: The apostrophie is prepended to only the non-empty lines. EXPECTED RESULTS: Should be prepended to every line.
Hi Jim, Could you please report a new bug for it ?
I filled a new bug report for you Jim.
new bug is in: https://bugs.documentfoundation.org/show_bug.cgi?id=132870 and work on the underlying problem in: https://bugs.documentfoundation.org/show_bug.cgi?id=135538
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/33656a6c7500d0f799b0e4ed97bda0a9e58a7010 tdf#64690: sw: Add UItest It will be available in 7.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.