| T O P I C R E V I E W |
| Jefe |
Posted - Apr 05 2006 : 09:36:13 AM
Hi,
Two month ago we migrate our code from VS6 to VS2005, very large amount of code around 4000 source files in 11 projects. We had to install a new version of VA and we did to the public beta 1438.
On some developers PC after installing the VA upon debugging the Visual Studio 2005 started to ignore some breakpoints. The scenario is this:
- Debug the code (with breakpoints)
- Change a file that has breakpoints in it. not necessarily in a code related to the breakpoint.
- Recompile it and build the exe again.
- Debug the code again.
The debugger doesn't stop in the previous breakpoints (in the recompiled file) although they seem valid in the file and in the breakpoints window. In order to enable them the breakpoints need to be removed and set again.
After the release of the new version 1444, all the developers upgraded to this version (upgrade not uninstall & install) and about half of them feel that the problem is gone. Still more than 10 developers suffer and reproduce this problem.
Is this a known issue?
Do I need to uninstall the previous version before installing the new one? And if so does the uninstall totally removes all the installed files and registry entries? Else how can I achieve that?
More info:
We are all working on win XP SP2, p4 CPU 3.0-3.4G and 2G RAM. We have another add-in IncrediBuild but working without it didn't help. Removing the VA caused the problem to disappear.
I've attached the info from the VA about (without the license of course) if it shades any light.
VA_X.dll file version 10.2.1444.0 built 2006.03.12
VAOpsWin.dll version 1.3.2.4
VATE.dll version 1.0.4.15
DevEnv.exe version 8.0.50727.42
msenv.dll version 8.0.50727.42
Font: Courier New 17(Pixels)
Comctl32.dll version 6.0.2900.2180
WindowsNT 5.1 Build 2600 Service Pack 2
Single processor
Platform: Win32
Stable Includes:
C:\\Program Files\\Microsoft Visual Studio 8\\VC\\include;
C:\\Program Files\\Microsoft Visual Studio 8\\VC\\atlmfc\\include;
C:\\Program Files\\Microsoft Visual Studio 8\\VC\\PlatformSDK\\include;
C:\\Program Files\\Microsoft Visual Studio 8\\SDK\\v2.0\\include;
Library Includes:
C:\\Program Files\\Microsoft Visual Studio 8\\VC\\atlmfc\\src\\mfc;
C:\\Program Files\\Microsoft Visual Studio 8\\VC\\atlmfc\\src\\mfcm;
C:\\Program Files\\Microsoft Visual Studio 8\\VC\\atlmfc\\src\\atl;
C:\\Program Files\\Microsoft Visual Studio 8\\VC\\crt\\src;
|
| 11 L A T E S T R E P L I E S (Newest First) |
| feline |
Posted - Jun 01 2006 : 5:50:18 PM
have you asked the people who make IncrediBuild if they have ever heard of anything like this before? it is a bit of a long shot to be honest, but it may be worth a try. |
| support |
Posted - May 31 2006 : 9:16:41 PM
We're at a bit of a loss since VA X does not read or touch idb, pdb or suo files.
We can't imagine how we effect breakpoints but we'll keep thinking. |
| feline |
Posted - May 31 2006 : 3:51:35 PM
to be honest i am not really sure. i suspect it is not as simple as which files are effected, since in order to work VA has to hook its self into the IDE all over the place. unfortunately this leaves plenty of room for clashes with other addin's.
i shall ask support, hopefully they can shed some light on this. |
| Jefe |
Posted - May 31 2006 : 09:54:49 AM
Hi feline,
Time is not the problem here, the problem is that it is only reproducible on our biggest project.
The difference in the IncrediBuild compilation output is as I mentioned before the .idb and .pdb files. Does VA use these files? The main pdb file (executableName.pdb) is not affected.
As far as I could see the breakpoints are kept in the suo file, does VA affects this file in any way.
If I remove the add-in registry key and relaunch the VS all my breakpoints are hit, when I reinstall the regkey they disappear again.
Regards |
| feline |
Posted - May 18 2006 : 3:21:26 PM
this is most odd. my first instinct is to suspect that IncrediBuild is a factor, for two reasons.
a) it effects how things build, which might effect how the debugger works, thus effecting break points
b) it works for me and i do not have IncrediBuild installed 
however if removing IncrediBuild, or disabling it, makes no difference then that seems to rule this out.
do you have the time to produce a small test project and see if the same thing happens there? re-reading your first post the rebuild step seems to be critical to reproducing this. i wonder if VA and IncreadiBuild are effecting each other in some manor. |
| Jefe |
Posted - May 18 2006 : 02:40:57 AM
Oops, this is what happens when working to late.
Here are the screen shots.
Debug while VA is installed
http://public.fotki.com/worcel/breakpoints_with_va/breakpoints_with_va.html
Debug after removing the VA
http://public.fotki.com/worcel/breakpoints_with_va/breakpoints_without_va.html
Sorry for not placing them in the message, I tried but this site changed the links of the photos so I used this option.
The only add-on I use (other then VA) is as I mentioned before IncrediBuild which is a tool that does parallel compilation. I was using VA and IncrediBuild in the VS6 also and it was ok. This tool only deals with the compilation itself, no code parsing or anything like this. And as I mantioned before removing it didn't change a thing while removing the VA did. Also we have a group of developers that are working with IncrediBuild and without the VA on the same code in a different location and they are not suffering from this problem.
The only output difference between IncrediBuild compilation and VS compilation is that instead of receiving 1 vc80.idb and 1 vc80.pdb files you get multiple files according to the number of stations involved in the build process (vc80_ib1.pdb, vc80_ib2.pdb... ) |
| kevinsikes |
Posted - May 18 2006 : 12:47:54 AM
Are they conditional breakpoints? I have seen the following scenario:
Break on line 1234 when foo==5
Breakpoint hits. Hooray!
Change the condition while the program is still running (not in break):
Break on line 1234 when foo==0
Now the breakpoint does NOT hit, even when I know for a fact that foo==0. Ack!
Here's the rub: Sometimes the above scenario works. Sometimes it doesn't. Who knows? Are ya feelin lucky? I have learned to change conditional breakpoints only when in break mode; this seems to appease the debugger.
|
| feline |
Posted - May 17 2006 : 4:41:16 PM
you will need to host the picture somewhere online before we can see it.
as for break points, i use them all the time in VS2005 myself, with VA enabled, and i have never had this problem. do you have any other addin's installed? anything "odd" about the machines or the software installed on them? how reproducible is this problem? does it happen in more than one cpp file or solution? |
| Jefe |
Posted - May 17 2006 : 12:41:05 PM
Hi again,
Your previous responses convinced me and I started to look for the solution in a different place, but it wasn't. Just an hour ago one of our developers showed me a proof that it is indeed the VA causing the breakpoint problem.
I've attached the breakpoint window from it's PC while debugging, as you can see most of the breakpoints do not have the address value, also they do not have the '(Currently X) and the correct function name (the member function name lacks its class).
Then (just to make sure) I've closed and restarted the VS2005 and start debug again same thing. After that I've closed the VS2005 again and removed the VA, started the VS2005 and started debug, all the breakpoint Address value was there (same with the other values). After that I've installed again the VA and the values where gone again. Of course when the values weren't present the debugger didn't stop in the breakpoint.
Does the VA do any manipulations on the suo file?
How do you explain this if you still claim that the VA is not causing this?
thanks,
 |
| feline |
Posted - Apr 05 2006 : 3:53:25 PM
i have come across reports of break points simply not working before, but the main person who reported this has never used VA. it seems that sometimes the IDE can do this on its own.
can one of the developers with this problem can try disabling VA and see if that makes any difference? |
| support |
Posted - Apr 05 2006 : 1:26:31 PM
We cannot recall receiving any reports of this problem. We would expect a fair number of complaints if it was common, particularly since we've been support VS2005 for six months or so.
It's rare you would ever need to uninstall VA X before installing a new build. About the only good reason is to clear your VA X key from the registry.
On the chance this is related... you might exit your IDE and see if you have a devenv.exe.manifest you can remove. Some earlier builds of VA X installed the file and while supposedly harmless to the IDE (it controls themes,) some users experience odd behavior in the IDE when the file exists. Check the directory in which the devenv.exe for vs8 exists.
|
