#901 Infinite loop when searching with no keyword

[Jean-Christophe Helary]

When an erroneous search is launched, it is not possible to stop it from the UI and OmegaT needs to be force-quit to stop it.

For ex:

search for (empty search field)
as regular expression
in source / in translation
untranslated
Search in Project memory

This search is endless.

[Thomas CORDONNIER]

I confirm the problem, but for OmegaT 4 only. In 3.6, in this case the search screen returns all results.
Before to think about a correction, it should be useful to define the expected behaviour in this case. Several possible behaviours:

• return an error saying that text search field is mandatory (implemented in DGT-OT)
• return zero result
• graying the search button, meaning that it cannot be called with empty search zone
• etc.

[Didier Briel]

I had missed that report. It's a regression, which was probably introduced in recent changes.
Since at least 1.4, searching for an empty string returned all ressults. That is the expected behaviour.

Didier

[Thomas CORDONNIER]

Since at least 1.4, searching for an empty string returned all ressults. That is the expected behaviour.

OK (I only wanted to check that this was intentional)

Finally you can try with this patch. This is, indeed, an infinite loop when match.end() == match.start()

[Aaron Madlon-Kay]

The title is "Impossible to stop a search", but the bug is an infinite loop when searching with no keyword. If the desire is to stop a search in progress (by a method other than closing the window, which you can already do when there is no infinite loop) then that would be an RFE.

I have changed the title to reflect the actual issue.

[Aaron Madlon-Kay]

Fixed in trunk, [r10384].

Thomas, I didn't use your patch because it resulted in a new SearchMatch object being created for every character of every segment.

My approach might leave out some search matches in some corner cases: can anyone think of a regex search that would result in some zero-width matches and some non-zero-width matches in the same search string?

[Didier Briel]

Thank you.
Can the previous behaviour be restored?
I.e., when searching for an empty string (in normal/exact search) all results should be returned.

Didier

[Aaron Madlon-Kay]

That is the behavior with the fix.

[Didier Briel]

I just realised there's a small difference (compared with some time ago). If I click on Search, I get indeed the desired behaviour (i.e., I get all results). But, if I just press Enter, I do not get any result.

If I type something into the Search field, Enter and clicking on Search both give results.
If there is nothing in the Search field, Enter does nothing and clicking on Search gives results.

It's the same in 3.6, so that change must be older.

Didier

[Thomas CORDONNIER]

Thomas, I didn't use your patch because it resulted in a new SearchMatch object being created for every character of every segment.

OK that is correct.

can anyone think of a regex search that would result in some zero-width matches and some non-zero-width matches in the same search string?

Unfortunately yes. Reading here - https://www.regular-expressions.info/zerolength.html - you can see that a simple regex such as "\d*" can generate 0-length matches.

Sample in Perl:
$a = "abc123defg"; print "<$&>," while $a =~ /\d*/g;
Result:
<>,<>,<>,<123>,<>,<>,<>,<>,<>,

Try with this expression in an existing document and see what happens. I did not try.

Thomas

[Aaron Madlon-Kay]

I thought that e.g. \d* would not return true from find() but I was wrong. With my initial fix, highlights were missing for searches like this. I have addressed this in trunk, [r10386].

[Thomas CORDONNIER]

I just did the test, replacing \d* with !
Result : all numbers are removed, other characters preceeded by !
I obtain exactly the same result in other languages, so I confirm that the behaviour is correct.
Even if I personally would never do such a replacement, we cannot exclude that somebody tries it, so it was important to check that the behaviour is similar to other tools.

[Didier Briel]

Closed in the released version 4.1.5 of OmegaT.

Didier