Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT cygwin DOT com Delivered-To: mailing list cygwin-developers AT cygwin DOT com Subject: Re: Many pthread failures in the test suite, one setgroup failure From: Robert Collins To: cygwin-developers AT cygwin DOT com In-Reply-To: <20020929000215.GB10872@redhat.com> References: <20020925141653 DOT GA6134 AT redhat DOT com> <1033139976 DOT 22908 DOT 333 DOT camel AT lifelesswks> <163544913434 DOT 20020927192540 AT logos-m DOT ru> <1033140780 DOT 9593 DOT 0 DOT camel AT lifelesswks> <44642850720 DOT 20020928223759 AT logos-m DOT ru> <1033254454 DOT 4375 DOT 48 DOT camel AT lifelesswks> <20020929000215 DOT GB10872 AT redhat DOT com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-xkv7MUPBU5yiOcGyk0Jb" Date: 29 Sep 2002 10:50:37 +1000 Message-Id: <1033260638.4375.76.camel@lifelesswks> Mime-Version: 1.0 --=-xkv7MUPBU5yiOcGyk0Jb Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sun, 2002-09-29 at 10:02, Christopher Faylor wrote: > >Which is valid for verifyable_object but will *kill* any derived > >classes. Yep. coding bug on my behalf. Can you or Chris try the test run > >after changing the verifyable_object destructor to be virtual (thread.h, > >line 163). >=20 > Already did that. It brings the pthread test suite failures down to > 1 for pthread-condvar6. assertion output is below. Ok, looking into this in shortly. =20 > >What *may* be a regression in 3.2 is the apparent bug caused by the > >introduction of a VMT in a derived class. However, as we already have a > >destructor for verifyable_object, and in this instance it should be > >virtual, we get to sidestep the bullet - for now. >=20 > I was thinking that it made sense to make the destructor virtual anyway. > But now, I'm worried about other parts of cygwin which are not exercised > by the test suite. Maybe they will have problems, too. >=20 > Isn't this actually a bug? Uhm what in? The missing virtual on the destructor *is* a bug in my code. gcc 3.2 having trouble with derived classes that have virtual methods of base classes with no virtuals methods is also (IMO) a bug and one in gcc. However, there is a thing called the rule of three: if a class has explictly decalared any of: copy constructor assignment operator destructor it MUST declare all three. Or else bad things happen (usually with remote storage). This isn't bad-because-of-compiler, but bad-because-of-programming-logic-errors. In this specific case, gcc was doing the right thing. I believe I could construct a test case to make gcc to the wrong thing though. Something like: class myBase{ public: myBase (int anInt):_value(anInt){} int getvalue() {return _value;} private: int _value; }; class myDerived { myDerived (int anInt) : myBase (anInt); virtual void confusebase(){return getvalue();} }; should do it. Rob --=20 --- GPG key available at: http://users.bigpond.net.au/robertc/keys.txt. --- --=-xkv7MUPBU5yiOcGyk0Jb Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQA9lk5dI5+kQ8LJcoIRAtPQAKCPygtlwo6RuXRKIBS0i+ibbJ3wSQCbB5AJ G1V5hzy1x3F9oBbshTziGTo= =Vg9L -----END PGP SIGNATURE----- --=-xkv7MUPBU5yiOcGyk0Jb--