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.
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.
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.
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.
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.
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)
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?
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.
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.
I see the bug fixed in daily Linux dbgutil bibisect repository version 2017-08-28. I am setting status VERIFIED FIXED. Thank you, Julien.
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.