Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

VsChromium Index Details window is empty in VS2019 16.5.2 #60

Closed
kayru opened this issue Apr 8, 2020 · 3 comments
Closed

VsChromium Index Details window is empty in VS2019 16.5.2 #60

kayru opened this issue Apr 8, 2020 · 3 comments

Comments

@kayru
Copy link

kayru commented Apr 8, 2020

I'm on VsChromium-0.9.31 and using a custom vs-chromium-project.txt with Unreal Engine codebase. Indexing and searching functionality works, but index details window contents shows up empty. No projects, no files, etc.
@kayru kayru mentioned this issue Apr 8, 2020
Closed
@rpaquay
Copy link
Contributor

rpaquay commented May 27, 2020

@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.

@kayru
Copy link
Author

kayru commented May 31, 2020

Index details seem to show up with v0.33 pre-release. However after using native find-in-files, the details stop working. Presumably same issue as #61. Potentially some kind of deadlock / soft error affecting the server, making it unresponsive to any further queries.

@rpaquay
Copy link
Contributor

rpaquay commented Jun 3, 2020

Ok, I am resolving this as a duplicate of #61, as the index not working is also a result of the error reproduced in #61. Technically, it could be something else, but we don't have another reproducible case for this bug other than running into #61.

@rpaquay rpaquay closed this as completed Jun 3, 2020
rpaquay added a commit that referenced this issue Jun 9, 2020
@rpaquay
Simplify thread pool to use BlockingCollection
d078f59 
Instead of implementing a custom queue with custom locks, CustomThreadPool
now uses a single BlockingCollection to add elements, and a fixed set
of threads consuming elements concurrently using GetConsumingEnumerable.

This fixes bug #60 and #61, at the expense of losing the ability of shutting
down idle threads in the pool. We decreased the pool size from 10 to 5.
@rpaquay rpaquay mentioned this issue Jun 9, 2020
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@kayru @rpaquay