Code snipped crashes VS - why?

  • Thread starter Thread starter Chris Stankevitz
  • Start date Start date
C

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

}
 
Chris Stankevitz said:
Maybe I should have just posted my code. This code freezes my version of VS
when I place a breakpoint inside the function "f". [...]
Click to expand...

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.)
[...]
Click to expand...


Schobi

--
(e-mail address removed) 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
 
I checked this (with VC7.1) and can confirm
the bug.
The IDE indeed behaves strange when I put a
breakpoint into the function.
Click to expand...

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
 
Chris Stankevitz said:
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!
Click to expand...

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
Click to expand...


Schobi

--
(e-mail address removed) 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
 
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.
 
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.
 
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?
 
problem with the length of your method prototype
Click to expand...

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
 
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
 
Chris Stankevitz said:
problem with the length of your method prototype
Click to expand...
[...]
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". :-/
Click to expand...

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
Click to expand...


Schobi

--
(e-mail address removed) 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
 
Hendrik Schober said:
Nevertheless, VC does have Problems with long
identifiers as employed by templates.
Click to expand...

Thanks for your help on this issue. I rewrote my function to avoid long
identifiers.

Chris
 
Back
Top