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

[Guest]

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:strstream 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?

 

[Carl Daniel [VC++ MVP]]

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

 

[Bo Persson]

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:strstream 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

 

[Doug Harrison [MVP]]

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

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.