Is there something wrong with this OO/STL code?

[Hendrik Schober]

Hi,

the following is a boiled-down version of a problem
we're plagued with. It's still a rather complicated
class hierarchy, but if we remove one more item, the
problem disappears.
This is the class hierarchy ('v' indicates virtual
inheritance):

A
|
v
|
B
| \
v v
| \
C B_
| \ \
v v \
| \ \
D C_ |
| \ \ |
v v | |
| \ | |
E \|/
\ D_
\ |
\ |
\ |
\|
E_

In code:

#include <map>

struct A {virtual ~A() {}; bool b1;};
struct B : public virtual A {bool b2[21];};
struct C : public virtual B {};
struct D : public virtual C {};
struct E : public virtual D {};

struct B_ : public virtual B {};
struct C_ : public virtual C {};
struct D_ : public virtual D
, public C_
, public B_{};
struct E_ : public D_
, public E {};

int main()
{
typedef std::map< unsigned long, E_* > M;
M m;
E_* p = new E_();
m.insert( M::value_type( 1, p ) );
for( M::iterator it = m.begin(); it != m.end(); ++it ) {
delete (*it).second; // *1
(*it).second = NULL;
}
m.clear(); // *2
}

The problem is in the line marked with *2: With
CodeWarrior 9.4 on MacOS X, it crashs with an
access fault. When we debug into the call to
'clear()' it seems as if (due to the delete in
line *1), the map somehow is messed up.
We could reproduce the crash with CW9.3, which
also usees MSL as their std lib. We could not
reproduce it with CW8 (MSL), GCC3.3 (either
libstd or Dinkumware) and VC7.1 (Dinkumware).
I have verified that Comeau (Online) compiles
the code without any warnings or errors.

Now here's my question: Is there anything wrong
with the code or is this a bug in the MSL?

TIA,

Schobi

--
Sp******@gmx.de is never read
I'm Schobi at suespammers dot org

"The presence of those seeking the truth is infinitely
to be prefered to those thinking they've found it."
Terry Pratchett

[Victor Bazarov]

Hendrik Schober wrote:

the following is a boiled-down version of a problem
we're plagued with. It's still a rather complicated
class hierarchy, but if we remove one more item, the
problem disappears.
This is the class hierarchy ('v' indicates virtual
inheritance):

A
|
v
|
B
| \
v v
| \
C B_
| \ \
v v \
| \ \
D C_ |
| \ \ |
v v | |
| \ | |
E \|/
\ D_
\ |
\ |
\ |
\|
E_

In code:

#include <map>

struct A {virtual ~A() {}; bool b1;};
struct B : public virtual A {bool b2[21];};
struct C : public virtual B {};
struct D : public virtual C {};
struct E : public virtual D {};

struct B_ : public virtual B {};
struct C_ : public virtual C {};
struct D_ : public virtual D
, public C_
, public B_{};
struct E_ : public D_
, public E {};

int main()
{
typedef std::map< unsigned long, E_* > M;
M m;
E_* p = new E_();
m.insert( M::value_type( 1, p ) );
for( M::iterator it = m.begin(); it != m.end(); ++it ) {
delete (*it).second; // *1
(*it).second = NULL;
}
m.clear(); // *2
}

The problem is in the line marked with *2: With
CodeWarrior 9.4 on MacOS X, it crashs with an
access fault. When we debug into the call to
'clear()' it seems as if (due to the delete in
line *1), the map somehow is messed up.
We could reproduce the crash with CW9.3, which
also usees MSL as their std lib. We could not
reproduce it with CW8 (MSL), GCC3.3 (either
libstd or Dinkumware) and VC7.1 (Dinkumware).
I have verified that Comeau (Online) compiles
the code without any warnings or errors.

Now here's my question: Is there anything wrong
with the code or is this a bug in the MSL?

There is nothing wrong with the code.

Have you tried to debug the library code to see where and when
the map gets "messed up"? That's what I'd do if I were to make
sure that 'MSL' is the culprit.

V

[Hendrik Schober]

Victor Bazarov <v.********@comAcast.net> wrote:

[...]
There is nothing wrong with the code.

Have you tried to debug the library code to see where and when
the map gets "messed up"? [...]
Yes. -- And got lost in some proprietary
tree implementation. :) Honestly, if the
code is correct, I'll report thisas a bug
and let MW do the debugging.
V

Schobi

--
Sp******@gmx.de is never read
I'm Schobi at suespammers dot org

"The presence of those seeking the truth is infinitely
to be prefered to those thinking they've found it."
Terry Pratchett