Problem description: Steps to reproduce: 1. Open Writer. 2. Just type some text with several paragraph breaks. 3. Open "Find & Replace" (Ctrl+H). 4. Enter $ in "Search for", click on "More Options" and select "Backwards" and "Regular expressions", then click on "Find" several times. Click "Yes" when asked if you want to continue from the end of the document. Current behavior: Writer behaves erratically. Expected behavior: Writer behaves sensible. Operating System: Windows 7 Version: 4.0.0.3 rc
Can you define erratically a bit more? Will help triage this
Indeed, I'm not positive what it should do but whatever it is doing is bad. I only see it when I click "replace all" in which case I get a dialog saying I have to turn off undo function, if I click "yes", I essentially get a freeze. Happens on: Version 4.1.0.0.alpha0+ (Build ID: b8e0455f201198b1deb8f8ca0181e6c9cadc335) Date: Sat Feb 23 16:04:37 2013 -0600 Bodhi Linux 2.2 as well as on: Version 4.0.0.3 release Windows XP ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Platform ALL | ALL New (confirmed) Major (results in essentially a crash, loss of data) High (default, might be over stated but this may be a bigger issue than just with reverse paragraph break searches) Regression (works fine in 3.6.4.3 on Bodhi Linux 2.2) Bibisectrequest (I'll do this now)
Bisected: 47498a36f7af8f54e6e3dda89cd4708802a409e6 is the first bad commit commit 47498a36f7af8f54e6e3dda89cd4708802a409e6 Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Tue Dec 11 03:32:02 2012 +0000 source-hash-19f4ebd8a54da0ae03b9cc8481613e5cd20ee1e7 commit 19f4ebd8a54da0ae03b9cc8481613e5cd20ee1e7 Author: Caolán McNamara <caolanm@redhat.com> AuthorDate: Mon Nov 12 21:17:37 2012 +0000 Commit: Caolán McNamara <caolanm@redhat.com> CommitDate: Tue Nov 13 09:49:18 2012 +0000 use SetControlForeground instead of SetTextColor because that's persistent across unrelated style changes otherwise setting e.g. alignment will reset the color to default black Change-Id: I2b975c3914a59a93e54d72aa0975a066b5edf533 :100644 100644 6d85145f7ba0ead31c84e60a4f7ea59af07f4e83 29d96b0de6d16a73b1e9ff2ca8745b115e40d115 M autogen.log :100644 100644 5d2105bc5db0d97452b3f213d028567f7ef47f74 fc50744f3abcdc37e7e8ae63b5ee73f25bb1c6e9 M ccache.log :100644 100644 cb3471f771599c0198309b766b1119b4272134de 28c61ffba7e7adab533f7ff9a4f4f595e4439822 M commitmsg :100644 100644 ea177fc38ffa1376ecf167db31aadeae1ee62b34 144992024292b77d35ec3f94e2b3fd309f9d27f1 M dev-install.log :100644 100644 34bcd3ceb8be50720147e089fde247e8d90868b0 ae2cc20a3e3477e7b1845778dd570bf277812953 M make.log :040000 040000 21c1e97d1421f61bbbeb0734daeac98e43fe52a1 2c1a78c87a5e84fe1c2bafb167b87e7c85aed252 M opt # bad: [5b4b36d87517a6ea96ff8c84c46b12f462fc9a1a] source-hash-8450a99c744e9005f19173e4df35d65640bcf5c4 # good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932 git bisect start 'latest' 'oldest' # good: [16b0b88cbd4ef0f51816e97277e40c5cf78f7bf9] source-hash-099198a4224778fe6e43f5dc13b5b9b1b4dc828c git bisect good 16b0b88cbd4ef0f51816e97277e40c5cf78f7bf9 # good: [f28b8f9a6c47fa59bf98fffe937a2f2db7a2445a] source-hash-a581d31b227623e09d2970a91214fda398f98eda git bisect good f28b8f9a6c47fa59bf98fffe937a2f2db7a2445a # good: [114fd3b76bcba890e6d702d00cef910f1493c262] source-hash-64ab96cd15e52da88781e720d6f031dbcd0ba902 git bisect good 114fd3b76bcba890e6d702d00cef910f1493c262 # bad: [47498a36f7af8f54e6e3dda89cd4708802a409e6] source-hash-19f4ebd8a54da0ae03b9cc8481613e5cd20ee1e7 git bisect bad 47498a36f7af8f54e6e3dda89cd4708802a409e6 # good: [f4e2d84db194943180f3e7ed4adce5f8e377d9bc] source-hash-806d18ae7b8c241fe90e49d3d370306769c50a10 git bisect good f4e2d84db194943180f3e7ed4adce5f8e377d9bc # good: [fb4214f9d134b556582a4a5280e5458de5f8eebd] source-hash-683758efb22d08a4cf211a6d985148f513da2a90 git bisect good fb4214f9d134b556582a4a5280e5458de5f8eebd # good: [7b32edd2389319e0d394368c4109201528c41f7e] source-hash-44b96a2fce52b6e3e683dc917fab219cf75001db git bisect good 7b32edd2389319e0d394368c4109201528c41f7e # good: [9ec4be63ed5281f2e9364b140da69291c7abc348] source-hash-a1ac2538e9b287444500618ab4d2f0f06c25cf34 git bisect good 9ec4be63ed5281f2e9364b140da69291c7abc348
So in here the i18npool re-base and switch to ICU regexp happened: git log --numstat a1ac2538e9b287444500618ab4d2f0f06c25cf34..19f4ebd8a54da0ae03b9cc8481613e5cd20ee1e7 So - there's not much wrong there. I guess this is a reasonably typical regexp search/replace corner case ;-)
Interesting, if I cancel the replace I get !!br0ken!! text in the document- which is exciting. Clearly we passed some invalid parameters to ::copy: (gdb) bt 10 #0 rtl_uString_newFromSubString (ppThis=0xbfdefb9c, pFrom=0xa0b1f28, beginIndex=11, count=172) at /ssd/opt/libreoffice/master/sal/rtl/strtmpl.cxx:1269 #1 0xaff2c93d in rtl::OUString::copy (this=0x9cf75d0, beginIndex=11, count=172) at /ssd/opt/libreoffice/master/solver/unxlngi6.pro/inc/rtl/ustring.hxx:1465 #2 0xb01d489f in SwUndoReplace::Impl::Impl (this=0xa9a7040, rPam=SwPaM = {...}, rIns="", bRegExp=true) at /ssd/opt/libreoffice/master/sw/source/core/undo/unins.cxx:651 #3 0xb01d49ab in SwUndoReplace::SwUndoReplace (this=0xa9d26c8, rPam=SwPaM = {...}, rIns="", bRegExp=true) at /ssd/opt/libreoffice/master/sw/source/core/undo/unins.cxx:518 #4 0xaff9b150 in SwDoc::ReplaceRangeImpl (this=0x9979ba0, rPam=SwPaM = {...}, rStr="", bRegExReplace=true) at /ssd/opt/libreoffice/master/sw/source/core/doc/docedt.cxx:2405 #5 0xaff9b850 in SwDoc::ReplaceRange (this=0x9979ba0, rPam=SwPaM = {...}, rStr="", bRegExReplace=true) at /ssd/opt/libreoffice/master/sw/source/core/doc/docedt.cxx:2198 #6 0xaff635f1 in SwFindParaText::Find (this=0xbfdf006c, pCrsr=0x99f64dc, fnMove=0xb0726634 <aBwrd>, pRegion=0xbfdeffc0, bInReadOnly=<optimized out>) at /ssd/opt/libreoffice/master/sw/source/core/crsr/findtxt.cxx:593 #7 0xaff66dbc in lcl_FindSelection (rParas=..., pCurCrsr=pCurCrsr@entry=0x99f64dc, fnMove=0xb0726634 <aBwrd>, pFndRing=@0xbfdeff9c: 0x0, aRegion=SwPaM = {...}, eFndRngs=FND_IN_SELALL, bInReadOnly=1 '\001', bCancel=@0xbfdf013f: 0 '\000') at /ssd/opt/libreoffice/master/sw/source/core/crsr/swcrsr.cxx:746 #8 0xaff6b410 in SwCursor::FindAll (this=0x99f64dc, rParas=..., nStart=DOCPOS_CURR, nEnde=DOCPOS_START, eFndRngs=FND_IN_SELALL, bCancel= @0xbfdf013f: 0 '\000') at /ssd/opt/libreoffice/master/sw/source/core/crsr/swcrsr.cxx:1010 #9 0xaff62228 in SwCursor::Find (this=0x99f64dc, rSearchOpt=..., bSearchInNotes=0 '\000', nStart=DOCPOS_CURR, nEnd=DOCPOS_START, bCancel= @0xbfdf013f: 0 '\000', eFndRngs=FND_IN_SELALL, bReplace=1) at /ssd/opt/libreoffice/master/sw/source/core/crsr/findtxt.cxx:638 Will dig into it later ...
Taking over.
(In reply to comment #2) > Regression (works fine in 3.6.4.3 on Bodhi Linux 2.2) @Joel: Are you sure? For me searching backwards for regex $ only doesn't work in current 3-6 branch (don't have a 3.6.4) and also not in 3.5.7.2, nothing is found.
Eike Rathke committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=c00601dab0f5533b152cd63cec0a89bfec1ba95f fdo#60259 prevent crash when searching backward for $ anchor regex 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.
Eike Rathke committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=3bc5cb3c485d67f1ce0541d349d11637f52ebda5 regex: handle zero-length matches, fdo#60259 related 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.
Having stepped through sw/source/core/crsr/findtxt.cxx SwPaM::DoSearch() bChkParaEnd cases I'm fairly convinced that this never worked, it just failed differently. Removing regression keyword.
Eike Rathke committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=d8dcfa0e5dbecf77c4d6a8d49caf61b339cf9b43 make forward replacement of $ work again, fdo#60259 related 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.
Thanks Eike - sorry for the bad information
With the crash fixed I lower importance to medium, note that it crashed only on master.
State of misery: * search $ forward works * search $ backward does not work and maybe never did * replace All $ works for empty replacement and replacement string * replace single confirmed $ replaces the following occurrence instead [1] [1] it behaves like that since at least 3.5.x but OOo didn't, the replacing code looks for the regex again which works for normal text but not for paragraph ends. Debugging that convoluted code I got confused by all that SwPaM and moving, pointing and marking. I put this bug back into the pool to have some Writer guy take over, Cc'ing.
Eike Rathke committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=5dd1542bb372627167b44f1b020eab5a405fa6fa&h=libreoffice-4-0 more regex fixes, fdo#60259 related It will be available in LibreOffice 4.0.3. 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.
Actually the bug I have didn't crash writer, it had only the behaviour I described. Now, with the latest daily (libreoffice-4-0~2013-03-31_16.47.37_LibO-Dev_4.0.3.0_Win_x86.msi), when I perform the same operation, it says: "Search key not found." as if there are no paragraph marks in the document at all, which is not true. So it got worse, actually.
It did not get worse. Searching backwards for paragraph end never worked, just that now you get the corresponding message again as it was the case already in 3.6.x
For me it got worse. And as I'm the one who reported this bug I should be entitled to voice my experience. Before, it showed results (in a strange way, for instance by selecting whole sentences instead of only the paragraph break), but at least it showed there were paragraph breaks. Now it says "nothing found" while there are paragraph breaks, in my opinion that is worse. Why is this so difficult to fix if forward searching is working OK? No offense intended. Regards
> Why is this so difficult to fix if forward searching is working OK? It is certainly possible to implement it given a large volume of spare time - on the other hand, fixing the crash / horrible corner cases so they at least don't cause serious problems for users / data-loss is a higher priority. Failing that - if you or someone else want to hack on improving this feature, they are (of course) more than welcome to.
Closing this one as WORKSFORME as the critial crasher is fixed. Please file a separate new issue for the feature request going beyond that.
Removing comma from Whiteboard (please use a space to delimit values in this field) https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Whiteboard#Getting_Started [NinjaEdit]