search

chromium / vs-chromium

A Visual Studio extension containing a collection of tools to help contributing code to the Chromium project.
BSD 3-Clause "New" or "Revised" License
310 stars 88 forks source link

VsChromium search stops working after native find-in-files is performed in VS2019 16.5.2 #61

Closed kayru closed 4 years ago

kayru commented 4 years ago

Another issue with the same project setup as #60 (VsChromium-0.9.31, UE4 codebase with custom project config). Code search works until native visual studio find-in-files operation is done via ctrl+shift+f. All functionality stops working after that. Code search does not seem to perform any operations and opening VsChromium Indexing Server Information window gets stuck on "Please Wait" message.

Please let me know if there are any additional diagnostics / logs that I could provide to help you reproduce and investigate the issue.

kayru commented 4 years ago

Just confirmed that this issue reproduces in other projects too, so seems like there is nothing specific to UE4.

rpaquay commented 4 years ago

@kayru

Does this still happen?

One thing that could help is to attach the log files to this bug, just to see if there is a meaningful error logged in there. The log files are located in "%LOCALAPPDATA%\VsChromium". Up to 10 files of 2MB files each are use for logging.

VsChromium.log is used for information/warning/error level logging. VsChromium.errors.log is used for warning/error level logging only.

torlack commented 4 years ago

I'm seeing this very issue now. While I can't include the log files due to sensitive information, I can explain what I am seeing.

First, there are no errors in the error log file other that one regarding a locked file in the source tree that we get during solution load.

After solution load, nothing of interest is in the log file. After I do a VsChr search, I can see the search results in the log file (229 lines of log).

With in a few seconds after I do a VS find in files, the log file starts growing rapidly. The file contains a massive series of "Register path", "Unregister path", "FlushFileRegistrationQueueTask", "Request # of type RegisterFileRequest", and "Request # of type UnregisterFileRequest" log lines.

It appears to be registering and then un-registering almost every file in the solution.

By the time I force quit VS, the VsChr log file was nearly 8000 lines long with this spam. 1921 requests were in the log file.

rpaquay commented 4 years ago

I see, this is very useful. It is likely that VS is behaving this way for some odd reason related to your configuration and/or solution, but it is clearly an issue with VsChromium, which should be able to deal with this amount of changes.

Would you mind trying the v0.33 pre-release (https://github.com/chromium/vs-chromium/releases/tag/v0.9.33)? It does have an improvement to this kind of VS behavior, so maybe this will address your problem while I investigate the root cause of this issue.

torlack commented 4 years ago

It didn't help.

If you need me for anything, let me know. Love the tool.

kayru commented 4 years ago

Yes, the issue is still present.

Installed v0.33 pre-release. Opened a relatively small project, confirmed vs-chromium search works via ctrl+shift+;, invoked native find-in-files via ctrl+shift+f, confirmed that vs-chromium becomes broken/stuck as before. Logs: https://gist.github.com/kayru/1f6cf8b4a1a3c74d6eaf7ee72a4b7f5b

rpaquay commented 4 years ago

Thank you @kayru, I am able to reproduce the issue. I am working on a fix.

Fyi, the line of code causing the bug is https://github.com/chromium/vs-chromium/blob/master/src/Server/Threads/ThreadObject.cs#L46

In some case, the _currentTask field is reset to null after a new task has been scheduled by another thread. Multi-threading is hard...

rpaquay commented 4 years ago

Fixed in https://github.com/chromium/vs-chromium/releases/tag/v0.9.34

rpaquay commented 4 years ago

@kayru There is a new pre-release (0.9.34) that should fix all issues related to index not working, etc. after performing a "Find in Files". If you have time to try it out, please let me know if it did indeed fix the problems you were seeing, so that I can make this pre-release an "official" release.

rpaquay commented 4 years ago

@torlack Same comment: There is a new pre-release (0.9.34) that should fix all issues related to index not working, etc. after performing a "Find in Files". If you have time to try it out, please let me know if it did indeed fix the problems you were seeing, so that I can make this pre-release an "official" release.

kayru commented 4 years ago

@rpaquay Unfortunately it does not look like the fix worked. As before, the the indexing server information window stops working as soon as built-in search starts and code search queries don't work.

Edit: curiously the issue is not reproducible in a tiny project, only in our main big UE4 project.

rpaquay commented 4 years ago

@kayru Sorry about that, I thought I had fixed the root cause, as this was fixed in the small project I was using to reproduce. Do you see errors in the error log file? Anything you can share?

kayru commented 4 years ago

Nope, no errors in the logs. I also noticed that in a "medium sized" project, vs-chromium hangs but eventually recovers. I will try to see if the issue is reproducible in the GitHub version of UE4, in which case you may be able to just use that.

rpaquay commented 4 years ago

@kayru

Oh, it is interesting it eventually recovers on a medium project. It could be that there are so many open/close files requests that VsChromium is temporarily overwhelmed and becomes "unresponsive" for a while, i.e. the new requests are still technically processed, but a while later after VsChromium had time to catch up. In the case of your big UE4 project, it could be that it takes minutes for VsChromium to catch up.

On your big UE4 project, when VsChromium is "unresponsive", do you see spam activity in the regular log file for a long time, or do you see no activity at all?

If it is the case that VsChromium is jus overwhelmed with too many requests, then I will have to work on an additional fix to address that.

rpaquay commented 4 years ago

I was able to reproduce the behavior mentioned in a previous comment. When "Find in Files" goes through hundred of thousand of source files, VsChromium is overwhelmed with File/Close requests, and takes more than 30 min to catch up.

(It is somewhat amusing how VsChromium ends up showing search results after 30 min or so :))

rpaquay commented 4 years ago

@kayru

The issue with large projects should be fixed in release 0.9.35: https://github.com/chromium/vs-chromium/releases/tag/v0.9.35

kayru commented 4 years ago

Confirmed. Seems to work with UE4 solution now. Thank you! I'll test this build for the few days before knowing for sure it's robust, but looks promising :)

kayru commented 4 years ago

I'm happy to confirm that 0.9.35 has been solid for me during daily use for the past week. Ship it :)

rpaquay commented 4 years ago

Great. I will release it this week.

torlack commented 4 years ago

I finally had a chance to test the fix and can confirm it works on a Frostbite game. So that is two massive game solutions known to work now :D

rpaquay commented 4 years ago

@torlack Thank you for confirming.

Fyi, I just released 0.9.35, but I noticed issue #69 (VsChromium does not show a banner when a new update is available), so I am going to make a new release shortly to fix that issue too. This issue does not affect you since you already have the latest version (the binary of the 0.9.35 release is the same binary you have been using), but it will affect you in the future, as you won't get a banner in Code Search when a new version of VsChromium is available.

rpaquay commented 4 years ago

Ok, I released version 0.9.36, which solves the "no update banner" issue (that will show up when the next release is available of course). I am closing this bug as fixed.