Bug 60259 - : Writer behaves erratically when reverse replacing $ with nothing
Summary: : Writer behaves erratically when reverse replacing $ with nothing
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.0.0.3 release
Hardware: All All
: medium major
Assignee: Not Assigned
URL:
Whiteboard: BSA bibisected40 target:4.1.0 target:...
Keywords:
Depends on:
Blocks:
 
Reported: 2013-02-04 01:23 UTC by oopbraak
Modified: 2015-12-22 01:31 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description oopbraak 2013-02-04 01:23:26 UTC
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
Comment 1 Joel Madero 2013-02-20 02:24:48 UTC
Can you define erratically a bit more? Will help triage this
Comment 2 Joel Madero 2013-02-25 16:09:08 UTC
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)
Comment 3 Joel Madero 2013-02-25 16:52:15 UTC
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
Comment 4 Michael Meeks 2013-03-08 15:19:00 UTC
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 ;-)
Comment 5 Michael Meeks 2013-03-08 17:23:56 UTC
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 ...
Comment 6 Eike Rathke 2013-03-08 18:11:19 UTC
Taking over.
Comment 7 Eike Rathke 2013-03-08 22:47:57 UTC
(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.
Comment 8 Commit Notification 2013-03-09 17:52:08 UTC
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.
Comment 9 Commit Notification 2013-03-09 17:52:27 UTC
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.
Comment 10 Eike Rathke 2013-03-09 17:56:04 UTC
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.
Comment 11 Commit Notification 2013-03-11 21:57:23 UTC
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.
Comment 12 Joel Madero 2013-03-11 23:04:03 UTC
Thanks Eike - sorry for the bad information
Comment 13 Eike Rathke 2013-03-12 11:06:18 UTC
With the crash fixed I lower importance to medium, note that it crashed only on master.
Comment 14 Eike Rathke 2013-03-12 11:34:45 UTC
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.
Comment 15 Commit Notification 2013-03-12 13:24:40 UTC
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.
Comment 16 oopbraak 2013-04-01 16:19:56 UTC
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.
Comment 17 Eike Rathke 2013-04-02 11:18:01 UTC
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
Comment 18 oopbraak 2013-04-21 02:28:53 UTC
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
Comment 19 Michael Meeks 2013-04-22 09:59:08 UTC
> 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.
Comment 20 Björn Michaelsen 2013-05-28 18:27:20 UTC
Closing this one as WORKSFORME as the critial crasher is fixed. Please file a separate new issue for the feature request going beyond that.
Comment 21 Robinson Tryon (qubit) 2015-12-22 01:31:16 UTC
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]