| Author |
 Topic  |
|
|
Dean Ashton
Ketchup Master
60 Posts |
 Posted - Sep 06 2005 : 06:38:02 AM
|
Hi,
Just installed 1421, and occasionally encounter a hang on load of DevEnv.exe..
Looking at the callstack for the main thread, I have this kind of stuff associated with
<stuff up here, associated with kernel32.dll!WaitForSingleObject>
10 va_x.dll!MigrateDevColor+0x9801a
11 va_x.dll!DllCanUnloadNow+0x5aed9
I had to kill DevEnv to get it back..
OS: Windows XP SP2
IDE: VS.NET 2003 Professional
Cheers,
Dean |
|
|
Henrik
Senior Member
30 Posts |
Posted - Sep 06 2005 : 09:49:58 AM
|
I can confirm this kind of issue.
From time to time the parsing of header files gobbles up 100% cpu time, and eats more and more memory (> 300 MB). In these cases I have to kill the DevStudio, and start it again. With some luck the problem does not show up then...
Config: VS 2003
OS: XP SP 2
Happy Bug Hunting :-)
Henrik |
 |
|
|
Dean Ashton
Ketchup Master
60 Posts |
Posted - Sep 06 2005 : 11:17:53 AM
|
I've had the memory issue before, but I had to kill DevEnv before it brought my PC to a standstill.. Otherwise I'd have posted that information too.
Essentially, when I had this I had the parsing information on the status bar constantly redrawing while parsing windows.h.. I suspect it'd had got into a parse loop, where it continued re-parsing and adding windows.h definitions (and those definitions from files included from windows.h). Nasty.. very nasty.
If I get it again, I'll try to narrow down the cause. |
|
|
|
feline
Whole Tomato Software
United Kingdom
19004 Posts |
Posted - Sep 06 2005 : 3:35:50 PM
|
| so far 1421 is behaving its self for me. can you try telling VA to rebuild its symbol databases and clear its history and cache? it will take a while but hopefully this will clear out any problems. |
zen is the art of being at one with the two'ness |
|
|
|
Henrik
Senior Member
30 Posts |
Posted - Sep 07 2005 : 04:35:21 AM
|
This might be of some help, though this does not happen always:
When VA parses the BOOST 1.32 Headers, it never comes to an ends - it parses the same files over and over again - using more and more memory and all available CPU power ...
Henrik |
|
|
|
Dean Ashton
Ketchup Master
60 Posts |
Posted - Sep 07 2005 : 07:21:40 AM
|
Sounds similar to my problem with windows.h...
Does this happen all the time for you, Henrik? If so, it's a good test case for the guys in Support, I guess |
|
|
|
Henrik
Senior Member
30 Posts |
Posted - Sep 07 2005 : 12:00:49 PM
|
Hi Dean,
not always ... but I have seen the same erratic behaviour more than once - now I have gone back to 1418 - I have to work a bit 
Cheers
Henrik |
|
|
|
feline
Whole Tomato Software
United Kingdom
19004 Posts |
Posted - Sep 08 2005 : 2:31:27 PM
|
Henrik, how often was this happening?
how do you have VA and the IDE setup? i have extracted the boost 1.32 code to my hard drive, "C:\\boost_1_32_0". on the grounds that there are lots of headers in "C:\\boost_1_32_0\\boost" i added this directory to
IDE tools menu -> options -> projects -> VC++ directories -> include files
as a result this directory is showing up in VA's stable include directories list. however i do not see any messages drawn to the status bar about VA parsing boost header files. so i presume you have a slightly different configuration.
Dean if you have any clues it would be useful to hear them |
zen is the art of being at one with the two'ness |
|
|
|
Dean Ashton
Ketchup Master
60 Posts |
Posted - Sep 15 2005 : 08:53:19 AM
|
FWIW, I just had DevEnv.exe hang again (still 1421) with the following callstack:
ntoskrnl.exe!KiSwapContext+0x2f
ntoskrnl.exe!KiSuspendThread+0x18
ntoskrnl.exe!KiDeliverApc+0x124
ntoskrnl.exe!KiSwapThread+0x89
ntoskrnl.exe!KeWaitForSingleObject+0x1c2
ntoskrnl.exe!NtWaitForSingleObject+0x9a
ntoskrnl.exe!KiFastCallEntry+0xfc
ntdll.dll!KiFastSystemCallRet
ntdll.dll!ZwWaitForSingleObject+0xc
kernel32.dll!WaitForSingleObjectEx+0xa8
kernel32.dll!WaitForSingleObject+0x12
va_x.dll+0x13249a
va_x.dll!DllCanUnloadNow+0x5aed9
Will move to 1422 this afternoon, if I'm feeling particularly brave. These new builds, while they may have a whizzy new parsing engine and loads of other changes under the hood, are turning out to be flakier than a lepers armpit. Stability seems to have turned to mush.. they're more like alpha builds than beta. :(
If 1423 (when that appears) isn't any better, then I may end up going back to the last 'proper' release so I can get some work done..
|
|
|
|
Henrik
Senior Member
30 Posts |
Posted - Sep 15 2005 : 12:13:03 PM
|
I will do the same - I will not install any new alpha/beta any more - I'll try to be patient until the next release build is out - I have to get my work done, too.
So Good Luck
Henrik |
|
|
|
weshunt
Junior Member
USA
23 Posts |
Posted - Sep 15 2005 : 2:10:45 PM
|
quote:
Originally posted by Dean Ashton
FWIW, I just had DevEnv.exe hang again (still 1421) with the following callstack:
ntoskrnl.exe!KiSwapContext+0x2f
ntoskrnl.exe!KiSuspendThread+0x18
ntoskrnl.exe!KiDeliverApc+0x124
ntoskrnl.exe!KiSwapThread+0x89
ntoskrnl.exe!KeWaitForSingleObject+0x1c2
ntoskrnl.exe!NtWaitForSingleObject+0x9a
ntoskrnl.exe!KiFastCallEntry+0xfc
ntdll.dll!KiFastSystemCallRet
ntdll.dll!ZwWaitForSingleObject+0xc
kernel32.dll!WaitForSingleObjectEx+0xa8
kernel32.dll!WaitForSingleObject+0x12
va_x.dll+0x13249a
va_x.dll!DllCanUnloadNow+0x5aed9
Will move to 1422 this afternoon, if I'm feeling particularly brave.
I had a very similar crash with 1422 yesterday. I was just typing some text and wham! I saved a minidump with heap and a screenshot of the windows at the time of the crash, if it would be helpful to support. The "minidump" is about 30 MB, though.
-Wes |
|
|
|
feline
Whole Tomato Software
United Kingdom
19004 Posts |
Posted - Sep 17 2005 : 3:02:18 PM
|
| so people know, the developers are looking at the call stacks. |
zen is the art of being at one with the two'ness |
|
|
|
Andrei
Junior Member
10 Posts |
Posted - Sep 19 2005 : 04:18:44 AM
|
Maybe the same case:
under 1422 VS2005 August CTP I had an Issue that when I have started the empty IDE VAssist was accessible (options dialog). After opening a project - it had disabled itself without any message. After a try to enable it - it had hanged the whole environment - only kill process helped. After rebuilding the databases and clear cache everything works. (But how long ? :) ) |
|
|
|
feline
Whole Tomato Software
United Kingdom
19004 Posts |
Posted - Sep 19 2005 : 2:49:44 PM
|
Andrei i had a problem where VA would disable its self when loading a C++ project, but rebuilding the symbol databases fixed this, and it has not reappeared. the working theory is that the error message saying that the databases were corrupt and that VA could not function was not showing up.
however the IDE did not hang on me when this happened. if it happens again (hopefully it wont) could you try and get a call stack please? |
zen is the art of being at one with the two'ness |
|
|
|
feline
Whole Tomato Software
United Kingdom
19004 Posts |
Posted - Sep 19 2005 : 6:48:25 PM
|
| weshunt is the mini dump still available? does zipping it make it noticeably smaller? i will email you, if you can email me a zip of the mini dump in response that might help track this down. |
zen is the art of being at one with the two'ness |
|
|
|
feline
Whole Tomato Software
United Kingdom
19004 Posts |
Posted - Sep 25 2005 : 4:06:09 PM
|
| is it possible for anyone with crashing problems to install 1423 and reproduce these problems with VA's logging enabled? |
zen is the art of being at one with the two'ness |
|
|
|
Dean Ashton
Ketchup Master
60 Posts |
Posted - Sep 26 2005 : 03:41:59 AM
|
| Sorry, I've gone back to 1418, as per my post earlier in this thread. Am I right in assuming that the developers were unable to get anything at all from callstacks in this case? |
|
|
|
feline
Whole Tomato Software
United Kingdom
19004 Posts |
Posted - Sep 26 2005 : 5:19:39 PM
|
| the call stacks were not enough information, but i have now successfully retrieved and passed on the minidump from weshunt which hopefully will help. email did not like a 60meg attachment, which caused us some problems *rolls eyes* |
zen is the art of being at one with the two'ness |
|
|
|
Henrik
Senior Member
30 Posts |
Posted - Sep 28 2005 : 01:47:11 AM
|
Build 1424 reintroduces the endless loop/memory gobbler whilst parsing the boost-headers:
My old post now applies again:
I can confirm this kind of issue.
From time to time the parsing of header files gobbles up 100% cpu time, and eats more and more memory (> 300 MB). In these cases I have to kill the DevStudio, and start it again. With some luck the problem does not show up then...
Config: VS 2003
OS: XP SP 2
Happy Bug Hunting :-)
Henrik |
|
|
|
sean
Whole Tomato Software
USA
2817 Posts |
Posted - Sep 28 2005 : 02:46:36 AM
|
case=787
Turning off the VA option "Parse all headers when opening project" may help (on the Performance page).
|
|
|
|
sean
Whole Tomato Software
USA
2817 Posts |
Posted - Sep 28 2005 : 3:28:17 PM
|
Sorry, case=787 is not reproducible in the release build so does not seem to apply to this.
Henrik, does the problem occur if you open the BoostSerializationLibrary.sln file in boost\\libs\\serialization\\vc7ide and then the demo.cpp in the first project? If you previously had "Parse all headers when opening project" checked, ensure that it is still checked.
If you have your boost installation directory set in your include path, then it will help reproducibilty to click "rebuild" in the performance page of the VA options dlg and restart the IDE so that VA is forced to reparse the files. |
Edited by - sean on Sep 28 2005 3:31:39 PM |
|
|
|
Henrik
Senior Member
30 Posts |
Posted - Sep 29 2005 : 01:34:01 AM
|
Hi sean,
If I load the demo project from boost everything is fine,but "my" situation is different:
A project uses a part of boost 1.32, the includes files are not in the list of stable include files.
The developer studio hangs in and endless loop whilst parsing the boost headers. It parses the sames headers over and over again, eating CPU time and memory.
How should we proceed?
Anyway, disabling "Parse all headers... " seems to help...
CU
Henrik |
|
|
|
sean
Whole Tomato Software
USA
2817 Posts |
Posted - Sep 29 2005 : 01:56:10 AM
|
How does your project know where the boost files are? If boost is not in your stable include list, is the boost directory set as an additional include directory for the project?
How widespread is your use of boost? I mean, would it be difficult to enumerate the #include statements in your project that pull in boost files?
How many projects are in your solution?
If more than one, do they all use boost?
Is it possible to list the headers that are being parsed over and over?
|
|
|
|
sean
Whole Tomato Software
USA
2817 Posts |
Posted - Sep 29 2005 : 02:06:11 AM
|
You could also enable logging and send the log files to support - that should get us the list of files that is cycling over and over.
http://www.wholetomato.com/support/faq.html#log
|
Edited by - sean on Sep 29 2005 02:07:16 AM |
|
|
|
Henrik
Senior Member
30 Posts |
Posted - Sep 30 2005 : 01:14:20 AM
|
I cannot create a relevant log file, since I have reverted to 1418.
But:
Yes, the Boost Headers are declared as additional include files:
..\\COMMON_LIBS\\boost\\include\\boost-1_32
And, currently I use only a fraction of boost, the regex- part:
#include "boost/regex/v4/regex.hpp"
Good Luck,
Henrik
|
|
|
|
sean
Whole Tomato Software
USA
2817 Posts |
Posted - Sep 30 2005 : 02:44:42 AM
|
| No luck... including regex.hpp causes no problem for me. |
|
|
| |
Topic |
|
Topic Locked
