Deleting search results results in app lock-up

[scottsmith-im]

Description of the Issue

Deleting search results results in app lock-up ("Not Responding").

I've noticed this happening when I do searches that result in lots of hits over many files -- hereafter referred to as a "big search". So far, I've only noticed the lock-up when I try to clean up the results view after one or more big searches by removing other (usually non-big) search results. It's not necessary to attempt remove the big search itself.

I've first noticed this problem not long ago, so I suspect that it was introduced relatively recently. I'm using Notepad++ in the same way I have been for years, and this problem just started occurring in the last few months or so.

Steps to Reproduce the Issue

1. Do two or more Find in Files searches, one of which results in lots of hits over lots of files (e.g. "22539 hits in 1983 files of 13138 searched"). The other search(es) can have few or zero hits.
2. Try to delete one of the other (non-big) search results by clicking on its parent item in the search results view.
3. Even though the search being deleted has a small number of hits, the app enters a "Not Responding" state and never recovers.

Expected Behavior

I might expect that deleting the results of a really big search could take some time. But deleting search results with a small number of hits shouldn't take long, just because the view also has one or more big search results in it. In fact, it's not clear why the mere presence of a large search result would impact the deletion of a small or zero-result search that's either earlier or later in the Search results view.

Actual Behavior

The app enters a "Not Responding" state and never recovers (I've let it sit for hours on at least one occasion).

Debug Information

Notepad++ v8.4.6 (32-bit)
Build time : Sep 25 2022 - 19:55:26
Path : C:\Program Files (x86)\Notepad++\notepad++.exe
Command Line :
Admin mode : OFF
Local Conf mode : OFF
Cloud Config : OFF
OS Name : Windows 10 Enterprise (64-bit)
OS Version : 21H2
OS Build : 19044.2251
Current ANSI codepage : 1252
Plugins :
mimeTools (2.8)
NppConverter (4.4)
NppExport (0.4)

[Rinakles]

Same issue here. Started a few versions ago, been waiting for it to be fixed but no changes so far.
It doesn't actually lock up, the time to close the results has simply increased by something like 1000x.

For instance, 120983 hits in 6836 files of 15651 searched took over two hours to close (all the while having high power and CPU usage), when previously it was about 15-20 seconds.

Even closing a (relatively) small number of results takes much longer than it used to. Unfortunately, I have no clue in which version this started. If I had to guess, about 4-6 weeks ago?

[Yaron10]

@donho,

I can reproduce that.

[alankilborn]

I can reproduce that.

I wonder if it is related to the introduction of this:

@Yaron10 could you try your reproduction scenario on released software, just before the above was added in?

[Yaron10]

@alankilborn,

The binary of the commit just before Show only one entry... is no longer available.
I've tested it with v8.4.2.

The search itself takes much longer (quite significantly, black screen etc.) with v8.4.2 compared to v8.4.7.

Deleting an entry in the Search Results window:
Much faster with v8.4.2.
v8.4.7 hangs.

[alankilborn]

@Yaron10

The search itself takes much longer (quite significantly, black screen etc.) with v8.4.2 compared to v8.4.7.

One step forward...

Deleting an entry in the Search Results window:
Much faster with v8.4.2.
v8.4.7 hangs.

...and one back.

Such are the hazards of s/w development.

[Yaron10]

@alankilborn,

#12048 by @Ashfaaq18 is a major factor in the search performance improvement.

[Rinakles]

Curious. I tried downgrading to 8.4.2, but the issue persisted.
Tried downgrading further from there. 8.4.0 is the first version that freezes for me, while 8.3.3 still works.
The update notes for 8.4.0 include this search-related item:

• Make Find in Files search result line number aligned. (Fix #11119)

So my issue may be different from the OP. Sorry for assuming that it's the same one. Did not expect there to be multiple issues with search deletion.

[Yaron10]

@Rinakles,

I've tested it more thoroughly and, you're right, 8.4.2 hangs as well on deleting an entry.

I haven't tested 8.3.3 now.
But I suppose it might hang as well under certain circumstances.
And the difference you see in your test-case is probably due to

Update Scintilla from v4.4.6 to v5.2.1 and add Lexilla v5.1.5. (Fix #10504).

in 8.4.0.

[patrickcoyne]

Not sure if this is necroposting but I run into this issue every day searching debug logs while doing dev work.

I'm running 8.4.8.

1. Open file
2. Search for a string with many instances (10000+)
3. Click on search results
4. CTRL+A to select all of them
5. Hit del to delete them all

The app is now hung. The more results I'm deleting, the long it is hung. Deleting 100,000+ results will hang so long I force quit the app.

This used to work fine. I thought maybe it was related to a plugin but seems like other people are seeing this too. Love Notepad++, please fix!

[Rinakles]

I recommend switching back and sticking to the latest working version, which is 8.3.3.
I'm not sure what's going on with this project, as new critical issues like this keep popping up and then ignored.

[alankilborn]

I recommend switching back and sticking to the latest working version, which is 8.3.3.

If that's the case, then I'd look to the change.log for 8.4; the only relevant item seems to be:

• Make Find in Files search result line number aligned. (Fix Improve search lines: 1 -> 01 if XX lines, 001 if XXX lines, 0001 if XXXX lines, etc. #11119)

Maybe that is the root cause?

[rdipardo]

@Rinakles,

I recommend switching back and sticking to the latest working version, which is 8.3.3.

That was the last N++ version built with Scintilla 4.x.x.

I'm not sure what's going on with this project

Scintilla v5 has been a steep learning curve for the developers.

À propos the search result window, the root of the problem is how the editor folds (or "collapses") the matching lines. See https://sourceforge.net/p/scintilla/bugs/2339, and the many threads it links to; also #11774.

[nyamatongwe]

Its worthwhile profiling every performance issue.

In Visual C++

1. Select the Release configuration.
2. Perform Debug | Performance Profiler...
3. Select CPU Usage
4. Press Start
5. Once application is running, perform an example slow operation
6. Close application
7. Select the heavy CPU % (green) range in the timeline
8. The Hot Path is the calling sequence that is slow although the underlying cause might be elsewhere

The profile shows that the time is being spent in FoldSearchResultDoc. Placing a breakpoint at the start of FoldSearchResultDoc shows that it is being run from position 0 many times instead of incrementally moving through the document. Lexers are responsible for marking the range that has been lexed but that isn't occurring here. Breaking in ColouriseSearchResultDoc shows that lexing is restarted from 0 styler.StartAt(startPos); but an absence of "@MarkingsStruct" results in early exit without updating the styled range.

Solution: either style the range or mark it as styled with styler.StartAt(startPos + length); if the existing styles should be valid.

[donho]

@nyamatongwe
Thank you for pointing out the Find in files searching performance issue.
I will check it ASAP.