By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
449,220 Members | 1,724 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 449,220 IT Pros & Developers. It's quick & easy.

VC++ .NET 2003: Access violation with /O2 compiler switch; no AV with /O1

P: n/a
VC++ .NET 2003: Access violation with /O2 compiler switch; no AV with /O

Hi
I'm in the process of narrowing down a problem, and I have reduced the code involved to the following
If someone could do the following and verify what I am seeing (and offer any insight!), I would appreciate it
Simply create a new "Win32 Console Project" in VC++ .NET 2003. On the "Application Settings" page, check the "Empty project" box. Click "Finish"
Add a new C++ source file, and paste in the following code
//=================
#include <strstream
#include <malloc.h

void Fn( void

_alloca( 100 )
std::ostrstream oss
oss << std::ends
oss.str()
oss.freeze( false )
throw std::string()
int main( void

tr

Fn()

catch( std::string&
return 0

//=================
I know the code doesn't make a whole lot of sense as it stands, but I am trying to reduce the code required to repro the problem to a minimum. When I build a "Release" build of the project (with the default project settings, which includes the default /O2, or "Maximize Speed" optimization) and run it, I get an AV in ostrstream::~ostrstream ("Access violation reading location 0x00000004"). Same result with /Ox ("Full Optimization"). However, if I change the optimization to /O1 ("Minimize Size") or /Od ("Disable [Optimizations]"), the code runs "just fine" (no AV)

If I do the same thing with VC++ .NET 2002, the code runs "just fine" with all optimization settings (/Od, /O1, /O2, /Ox)

Any thoughts?
Nov 17 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
This definitely looks like a codegen bug. I was able to reproduce the crash
compiling the VC7.1, but the bug appears to be fixed in the Whidbey (VS.NET
2005) alpha. If this bug is causing you problems in production code, you
should contact Product Support Services to see if there's a
hotfix/QFE/workaround available.

-cd

Binary wrote:
VC++ .NET 2003: Access violation with /O2 compiler switch; no AV with
/O1

Hi,
I'm in the process of narrowing down a problem, and I have reduced
the code involved to the following.
If someone could do the following and verify what I am seeing (and
offer any insight!), I would appreciate it.
Simply create a new "Win32 Console Project" in VC++ .NET 2003. On
the "Application Settings" page, check the "Empty project" box.
Click "Finish".
Add a new C++ source file, and paste in the following code:
//==================
#include <strstream>
#include <malloc.h>

void Fn( void )
{
_alloca( 100 );
std::ostrstream oss;
oss << std::ends;
oss.str();
oss.freeze( false );
throw std::string();
}

int main( void )
{
try
{
Fn();
}
catch( std::string& )
{
}
return 0;
}
//==================
I know the code doesn't make a whole lot of sense as it stands, but I
am trying to reduce the code required to repro the problem to a
minimum. When I build a "Release" build of the project (with the
default project settings, which includes the default /O2, or
"Maximize Speed" optimization) and run it, I get an AV in
ostrstream::~ostrstream ("Access violation reading location
0x00000004"). Same result with /Ox ("Full Optimization"). However,
if I change the optimization to /O1 ("Minimize Size") or /Od
("Disable [Optimizations]"), the code runs "just fine" (no AV).

If I do the same thing with VC++ .NET 2002, the code runs "just fine"
with all optimization settings (/Od, /O1, /O2, /Ox).

Any thoughts?

Nov 17 '05 #2

P: n/a

"Binary" <an*******@discussions.microsoft.com> skrev i meddelandet
news:B8**********************************@microsof t.com...
VC++ .NET 2003: Access violation with /O2 compiler switch; no AV with /O1

Hi,
I'm in the process of narrowing down a problem, and I have reduced the code involved to the following. If someone could do the following and verify what I am seeing (and offer any insight!), I would appreciate it. Simply create a new "Win32 Console Project" in VC++ .NET 2003. On the "Application Settings" page, check the "Empty project" box. Click "Finish". Add a new C++ source file, and paste in the following code:
//==================
#include <strstream>
#include <malloc.h>

void Fn( void )
{
_alloca( 100 );
std::ostrstream oss;
oss << std::ends;
oss.str();
oss.freeze( false );
throw std::string();
}

int main( void )
{
try
{
Fn();
}
catch( std::string& )
{
}
return 0;
}
//==================
I know the code doesn't make a whole lot of sense as it stands, but I am trying to reduce the code required to repro the problem to a minimum. When
I build a "Release" build of the project (with the default project settings,
which includes the default /O2, or "Maximize Speed" optimization) and run
it, I get an AV in ostrstream::~ostrstream ("Access violation reading
location 0x00000004"). Same result with /Ox ("Full Optimization").
However, if I change the optimization to /O1 ("Minimize Size") or /Od
("Disable [Optimizations]"), the code runs "just fine" (no AV).
If I do the same thing with VC++ .NET 2002, the code runs "just fine" with all optimization settings (/Od, /O1, /O2, /Ox).
Any thoughts?


There are some limitations to the use of _alloca in the Visual Studio help.
One of these is:

"Security Note In Windows XP, if _alloca is called inside a try/catch
block, you must call _resetstkoflw in the catch block."

If /O2 happens to inline the functions call Fn(), then maybe _alloca
actually is inside the try/catch block?
Bo Persson

Nov 17 '05 #3

P: n/a
Binary wrote:
VC++ .NET 2003: Access violation with /O2 compiler switch; no AV with /O1 <snip>When I build a "Release" build of the project (with the default project settings, which includes the default /O2, or "Maximize Speed" optimization)


I can't say if using /O1 here avoided the problem or merely disguised it,
but many people consider /O1 a better default option than /O2. YMMV, but
after switching to /O1 years ago, I've run into very few optimizer bugs. In
addition, if "smaller code" is achieved to a significant degree, I'd
hypothesize that it can sometimes be faster due to cache and paging effects.
In any event, it's very likely fast enough, such that sticking with /O2 as
the default doesn't buy you much.

--
Doug Harrison
Microsoft MVP - Visual C++
Nov 17 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.