| Author |
 Topic  |
|
|
tfooy
New Member
Belgium
8 Posts |
 Posted - Nov 27 2013 : 03:45:32 AM
|
This morning when I started Visual Studio, I noticed that Visual Assist hangs/cycles during the startup. It keeps eating CPU and seems to be stuck on the stage "VA: Sorting symbols...".
Previous evening I have left my VS open, but a nightly build procedure has recreated its active solution file (.sln) and its osee.vcxproj file. In the morning I just closed VS and started again to have the up-to-date solution. That is when the problem started.
It is a quite large solution (+25000 files). I have already tried the following:
- In the Options dialog, Performance node: clicked the Clear button and the Rebuild button. However after restarting VS the rebuild does not seem to happen, because that would trigger a lot of "VA: Parsing xx.cpp" messages and I don't get any of them: VA immediately starts to sort symbols.
- When I disable "Parse all files when opening a project" then VA doesn't hang anymore at startup, but it is not usable either: it doesn't recognize any symbols, include paths, ...
- I enabled logging and took a look at the generated +60MB log file. I thinks it contains a good clue: about 99% of the file is filled with this message: "UI: DBF::GAO fileID not located tid(343c) bd891c41 F:\\Development\\LAST\\all_of_my_header_and_source_files"
So it looks as if somehow VA is not able to get a hold of the files anymore.
Has this happened before? Can you give me some hints to try to resolve this problem? At this moment I can't think of another solution anymore. And my working environment is currently also not usable anymore...
Thanks in advance,
Tim |
|
|
tfooy
New Member
Belgium
8 Posts |
Posted - Nov 27 2013 : 05:02:36 AM
|
After a couple of hours eating of CPU and lots of restarts of Visual Studio, the problem seems to have fixed itself.
I hope this will not be a recurring theme... |
 |
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Nov 27 2013 : 10:17:54 AM
|
Apologies for the problem, this should not have happened. I don't recognise this problem description, so I don't think this is a known problem.
Which IDE, OS and version of VA are you using?
Do you often leave the IDE open while the solution and project files are updated from source control? Or do you normally close the IDE before doing this update?
Do your code files live on a normal local drive, or some form of network or mapped drive? |
zen is the art of being at one with the two'ness |
|
|
|
tfooy
New Member
Belgium
8 Posts |
Posted - Nov 28 2013 : 02:18:43 AM
|
I use Visual Studio 2010 SP1 and Visual Assist 10.7.1940 on Windows Server 2008 R2 Enterprise SP1 (terminal server). Normally I don't leave the IDE open, precisely because I know that the nightly build will update the sources and recreate the project files. Without restarting VS with the new project files, newly added source files will not be known by VS and thus VA. The source files live on a normal local drive.
Last night I closed the IDE and this morning on startup the problem did not reoccur, so I can't really give you a reproduction scenario. All the better, I guess :-) |
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Nov 28 2013 : 1:27:19 PM
|
Hopefully this was a one off problem, but if it happens again you can try closing the IDE, making sure all instances of devenv.exe have been closed, and manually deleting VA's symbol database is probably worth a try.
Normally I would not recommend this, but this is something of an extreme situation. This FAQ will help you figure out where VA has been installed for VS2010:
http://docs.wholetomato.com?W282
Inside the install directory you will find a fairly large "Data" directory. Delete its content, and then reload the IDE. Please be aware this will trigger a complete rescan of your stable include directories and solution by VA. |
zen is the art of being at one with the two'ness |
|
|
|
tfooy
New Member
Belgium
8 Posts |
Posted - Nov 29 2013 : 03:16:41 AM
|
Just out of curiosity I have taken a look at the install location, and indeed found the VA_X.dll file there. However, I don't have the Data directory that was supposed to be there. Could this be a sign of trouble? Is it somehow shared with the other users on the terminal server?
VA seems to work just fine though. |
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Dec 04 2013 : 6:55:34 PM
|
I have not tested terminal server myself, so its possible this is a factor. Another option is that someone has used the registry setting to move the VA symbol database to a different location. This is explained here:
http://docs.wholetomato.com?W332 |
zen is the art of being at one with the two'ness |
|
|
|
tfooy
New Member
Belgium
8 Posts |
Posted - Dec 06 2013 : 05:56:25 AM
|
Indeed, the location of the database was moved to a central directory on the terminal server.
Sadly, the problem has reoccurred the last two days. I have taken a look at the startup.log file that was in the database directory, and it contains more than 6000 lines like this:
GetSymDefStrs idx e:\\VisualAssistCache\\vs10_1\\CPP\\Db35Ds.db is corrupt, fid=0x77d89cdb, sp=0x14, rel=0x37bbad, act=0x1df1bb77 tid=20272 uiTid=15920:280 12/6/2013 10:59:52 0x4f30
And this got me thinking: is it a problem that all users of the terminal server share the same VA symbol database? Note that they all have different source checkouts and releases to work on. Is Visual Assist able to handle this? Does it allow multiple VS instance to concurrently start up and load/change the symbol database?
If not, then I guess we need to specify a different symbol database location for each user. Which, according to the information I found in the topic that you mentioned previously, should work fine by using the %USERNAME% environment variable in the registry setting for the location. |
Edited by - tfooy on Dec 06 2013 08:26:04 AM |
|
|
|
tfooy
New Member
Belgium
8 Posts |
Posted - Dec 06 2013 : 08:20:51 AM
|
| As a side note: this morning I noticed the following behavior: first VA was eating a single CPU for about 50 minutes, crippling the responsiveness of VS (I guess it was trying to deal with the database corruption a that time), and only afterwards it started the phase of parsing files (which uses 8 cores) and that only took one or two minutes. |
|
|
|
sean
Whole Tomato Software
USA
2817 Posts |
Posted - Dec 06 2013 : 09:49:57 AM
|
Visual Assist X has not been tested under Windows Terminal Services and is not officially supported in that environment. You may have some success using our product this way, but we cannot guarantee your results.
quote:
Originally posted by tfooy
is it a problem that all users of the terminal server share the same VA symbol database?
Yes.
quote:
Is Visual Assist able to handle this?
No.
quote:
Does it allow multiple VS instance to concurrently start up and load/change the symbol database?
It supports multiple VS instances per-user to share the symbol database directory. It does not support multiple users sharing the same directory.
We will update the UserDataDir description to indicate that it is a per-user setting which can not be shared. |
Edited by - sean on Dec 06 2013 09:51:17 AM |
|
|
| |
Topic |
|
VA is stuck during startup of VS
