g++ 3.4 exception problem

[snorkelman]

I have a case where an exception in the constructor of class with a
virtual base leads to termination:

struct vbase {};

struct foo : virtual vbase {
foo() {
throw "exception in foo ctor";
}
};

main()
{
struct bar : public foo {};
try {
bar a;
}
catch ( ... ) {
}
return 0;
};

This program demonstrates the problem in g++ 3.4. Instead of catching
the exception, the program terminates. The base dtor gets called as
expected, but upon return, there is some generated code that I can't
decipher, which jumps to some termination code at bad_alloc + 80.

That should be a clue... but I'm unable to catch it.

|
| markn at ieee dot org
|

[Giancarlo Niccolai]

sn********@gmail.com wrote:

I have a case where an exception in the constructor of class with a
virtual base leads to termination:

struct vbase {};

struct foo : virtual vbase {
foo() {
throw "exception in foo ctor";
}
};

main()
{
struct bar : public foo {};
try {
bar a;
}
catch ( ... ) {
}
return 0;
};

This program demonstrates the problem in g++ 3.4. Instead of catching
the exception, the program terminates. The base dtor gets called as
expected, but upon return, there is some generated code that I can't
decipher, which jumps to some termination code at bad_alloc + 80.

That should be a clue... but I'm unable to catch it.

|
| markn at ieee dot org
|

Suggestion: try with Gcc 4.0.1. Ver 3.4 seems weird at times, and I think
the effort will be focused on version 4 from now on.

Giancarlo.

[snorkelman]

Same problem appears in g++ 4.0.0... I'd really like to know whether
this is a compiler problem or me doing something wrong...

[Peter Julian]

<sn********@gmail.com> wrote in message
news:11**********************@g47g2000cwa.googlegr oups.com...

I have a case where an exception in the constructor of class with a
virtual base leads to termination:
#include <stdexcept>

struct vbase {};

struct foo : virtual vbase {
foo() {
throw "exception in foo ctor";
Thats not an exception object you are throwing. Try:

throw std::exception("foo ctor");
}
};

main()
int main()
{
struct bar : public foo {};
The struct bar type definition above goes outside of main's body.
try {
bar a;
}
catch ( ... ) {
}
catch (const std::exception& e)
{
e.what();
}
return 0;
};

This program demonstrates the problem in g++ 3.4. Instead of catching
the exception, the program terminates. The base dtor gets called as
expected, but upon return, there is some generated code that I can't
decipher, which jumps to some termination code at bad_alloc + 80.

That should be a clue... but I'm unable to catch it.

[Alf P. Steinbach]

* Peter Julian:

<sn********@gmail.com> wrote in message
news:11**********************@g47g2000cwa.googlegr oups.com...

I have a case where an exception in the constructor of class with a
virtual base leads to termination:

#include <stdexcept>

struct vbase {};

struct foo : virtual vbase {
foo() {
throw "exception in foo ctor";

Thats not an exception object you are throwing. Try:

throw std::exception("foo ctor");

Any type can be used.

}
};

main()

int main()

{
struct bar : public foo {};

The struct bar type definition above goes outside of main's body.

AFAICS it's perfectly OK placed where it is. The main restrictions on a
local class are that it cannot have static members, and that it cannot be
used as a template parameter. I cannot find any statement that forbids a
local class from using virtual inheritance.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[markn]

>Thats not an exception object you are throwing. Try:

No, it's not, but of course there is nothing special about what type of
object you throw, they're all the same as far as the compiler is
concerned.

I have tried quite a few variations on the type of object to be thrown
and various catch clauses, and they all behave the same. I have
verified that std::exception behaves no differently, same error. Only
difference is the error report:

terminate called after throwing an instance of 'std::exception'
what(): St9exception

No additional clues here pointing towards a fix, either.

The struct bar type definition above goes outside of main's body.

I reserve the right to define my structs anywhere I please. :-)

Seriously, the struct definition is legal as is. But, hoping that you
were on to something, I move the struct definition to the global
namespace, no joy.

I'm still searching for a workaround, no luck so far... I think if I
was able to step through the unwind source code where things go awry I
might be able to figure it out - the unannotated assembly is a bit
tough.. still working on how to do that.
|
| Mark
|

[Alf P. Steinbach]

* sn********@gmail.com:

I have a case where an exception in the constructor of class with a
virtual base leads to termination:

struct vbase {};

struct foo : virtual vbase {
foo() {
throw "exception in foo ctor";
}
};

main()
{
struct bar : public foo {};
try {
bar a;
}
catch ( ... ) {
}
return 0;
};
Typos: result type, semicolon.

This program demonstrates the problem in g++ 3.4. Instead of catching
the exception, the program terminates. The base dtor gets called as
expected, but upon return, there is some generated code that I can't
decipher, which jumps to some termination code at bad_alloc + 80.

That should be a clue... but I'm unable to catch it.

A workaround is

struct bar: foo{ bar(): vbase() {} };

It seems that g++ incorrectly generates a default constructor (or generates
corresponding code, or no code) that doesn't initialize vbase.

Of course, if the actual code has a bunch of interface classes instead of
something like vbase, "initializing" them all is somewhat impractical, but
if that's what's needed, then it's needed. I'd post an error report if I
were you. Just google up the reporting page on the web.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[markn]

Alf, you had my hopes up, but I don't think this is a fix.

I don't think the absence of base class initialization is the source of
my trouble. In any case,this mode that explicitly calls it still
exhibits the problem.

If I step into the disassembly, I see things proceed as I expect. The
base ctor is called, then foo<1>,then foo<2>. The throw is reached,
then ~foo<1>(), ~vbase(), the exception is allocated, then we go south.

struct vbase {};

template<int N>
struct foo : virtual private vbase {
foo() : vbase() {
if ( N == 2 )
throw "something bad happened";
}
};

struct bar
: public foo<1>
, public foo<2>
, public foo<3>
{};

int main()
{

try { bar a; }
catch ( ... ) {}
return 0;
}

|
| Mark
|

[Mark Nelson]

One more point... the compiler correctly only generates a single call
to the virtual base constructor, and it calls it ahead of the
constructors for the instances of foo<N>. In fact, the call to vbase()
added to the foo ctor gets thrown away. It might be a good idea fo the
compiler to generate a warning in this case, if it could properly
figure out when that initializer does not get invoked.

|
| Mark
|

[Mark Nelson]

Some progress. In the example above, the problem disappears if you
change the code to:

struct bar
: public foo<1>
, public foo<2>
, public foo<3>
{
bar(){}
};

Yes, just adding a constructor to the base class causes the problem to
go away. I'm checking this on gcc 4.0.0 on an OS X target, I'll double
check with 3.4.

This doesn't completely fix the problem, but I think I can force users
to implement a constructor by creating a non-default ctor for my
virtual base...

I'm going see if the disassembly of the succesful case yields any
additional clues.
|
| Mark
|

[Alf P. Steinbach]

* ma***@ieee.org:

Alf, you had my hopes up, but I don't think this is a fix.
Not a completely general one, no, but it is a fix.

This is cool: your new code demonstrates one bug in g++ 3.4.*, and another
bug in MSVC 7.1. :-)

I don't think the absence of base class initialization is the source of
my trouble. In any case,this mode that explicitly calls it still
exhibits the problem.

If I step into the disassembly, I see things proceed as I expect. The
base ctor is called, then foo<1>,then foo<2>. The throw is reached,
then ~foo<1>(), ~vbase(), the exception is allocated, then we go south.

struct vbase {};

template<int N>
struct foo : virtual private vbase {
Make that 'protected' in order to enable the fix.

The MSVC 7.1 compiler bug: it doesn't honor 'private' in this context.

foo() : vbase() {
if ( N == 2 )
throw "something bad happened";
}
};

struct bar
: public foo<1>
, public foo<2>
, public foo<3>
{
bar(): vbase() {} // g++ 3.4 compiler bug workaround.
};

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Mark Nelson]

>Make that 'protected' in order to enable the fix.

That private inheritance was a leftover from some previous
experimentation, my bad.:-)

But you're right about the fix, adding the constructor in the base
class does the job. But it does the job even *without* the base class
initialization, at least in 4.0.0. I think I have enough here to cobble
together a workaround, thanks for providing the line of code that
opened the door!

|
| Mark
|