vc8.0 crash while compiling boost-1.33.1 serialization library with /analyze

  • Thread starter Thread starter George M. Garner Jr.
  • Start date Start date
G

George M. Garner Jr.

VC8.0 crashes while compiling boost-1.33.1 serialization library (or any
other library that includes the serialization headers) if code analysis
(/analyze) is enabled. This problem did not occur with prior beta releases
of boost-1.33.1 or with the VC8.0 beta. You may want to consider whether
the crash of a dependent tool should be allowed to cause the entire VC8 IDE
to hang or whether this might be a design defect. Given the recent price
increases I respectfully suggest that you fix this problem.

Regards,

George.
 
Yes, please do submit a report. Specifically, we'll need to know what
headers you're including, and what compiler options you're using. I tried
the obvious repro (cl /c /analyze foo.cpp, where all foo.cpp does is
#include <boost/serialization/serialization.hpp>, and it compiled OK. I'm
probably just missing some switches or headers that you're using, though.

-Dave
 
Dave,

I bugged it. The steps to reproduce are below. Note that I am running cl
from the IDE and not from the command line so perhaps the problem is with
the IDE and not cl. Also, make sure that you have the release version of
boost-1.33.1 as this bug cannot be reproduced on earlier betas or release
candidates. These steps are reproducible here so it should work for you as
well.

Regards,

George.

P.S. Code analysis caught some latent bugs in the regex library so it is
really useful when it works.

1. Dowload and install boost-1.33.1 from
http://prdownloads.sourceforge.net/boost/boost_1_33_1.tar.bz2?download.
Make sure that you have the release version of boost-1.33.1. This problem
cannot be reproduced on earlier beta versions of boost.

2. Install Visual Studio 2005 Team Edition for Software Developers.

3. Open the VS IDE. From the file menu click OPEN Project and navigate to
boost_1_33_1\libs\serialization\vc7ide and open
BoostSerializationLibrary.sln.

4. When prompted select to upgrade the solution to VS8.0 and follow the
prompts until the project is upgraded.

5. In the Solution Configuration combo box select "Debug dynamic"

6. Right click on the "Library" project in solution explorer and select
"Code Analysis for C++" from the Advanced tab of the property sheet.

7. Repeat step 6 for the "LibraryW" project.

8. Right click on the "Library" project and select build.

9. Right click on the "LibraryW" project and select build. Crash will while
building LibraryW project.
 
George said:
Dave,

I bugged it. The steps to reproduce are below. Note that I am
running cl from the IDE and not from the command line so perhaps the
problem is with the IDE and not cl. Also, make sure that you have
the release version of boost-1.33.1 as this bug cannot be reproduced
on earlier betas or release candidates. These steps are reproducible
here so it should work for you as well.
Click to expand...

Here's the link to the bug:

http://lab.msdn.microsoft.com/ProductFeedback/viewFeedback.aspx?FeedbackId=FDBK42095

I was able to repro it as well - added my validation & vote to the bug
report.

I also found a workaround - build from the command line with vcbuild. I'm
guessing that the IDE is choking on the gigantic warning messages that
compiling this code produces.

-cd
 
Carl,

The crash doesn't occur when building with vcbuild instead of the IDE. When building this
project, the compiler emits some extremely long warnings (100's or perhaps 1000's of lines of
text for a single warning due to the lengthy template instantiation
Click to expand...
stack). It looks like the IDE is
choking on the gigantic amount of text being stuffed into it by the
Click to expand...
compiler. <

That sounds like a classic heap or stack-based buffer overflow. The
real question is why the IDE (or cl) doesn't check the size of the buffer
that is passed to it. I thought that code analysis and the new SL was
supposed to put an end to this sort of thing.

Regards,

George.
 
George said:
Carl,


(100's or perhaps 1000's of lines of
instantiation stack). It looks like the IDE is
by the compiler. <

That sounds like a classic heap or stack-based buffer overflow. The
real question is why the IDE (or cl) doesn't check the size of
the buffer that is passed to it. I thought that code analysis and
the new SL was supposed to put an end to this sort of thing.
Click to expand...

It could be a buffer overflow, but the flow from CL to the IDE is via a
named pipe, not memory buffers. On the other hand, it could be that
something about the IDE architecture limits the rate at which it can accept
input. Or it may be that the error message parser has an inherent
limitation that makes it unable to eat a single warning that's a megabyte
long. Who knows :) IIRC, there were other similar bugs in the error
window parsing that were reported during the beta, but apparently at least
one survived.

-cd
 
Back
Top