You guys are going to like this. I work on a very large (500,000 line)
native C++ project. VS started crasing recently and I've similified it down
to fifty lines (took me six hours).
Why is the debugger crashing?
Microsoft Visual C++ .NET 69462-270-0000007-18536
Steps to reproduce:
1. Download/extract sample.zip
2. Open sample.sln
3. Build the project
4. Place a breakpoint in SlamemApp.cpp line 44 (at function "f"). This is
required. ALso note that the function "f" is never called.
5. Launch the app in the debugger
6. VS stops responding
There are many things I can rename/reorder/eliminate to "fix" the problem,
but I don't want to bias your analysis.
Thanks so much for your help!
Zip file here:
http://www.stankevitz.com/visualstudio/sample.zip
Chris
> Why is the debugger crashing?
I may be on to something here. Could it be that when a function's mangled
name reaches 766 characters that VS crashes when you place a breakpoint in
the function?
Length_of_mangled_name (Works)
716 (Works)
736 (Works)
761 (Works)
766 (Does not work)
771 (Does not work)
776 (Does not work)
786 (Does not work)
846 (Does not work)
James Park - 28 Jul 2005 18:04 GMT
I was feeling pretty smart until I came across this post, haha. I guess I
should read all the posts in a thread before I reply. :) I'm a little
confused though. If you already had a handle on the problem, why did you
still need a workaround?
>> Why is the debugger crashing?
>
[quoted text clipped - 11 lines]
> 786 (Does not work)
> 846 (Does not work)
Chris Stankevitz - 29 Jul 2005 00:11 GMT
I do not have a handle on the problem. I do not understand why/how it
happens. I understand several things I can do to make the symptoms go away
in this simple test case though (like rename the class).
Renaming the class and moving the declaration of structures around isn't an
option in my real case so I am trying to figure out what is really wrong.
Thanks for the help,
Chris
>I was feeling pretty smart until I came across this post, haha. I guess I
>should read all the posts in a thread before I reply. :) I'm a little
[quoted text clipped - 16 lines]
>> 786 (Does not work)
>> 846 (Does not work)
Maybe I should have just posted my code. This code freezes my version of VS
when I place a breakpoint inside the function "f". Notice function "f" is
never called. I generated this code by shrinking down my 500k line app to
these 40 lines.
I am not convinced that the issue is due to the length of the mangled name
because I can construct certain functions with much longer mangled name
lengths and it works fine.
While my original version (in the 500k line app) had a much shorter class
name, in the transition to the short version I had to increase the length of
the class name to have VS die.
Thanks for your help,
Chris
int main()
{
return 0;
}
#include <list>
#include <map>
class A;
class B;
class TSEntropyScheduleEvaluatorTSEntropyScheduleEvaluator
{
struct S {};
enum E {};
void f(
B& a,
std::map<unsigned, int>&,
std::map<unsigned, A*>&,
std::map<unsigned, std::list<S*> >&,
std::map<unsigned, std::map<unsigned, A*> >&,
std::map<unsigned, double>&,
E g);
};
void TSEntropyScheduleEvaluatorTSEntropyScheduleEvaluator::f(
B& a,
std::map<unsigned, int>&,
std::map<unsigned, A*>&,
std::map<unsigned, std::list<S*> >&,
std::map<unsigned, std::map<unsigned, A*> >&,
std::map<unsigned, double>&,
E g)
{
}
Hendrik Schober - 28 Jul 2005 15:11 GMT
> Maybe I should have just posted my code. This code freezes my version of VS
> when I place a breakpoint inside the function "f". [...]
I checked this (with VC7.1) and can confirm
the bug.
The IDE indeed behaves strange when I put a
breakpoint into the function. Funny enough,
it doesn't even really freeze -- I can still
operate it. (For example, I was able to open
the breakpoint window and clear the breakpoint)
It's just that it seems to wait for something.
(It's not using much CPU resources either.)
> [...]
Schobi

Signature
SpamTrap@gmx.de is never read
I'm Schobi at suespammers dot org
"Coming back to where you started is not the same as never leaving"
Terry Pratchett
Chris Stankevitz - 28 Jul 2005 16:00 GMT
> I checked this (with VC7.1) and can confirm
> the bug.
> The IDE indeed behaves strange when I put a
> breakpoint into the function.
Hendrik,
Thanks for taking a look at this for me. Do you have any idea what how I
can work around this? This particular problem is causing my team a lot of
headache because we need to debug this function!
Thanks,
Chris
Hendrik Schober - 28 Jul 2005 16:17 GMT
> > I checked this (with VC7.1) and can confirm
> > the bug.
[quoted text clipped - 6 lines]
> can work around this? This particular problem is causing my team a lot of
> headache because we need to debug this function!
I think you should try to solve this with
MS support. (AFAIK they don't charge if
it's a MS bug you're running into.)
> Thanks,
>
> Chris
Schobi

Signature
SpamTrap@gmx.de is never read
I'm Schobi at suespammers dot org
"Coming back to where you started is not the same as never leaving"
Terry Pratchett
James Park - 28 Jul 2005 16:42 GMT
The same problem is cropping up here too. I tried the code on VS 2005 Beta
2, and it works fine. I think I found a workaround though; try moving the f
function body inside the class.
>> I checked this (with VC7.1) and can confirm
>> the bug.
[quoted text clipped - 10 lines]
>
> Chris
James Park - 28 Jul 2005 17:45 GMT
Actually, that workaround will stop working when you actually try to use f,
so pretend I didn't mention it. :) But fret not, this time I think I've
found the real problem. I'm not smart enough to know why, but VS 2003 might
be having a problem with the length of your method prototype. Comment out an
argument or hack off a few characters from the class name (at least two),
and voila, the problem goes away.
> The same problem is cropping up here too. I tried the code on VS 2005 Beta
> 2, and it works fine. I think I found a workaround though; try moving the
[quoted text clipped - 14 lines]
>>
>> Chris
Chris Stankevitz - 28 Jul 2005 20:16 GMT
> problem with the length of your method prototype
Thanks for your input! I need all the help I can get.
There are many things that "fix" this problem, including
1. Shorten class name
2. move struct declaration outside of the class
3. Change random things to "ints" (e.g. change the enum argument to an int
argument)
There are 4,000 other functions in my app with longer "mangled" names that
work fine so I suspect the root problem is not "the function prototype is
too long". :-/
I appreciate your input,
Chris
Hendrik Schober - 29 Jul 2005 10:51 GMT
> > problem with the length of your method prototype
> [...]
> There are 4,000 other functions in my app with longer "mangled" names that
> work fine so I suspect the root problem is not "the function prototype is
> too long". :-/
Nevertheless, VC does have Problems with long
identifiers as employed by templates. I just
spent many days trying to hunt for the cause
of an ICE which prevented us from porting a
fairly important piece of code to VC. In the
end it was the length of a particular class
template instance. The current VC8 beta did
compile the code successfully, but took ages
for this one file.
I was able to trigger CW9.5 to emit the full
type name in an error message and it was >15kB
long. When I managed to get it down to <10kB,
VC accepted the type in the test project I had
set up (although taking >5min to compile), but
still crashed in the real code.
In the end I had to give up and circumvent the
problem by re-designing the code in question.
It's now less flexible, but at least it works
for the cases we need it right now. When VC8
hits the shelfs, we can remove the workaround.
> [...]
> Chris
Schobi

Signature
SpamTrap@gmx.de is never read
I'm Schobi at suespammers dot org
"Coming back to where you started is not the same as never leaving"
Terry Pratchett
Chris Stankevitz - 29 Jul 2005 18:45 GMT
> Nevertheless, VC does have Problems with long
> identifiers as employed by templates.
Thanks for your help on this issue. I rewrote my function to avoid long
identifiers.
Chris
Chris Stankevitz - 28 Jul 2005 20:18 GMT
> I tried the code on VS 2005 Beta 2, and it works fine.
Thanks for checking that for me.