SlickEdit Community
Archived Read Only Forums => SlickEdit 2020 v25 Beta Discussion => Topic started by: rowbearto on August 24, 2020, 03:57:58 pm
-
I've hit this issue a few times but so far have not been able to reproduce it with a small project.
I do a "Find in files" search. I know the search term is in one of the files, but SlickEdit states "No files were found to look in.". But there are files to look in. If I simply change the search term to something else (without changing "Look in:" or "File types") that I know is there it is found. It depends on the search term. After some time it doesn't reproduce.
-
What is lookin set to?
-
lookin is set to a directory
File Types is set to:
CMakeLists.txt;*.cmake
I'm trying to construct a small project that reproduces it again.
-
I tried making a smaller project with just the files to search, used a clean config, then tried clean config + my user.cfg.xml, can't reproduce it :(
-
And it just stopped happening with my real project and my main SE installation. This issue has occurred for me a few times in past week or so.
-
Is the directory remote? Just wondering if the directory went off line.
-
Directory is remote but I know for sure it is not offline.
-
Next time it happens, you could try switching to the Files tab and see if it lists any files.
-
Its happening again now. I switched to Files tab and it is showing the found files. But with "Find in Files" it is saying "No files were found to look in".
I've seen this in both Linux and Windows with beta3. Don't know how to reliably reproduce it. Any hints?
-
Some symptoms of the issue.
I have a directory with many scripts and 3 of the scripts have the string: "sshvarskeep.sh".
If I search for "sshv" it indicates 197 files searched and 3 files found.
If I add 1 character, "sshva", it indicates 97 files searched (100 less) and nothing found.
Add 1 additional character, "sshvar", and it says that no files were found to look in. Maybe it subtracted another 100 files and with -3 files it thinks there is nothing to search?
Anything special about subtracting 100?
There is another string that I searched in this directory before which was previously found. But now that I'm in some state where this problem is happening, it isn't finding it anymore. So not sure I can find a way to systematically repro it.
-
And now it doesn't repro anymore, and all I did was some more normal usage, editing and searching.
I suspect there is some kind of memory corruption. Maybe the search string is overwriting some variables and that is why shorter search string didn't cause an issue while a larger one did.
-
Happening again now. When I search "connect" it searches 451 files. When I add a space and search "connect ", which I know it should find, it states "no files were found to look in". Using "Files" tab it finds 454 files. So Files tab is finding 3 more files than "connect" which searches 451 files.
Perhaps the issue could be reproduced if try a "Find in Files" with a very long search string, then maybe it would cause whatever memory corruption may be occurring?
-
Are you using the "List current context" check box? If you uncheck it, does the number of files change?
-
I am using "List current context". When I uncheck it then it has 453 files instead of 451.
Some things changed since last post. In the last post "connect" found 451 files instead of 454. But when I do it again now, "connect" found all 454 files. So I changed the search string by repeating "connect " many times with pasting.
After I did that, and with "List current context" checked, it found 451 files. When I uncheck it, it found 453 files. Going back and forth was consistent, 451/453, when in both cases it should be 454.
-
Are you doing the search on Windows or Unix?
Are you specifying any excludes? If so, you could try removing that.
-
I have fixed a bug with the "List current context" option but I'm not sure if that bug could cause the search instance to terminate prematurely. For me, it crashed the primary instance of SlickEdit.
-
I'm currently doing this search in Linux, however I have noticed this issue in Windows before.
I do have excludes of "<Default Excludes>;local-objs/;*.log"
When I remove the excludes and try to find the "connect connect ..." string with "list current context" checked, the # of files found goes up to 454 from 451.
However with those excludes present in the "Files" tab, it finds 454 files.
-
If you copy the search results out to a file for both cases and diff them, it should tell us which files are missing. Seems like the same files are probably missing each time. This might give us a clue as to whats going on.
I'm still trying various test cases on my end and not having any luck.
-
Not sure that will help as no files are found in my search results for my search term. It is the set of files that is getting searched that is being narrowed down unnecessarily.
If there is a way for "Find in Files" to also list all the files that were searched then I can diff that against the output of the "Files" tab.
-
When Beta 3 launches the search instance of SlickEdit, the -sc option is NOT used (fixed for beta 4). I'm just wonder if the <Default Excludes> or <Binary Excludes> are different for the search instance. This doesn't explain the flackyness of the number of files found.
-
Not sure that will help as no files are found in my search results for my search term. It is the set of files that is getting searched that is being narrowed down unnecessarily.
If there is a way for "Find in Files" to also list all the files that were searched then I can diff that against the output of the "Files" tab.
Hmm...you'd have to change the search string to a SlickEdit regex like "\z". This will match the end of each file so you get each file listed once.
-
But if my search string is simply "\z" then it may not trigger the problem. perhaps I could do a regex search of (my long search string)|\z, maybe that would still repro the problem and find all the files? Hopefully it also occurs with regex search.
-
Unfortunately it stopped reproducing again. I'll try with \z when it happens again.
One thing I noticed, when a search string is found I don't see SE printing out the number of files searched.
-
Do you mean it's not printed on the message line or not appended to the end of the search output?
-
I do see it now at the end of the search output. Strange I didn't see it before, maybe I should have waited longer.
-
Look for fif.tar.gz on support.
I reproduced the issue with a regex search of (ignor|\z). 1.txt finds 451 files. 2.txt finds 454 files. But the diff output is the same except for the final line showing 451 vs 454 files.
So maybe I need something besides \z in my regex, or I did it wrong? The search results don't have all 451 (or 454) files searched in the output.
Also, I think I didn't see the # of files searched before because I actually did "find" instead of "find in files".
-
Look for fif2.tar.gz on support. I was able to repro it with "\Z" (need capital Z).
With the excludes (10.txt) it searched 451 files. Without the excludes (11.txt) it searched 454 files.
Files tab with the excludes included finds 454 files.
-
One bug I'm seeing with the "List current context" option is that the "Total Files searched" is including files that were excluded. When I turn that option off, then the "Total files search" does not include files that were excluded.
This doesn't help me explain the issues you are having though.
-
Well I'm fairly sure that I had "list current context" checked in my upload of 10.txt and 11.txt, so in 10.txt even though "list current context" was checked, 3 files got excluded.
-
The Files tab of the Find and Replace tool window is ignoring binary excludes (different than excluded files extensions).
-
OK. Even so the 2 files that the diff of 10.txt and 11.txt show are not binary files, they are text files. I can upload them to support if you like. And I don't think that I have any binary files in this directory that I'm searching.
-
I don't think you're following what I'm saying. I found a couple bugs. The bugs that I found do not explain the problems you are having. They are bugs having to do with the "Total files searched" count being wrong because binary files (typically files with no extension) are being included in the "Total files searched" count. If you have files with no extension that are binary, this will help confuse what's going on here. The "Total files searched" count is currently only correct for a multi-file search which does not have the "List current context" checked. The Files tab is incorrect as well for binary files with no extension.
-
Found and fixed the major problem where results are random and may find NO FILES when the "List current context" option is used.
Fixed for beta 4
-
Excellent! That's amazing! Thanks Clark. Look forward to getting it, hopefully you nailed it!
-
Give beta 4 a try. Should be much better.
-
Using beta4 now on Windows.
I'm trying to search all files in a directory, but it just hangs and doesn't show anything. When I stop the search with the Stop button in Find in Files, it says "Search terminated" and "No files were found to look in".
The "Files" tab is also hanging.
This is in a subdirectory of c:\Program Files(x86), not sure if that makes a difference.
I removed all excludes and unchecked "List current context", still get the hang. I can also stop the "Files" tab and it gives same message as when I stop the "Find in Files" tab.
-
I closed and restarted SlickEdit, the issue went away.
Before closing I tried a directory I own just under c: and it was hanging there too.
After restart no hang in either my dir or the Program Files(x86)
-
Load this debug version of bgsearch.e.
This will dump almost all the parameters passed to the background process (sgrep or vs) to vs.log. When you get a problem, you can take a look at vs.log and post it here.
The previous issue you had was a problem where excludes were getting truncated. This log will let us know exactly what is getting passed to the the search process.
-
Do you have "Sort Find in files search results by filename" turned on? (Tools>Options>Editing>Search).
If you have this on, I recommend you turn it off. When this option is on, it drastically slows down how long it will take before you see any feed back from SlickEdit.
v25 has better output when this option is turned off. v25 outputs the filenames in the order the file system orders the files which is fairly sorted. Prior versions did not do this.
-
I have never enabled "Sort Find in files search results by filename" and I checked that it is OFF in my config. So when I saw this issue that was OFF.
-
I just wanted to rule that out. Just run with that debug version of bgsearch.e. Hopefully, it will help us figure this out.
-
RC 1 has the same logging output but it's off by default. To turn it on, set the macro variable def_mfdebug to 1
-
Would it be possible that I only enable this if/when the issue starts occurring again?
I'd rather not have it enabled all the time and forget that it is on.
So far I haven't had this issue repeat yet, but I think it may have happened on 2 different occasions.
I have RC1 now in Linux. Will change in Windows soon when I start using it.
-
You don't need to have it on all the time. It's up to you. Should not effect performance. vs.log will keep growing but quite slowly.