Bug 111818 - assertion in SvxSearchItem::GetRegExp() const, srchitem.hxx:244
Summary: assertion in SvxSearchItem::GetRegExp() const, srchitem.hxx:244
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
6.0.0.0.alpha0+
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:6.0.0 target:5.4.2
Keywords: bibisected, haveBacktrace, regression
Depends on:
Blocks: Assert
  Show dependency treegraph
 
Reported: 2017-08-15 15:35 UTC by Terrence Enger
Modified: 2017-09-01 11:53 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
bibisect in till52 (2.48 KB, text/plain)
2017-08-15 15:35 UTC, Terrence Enger
Details
bt with debug symbols (6.33 KB, text/plain)
2017-08-15 18:36 UTC, Julien Nabet
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Terrence Enger 2017-08-15 15:35:14 UTC
Created attachment 135556 [details]
bibisect in till52

STR
---

(1) Create new spreadsheet "Untitle 1".

(2) Type "<Ctrl>+F".  Program moves caret into the search toolbar at
    bottom of the window.

(3) Type "qwer<Enter>".

    Expected: Nothing much.  In particular, window "Untitled 1"
              remains open.

    Observed: Program terminates with terminal messages (lines
              rewrapped) :

        soffice.bin:
            /home/vmiklos/git/libreoffice/master/include/svl/srchitem.hxx:244:
            bool SvxSearchItem::GetRegExp() const:
            Assertion
            `(m_aSearchOpt.algorithmType ==
                   css::util::SearchAlgorithms_REGEXP
             ) == (m_aSearchOpt.AlgorithmType2 ==
                   css::util::SearchAlgorithms2::REGEXP
                  )
            ' failed.
        Application Error
        Fatal exception: Signal 6

The assertion is raised independently of whether the search string in
step (3) is or is not in the document.

Working on debian-stretch in the linux dbgutil daily till52 bibisect
repository, I see that the assertion started being raised somewhere in
the 179 source commits:

          commit    date        s-h
          --------  ----------  --------
    good  aa6c556b  2016-03-10  3a884475
    bad   64448be9  2016-03-11  42d6a165

I am setting keywords regression, bibisected.
Comment 1 Terrence Enger 2017-08-15 15:54:22 UTC
I am unable to reproduce the assertion in a local build

    Version: 6.0.0.0.alpha0+
    Build ID: 46aba1db9a8e43da03f4db580b8dc9de7b850b00
    CPU threads: 2; OS: Linux 4.9; UI render: default; VCL: gtk3; 
    Locale: en-CA (en_CA.utf8); Calc: group

configured

    CC=ccache /usr/bin/gcc
    CXX=ccache /usr/bin/g++
    --enable-option-checking=fatal
    --enable-dbgutil
    --enable-debug
    --without-system-postgresql
    --without-myspell-dicts
    --with-extra-buildid
    --without-doxygen
    --with-external-tar=/home/terry/lo_hacking/git/src
    --without-package-format

built and running under gdb on debian-stretch.

I am setting keywords regression, bibisected.
Comment 2 Terrence Enger 2017-08-15 16:40:36 UTC
In the range in bibisected range, I notice this commit with "search"
in the commit message:

    commit 69ac605191860aceee09f1147a5234222d1b3300
    Author: Mohammed Abdul Azeem <azeemmysore@gmail.com>
    Date:   Mon Feb 29 16:48:03 2016 +0530

        tdf#57523 - Regex search "^$" finds all empty cells in given range.
    
        Just added a condition to trigger ScTable::SearchAndReplaceEmptyCells
        which already finds and replaces all empty cells.
    
        Corrected range detection to find empty cells in data area only.
        Odd behavior when selection was left or above actual data area
        has been fixed.
    
        Change-Id: I4b0cedd9d28ebdcaf580ca1bc8da780cf6342c54
        Reviewed-on: https://gerrit.libreoffice.org/22766
        Tested-by: Jenkins <ci@libreoffice.org>
        Reviewed-by: Eike Rathke <erack@redhat.com>
        Tested-by: Eike Rathke <erack@redhat.com>

Mohammed, could this commit be causing the assertion?

I am adding azeemmysore@gmail.com to cc.
Comment 3 Julien Nabet 2017-08-15 18:36:17 UTC
Created attachment 135561 [details]
bt with debug symbols

On pc Debian x86-64 with master sources updated today, I could reproduce this.

To reproduce this, I had to check first "Regular expressions" in "Other options" from "Find and Replace".
Then, I closed this window and tried Ctrl-F (so no specific window, just the cursor which goes on box to type the expression to search), then typed something and had an assert when typing Enter.
Comment 4 Julien Nabet 2017-08-15 18:45:02 UTC
Eike: noticing the assert has been added with https://cgit.freedesktop.org/libreoffice/core/commit/?id=21edff2a37c9c22d200df2638e31f7ff3afe85b6, thought you might be interested in this one.
Comment 5 Julien Nabet 2017-08-15 18:53:03 UTC
Rerunning the test on gdb, I found that at the assert, m_aSearchOpt.algorithmType = com::sun::star::util::SearchAlgorithms::SearchAlgorithms_ABSOLUTE (instead of css::util::SearchAlgorithms_REGEXP)
Comment 6 Julien Nabet 2017-08-16 08:48:01 UTC
I think the pb is in impl_executeSearch more precisely here:
114      css::uno::Sequence< css::beans::PropertyValue > lArgs(7);
115      lArgs[0].Name = "SearchItem.SearchString";
116      lArgs[0].Value <<= sFindText;
117      lArgs[1].Name = "SearchItem.Backward";
118      lArgs[1].Value <<= aSearchBackwards;
119      lArgs[2].Name = "SearchItem.SearchFlags";
120      lArgs[2].Value <<= (sal_Int32)0;
121      lArgs[3].Name = "SearchItem.TransliterateFlags";
122      SvtCTLOptions aCTLOptions;
123      TransliterationFlags nFlags = TransliterationFlags::NONE;
124      if (!aMatchCase)
125          nFlags |= TransliterationFlags::IGNORE_CASE;
126      if (aCTLOptions.IsCTLFontEnabled())
127          nFlags |= TransliterationFlags::IGNORE_DIACRITICS_CTL;
128      if (aCTLOptions.IsCTLFontEnabled())
129          nFlags |= TransliterationFlags::IGNORE_KASHIDA_CTL;
130      lArgs[3].Value <<= (sal_Int32)nFlags;
131      lArgs[4].Name = "SearchItem.Command";
132      lArgs[4].Value <<= (sal_Int16)(aFindAll ?
133          SvxSearchCmd::FIND_ALL : SvxSearchCmd::FIND );
134      lArgs[5].Name = "SearchItem.AlgorithmType";
135      lArgs[5].Value <<= (sal_Int16)0;  // 0 == SearchAlgorithms_ABSOLUTE
136      lArgs[6].Name = "SearchItem.SearchFormatted";
137      lArgs[6].Value <<= bSearchFormatted;
138  
139      css::uno::Reference< css::frame::XDispatchProvider > xDispatchProvider(xFrame, css::uno::UNO_QUERY);
(see https://opengrok.libreoffice.org/xref/core/svx/source/tbxctrls/tbunosearchcontrollers.cxx#135)

I suppose we should add the arg "SearchItem.AlgorithmType2" with ABSOLUTE too, unless we should synchronize with options set before?
Comment 7 Eike Rathke 2017-08-28 12:25:14 UTC
Yes, AlgorithmType2 should be included as well, though it's unclear to me how the dispatcher actually constructs an SvxSearchItem of the UNO properties. Setting properties should happen through SvxSearchItem::PutValue() just that I don't see how the property name is mapped to member ID. Anyway, try with "SearchItem.AlgorithmType2", the MID_SEARCH_ALGORITHMTYPE2 is already prepared.
Comment 8 Commit Notification 2017-08-28 20:24:04 UTC
Julien Nabet committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=97cd8e4d64632bb65445cb2f395b1385a0a2a13b

tdf#111818: add SearchItem.AlgorithmType2 option

It will be available in 6.0.0.

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 Terrence Enger 2017-08-31 22:41:08 UTC
I see the bug fixed in daily Linux dbgutil bibisect repository version
2017-08-28.  I am setting status VERIFIED FIXED.

Thank you, Julien.
Comment 10 Commit Notification 2017-09-01 11:53:03 UTC
Julien Nabet committed a patch related to this issue.
It has been pushed to "libreoffice-5-4":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=bb8641f649cb53a4afe0653d641bd9907e2dfa57&h=libreoffice-5-4

tdf#111818: add SearchItem.AlgorithmType2 option

It will be available in 5.4.2.

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.