Code snipped crashes VS - why?

[Chris Stankevitz]

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

[Chris Stankevitz]

> 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)

[Chris Stankevitz]

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 TSEntropyScheduleEvaluatorTSEntropyScheduleEvaluat or
{
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 TSEntropyScheduleEvaluatorTSEntropyScheduleEvaluat or::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]

Chris Stankevitz <ch******@stankevitz.nospamplease.com> wrote:

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

--
Sp******@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]

"Hendrik Schober" wrote

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]

Chris Stankevitz <ch******@stankevitz.nospamplease.com> wrote:

"Hendrik Schober" wrote

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!

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

--
Sp******@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]

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.

"Chris Stankevitz" <ch******@stankevitz.nospamplease.com> wrote in message
news:Or**************@TK2MSFTNGP15.phx.gbl...

"Hendrik Schober" wrote

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

[James Park]

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.

"James Park" <jp**********@SpaMMEhotmail.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...

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.

"Chris Stankevitz" <ch******@stankevitz.nospamplease.com> wrote in message
news:Or**************@TK2MSFTNGP15.phx.gbl...

"Hendrik Schober" wrote

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

[James Park]

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?

"Chris Stankevitz" <ch******@stankevitz.nospamplease.com> wrote in message
news:%2****************@TK2MSFTNGP14.phx.gbl...

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)

[Chris Stankevitz]

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

[Chris Stankevitz]

"James Park" <jp**********@SpaMMEhotmail.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...

I tried the code on VS 2005 Beta 2, and it works fine.

Thanks for checking that for me.

[Chris Stankevitz]

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

"James Park" <jp**********@SpaMMEhotmail.com> wrote in message
news:eK**************@TK2MSFTNGP14.phx.gbl...

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?

"Chris Stankevitz" <ch******@stankevitz.nospamplease.com> wrote in message
news:%2****************@TK2MSFTNGP14.phx.gbl...

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)

[Hendrik Schober]

Chris Stankevitz <ch******@stankevitz.nospamplease.com> wrote:

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

--
Sp******@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]

"Hendrik Schober" <Sp******@gmx.de> wrote

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