bug: stack overflow in std::auto_ptr

[Bronek Kozicki]

Hi


Please try this code. I think that it's perfectly legal. However when
compiled under MSVC71 stack overflow happens in first line of main, thus
second line is never executed.


B.

#include <iostream>
#include <memory>

using namespace std;

struct A
{
virtual ~A() {}
};

struct B : public A
{
};

auto_ptr<B> test()
{
return auto_ptr<B>(new B);
};

int main()
{
auto_ptr<A> r = test();
std::cout << "You won't see this!" << std::endl;
}

 

[David Lowndes]

Bronek,

Compiling your code with VC7.1 gives this warning:

warning C4717: 'std::auto_ptr<B>:perator<A> std::auto_ptr_ref<A>' :
recursive on all control paths, function will cause runtime stack
overflow

.... which is what's happening to you in practice.

The online Comeau compiler won't compile your code, saying:

""ComeauTest.c", line 23: error: class "std::auto_ptr<A>" has no
suitable copy constructor
auto_ptr<A> r = test();
"

Dave

 

[Bronek Kozicki]

warning C4717: 'std::auto_ptr<B>:perator<A> std::auto_ptr_ref<A>' :
recursive on all control paths, function will cause runtime stack
overflow

... which is what's happening to you in practice.

.... and puts us in the realm of Undefined Behaviour.

""ComeauTest.c", line 23: error: class "std::auto_ptr<A>" has no
suitable copy constructor
auto_ptr<A> r = test();

which means that code is illegal. Is it ? Anyway I'd say that
"std::auto_ptr is flawed and has to be fixed" (


B.

 

[David Lowndes]

which means that code is illegal. Is it ?

Not being intimately familiar with the standards I can't say - but the
Comeau compiler is usually right.

Anyway I'd say that
"std::auto_ptr is flawed and has to be fixed" (

From what I've read about std::auto_ptr, it has many gotchas and can
be more trouble than its worth.

Dave

 

[Hendrik Schober]

Bronek,

Compiling your code with VC7.1 gives this warning:

warning C4717: 'std::auto_ptr<B>:perator<A> std::auto_ptr_ref<A>' :
recursive on all control paths, function will cause runtime stack
overflow

Funny. From VC I get this:

test.cpp(22) : error C2664: 'std::auto_ptr<_Ty>::auto_ptr(std::auto_ptr<_Ty> &) throw()' :

[...]

The online Comeau compiler won't compile your code, saying:

""ComeauTest.c", line 23: error: class "std::auto_ptr<A>" has no
suitable copy constructor
auto_ptr<A> r = test();
"

while Comeau here says this:

Comeau C/C++ 4.3.3 (Aug 10 2003 15:39:53) for _MS_WINDOWS_x86_Beta8
Copyright 1988-2003 Comeau Computing. All rights reserved.
MODE:non-strict warnings microsoft C++

"test.cpp", line 22: warning: initial value of reference to non-const must be
an lvalue
auto_ptr<A> r = test();
^
However, if I change this line

auto_ptr<A> r = test();

into this one

auto_ptr<A> r( test() );

I get your warning with VC7.1, and

initial value of reference to non-const must be an lvalue

from Comeau.
Now, when I tried this

auto_ptr<B> r = test();
auto_ptr<A> s(r);

both Comeau and VC7.1 accept the code.
I'm not sure what to make of this, but it
seems to be a work-around.
If you want to know chapter and verse of
the standard, I'd suggest you ask in either
comp.lang.c++.moderated or comp.std.c++. I
have decided long ago that the std doc is
far beyond my abilities to digest English.

Dave

Schobi

--
(e-mail address removed) is never read
I'm Schobi at suespammers dot org

"Sometimes compilers are so much more reasonable than people."
Scott Meyers

 

[David Lowndes]

Funny. From VC I get this:

test.cpp(22) : error C2664: 'std::auto_ptr<_Ty>::auto_ptr(std::auto_ptr<_Ty> &) throw()' :
cannot convert parameter 1 from 'std::auto_ptr<_Ty>' to 'std::auto_ptr<_Ty> &'

Mighty odd that we've got different results

If I get time I'll have to check what I tried again.

I have decided long ago that the std doc is far beyond my abilities to digest English.

<

Mine too.

Dave

 

[David Lowndes]

Funny. From VC I get this:

test.cpp(22) : error C2664: 'std::auto_ptr<_Ty>::auto_ptr(std::auto_ptr<_Ty> &) throw()' :
cannot convert parameter 1 from 'std::auto_ptr<_Ty>' to 'std::auto_ptr<_Ty> &'

I've tried again and VC7.1 (version 13.10.3077) reports the "recursive
on all control paths, function will cause runtime stack overflow"
warning for me.

The Comeau online (version 4.3.3) error is as I originally posted too.

I wonder what we have done differently?

Dave

 

[Bronek Kozicki]

I've tried again and VC7.1 (version 13.10.3077) reports the "recursive
on all control paths, function will cause runtime stack overflow"
warning for me.

The Comeau online (version 4.3.3) error is as I originally posted too.

I wonder what we have done differently?

Maybe that question should be passed to Mr. Plauger ?


B.

 

[Hendrik Schober]

[David, haven't seen your posting, so I
don't know if you wrote anything else
which I missed.]

That's funny.
I tried it again: Copy & paste the code
from Bronek's original posting int a my
test project, compile it, and get this:

------ Build started: Project: Test, Configuration: Debug Win32 ------

Compiling...
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077 for 80x86
Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.
cl /Od /I "..\.." /D "WIN32" /D "_DEBUG" /D "_CONSOLE" /D "_MBCS" /Gm /EHsc /RTC1 /MLd /GS /Za /Zc:wchar_t /Zc:forScope /GR
/Fo"C:\Temp\Test\Debug\Test/" /Fd"C:\Temp\Test\Debug\Test/vc70.pdb" /W4 /c /Wp64 /Zi /TP
\Develop\test.cpp
test.cpp
\Develop\test.cpp(22) : error C2664: 'std::auto_ptr<_Ty>::auto_ptr(std::auto_ptr<_Ty> &) throw()' : cannot convert parameter 1
from 'std::auto_ptr<_Ty>' to 'std::auto_ptr<_Ty> &'
with
[
_Ty=A
]
and
[
_Ty=A
]
and
[
_Ty=A
]
A reference that is not to 'const' cannot be bound to a non-lvalue

[Damn, I hate the IDE trying to copy formatted text
to the clipboard! OE is just to stupid to deal with
it. Can I have a switch to turn this off, please?!]

My "yvals.h" file has a

#define _CPPLIB_VER 313

in it.

Yeah:

Comeau C/C++ 4.3.3 (Aug 6 2003 15:13:37) for ONLINE_EVALUATION_BETA1
Copyright 1988-2003 Comeau Computing. All rights reserved.
MODE:strict errors C++

"ComeauTest.c", line 18: error: extra ";" ignored,
In C: A function definition does not end with a semicolon
In C++: A function definition, extern "C" or namespace, does not end with a semicolon
};
^

"ComeauTest.c", line 22: error: class "std::auto_ptr<A>" has no suitable copy
constructor
auto_ptr<A> r = test();
^

2 errors detected in the compilation of "ComeauTest.c".



For Comeau I know. I was using this:

Comeau C/C++ 4.3.3 (Aug 10 2003 15:39:53) for _MS_WINDOWS_x86_Beta8
Copyright 1988-2003 Comeau Computing. All rights reserved.
MODE:non-strict warnings microsoft C++

That's what I have on disk, and I think it's
using VC's std lib. AFAIK, Comeau Online uses
libcomo, which is a derivate of SGI's std lib.

Maybe that question should be passed to Mr. Plauger ?

This might be true for the difference between
Comeau Online and my version, which does use
Plauger's std lib. (You might want to post
your question in the STL group. Or go and ask
on comp.lang.c++.moderated ot comp.std.c++.)
However, I am still puzzled why David gets
different results with VC.

B.

Schobi

--
(e-mail address removed) is never read
I'm Schobi at suespammers dot org

"Sometimes compilers are so much more reasonable than people."
Scott Meyers

 

[David Lowndes]

That's funny.

OK, I see what the difference is now - you have the /Za "Disable
Language Extensions" compiler options set.

If I change that setting in my test project, I get the same error as
you.

I'd tested the code by creating a Win32 console application and
pasting the code it.

Dave

 

[Jonathan Turkanis]

[relates to problem discussed by Bronek Kozicki on 1-22-04; posted
also to m.p.vc.language]

The following program produces a stack overflow with VC7.1 +
Dinkumware
313:

#include <memory>

int main()
{
std::auto_ptr<const int> r(std::auto_ptr<int>(new int));
}

It has been tested successfully on the following compiler/standard
library combinations:

VC7.1 with auto_ptr from MSL (Metrowerks)
VC7.0 with auto_ptr from VC7.0 and VC7.1 and with STLPort
Intel 7.1 for Windows with Dinkumware for VC7.1
GCC 3.2 (MinGW)
Metrowerks Codewarrior 8.0 with MSL
Borland 5.6.4 with STLPort
Comeau 4.3.3 with libcomo

It therefore seems to be a problem unique to the combination of VC7.1
and Dinkumware.

VC7.1 + Dinkumware also crashes with the test program from Greg Colvin
(one of the auto_ptr architects) at
http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2000/n1232.pdf. This
problem was discovered by Bronek Kozicki and myself as a result of
discussion on the Boost developers list and comp.std.c++ and.

Jonathan Turkanis

 

[David Lowndes]

Jonathan,

Since the issue reproduces with the STL implementation with the
Whidbey compiler, I've tried to pass this on to MS - just in case
they're not already aware of it.

Dave

 

[Hendrik Schober]

OK, I see what the difference is now - you have the /Za "Disable
Language Extensions" compiler options set.
Ah!

If I change that setting in my test project, I get the same error as
you.

O.K., so this mystery is solved now.

I'd tested the code by creating a Win32 console application and
pasting the code it.

I have that one turned on in my test
project, since I am very concerned
about writing portable code. (Most of
our code is ported among a couple of
platforms.)

Dave

Schobi

--
(e-mail address removed) is never read
I'm Schobi at suespammers dot org

"Sometimes compilers are so much more reasonable than people."
Scott Meyers

 

[David Lowndes]

.... you might also want to post this to the microsoft.public.vc.stl
newsgroup where the Dinkumware people might pick up on it.

Dave

 

[Jonathan Turkanis]

... you might also want to post this to the microsoft.public.vc.stl
newsgroup where the Dinkumware people might pick up on it.

Thanks. I've already been in contact with P. J. Plauger.

Jonathan

 

[David Lowndes]

Thanks. I've already been in contact with P. J. Plauger.

Good, let us know the outcome if you can.

Dave

 

[Jonathan Turkanis]

Good, let us know the outcome if you can.

Will do.

Jonathan

 

[Jonathan Turkanis]

Good, let us know the outcome if you can.

From comp.std.c++

------------------------------------------

I tested the simplified example on a number of compiler/standard
library combinations, and only VC7.1 with Dinkumware had any trouble.
Among other things, I tried

VC7.1 with auto_ptr from MSL
Intel 7.1 for Windows with Dinkumware for VC7.1
VC7.0 with auto_ptr from VC7.0 and VC7.1 and with STLPort

So it seems to be VC7.1 and Dinkumware together which are

responsible.

Hmm. I'm getting diagnostics of various sorts from V6.0, V7.0, and
V7.1
using the library as shipped. Our Unabridged Library behaves much like
the shipped library with V7.1. Works fine with gcc and EDG compilers.
I've reported this as a compiler problem to Microsoft.

auto_ptr was *invented* to take advantage of a loophole in Standard
C++. It has caused various degrees of pain for *all* compilers over
the years, and hardly anybody on the C++ committee is happy with it
in its current form. It is most prudent to avoid corner cases, at
least in practical code. If you're looking for trouble, however,
there's plenty to find...

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

 

[Martyn Lovell [MSFT]]

Jonathan, David,

Hmm. I'm getting diagnostics of various sorts from V6.0, V7.0, and
V7.1
using the library as shipped. Our Unabridged Library behaves much like
the shipped library with V7.1. Works fine with gcc and EDG compilers.
I've reported this as a compiler problem to Microsoft.

auto_ptr was *invented* to take advantage of a loophole in Standard
C++. It has caused various degrees of pain for *all* compilers over
the years, and hardly anybody on the C++ committee is happy with it
in its current form. It is most prudent to avoid corner cases, at
least in practical code. If you're looking for trouble, however,
there's plenty to find...

We looked into this issue further and worked with Dinkumware. We eventually
concluded there was a bug in the implementaiton of auto_ptr that had been
exposed by V7.x and Whidbey's more complete conformance to the standard.

Martyn Lovell
Development Lead
Visual C++ Libraries Team
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[David Lowndes]

We looked into this issue further and worked with Dinkumware. We eventually

concluded there was a bug in the implementaiton of auto_ptr that had been
exposed by V7.x and Whidbey's more complete conformance to the standard.

Martyn,

Does that mean you can get it fixed for the Whidbey release?

Dave