Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT cygwin DOT com>
List-Help: <mailto:cygwin-developers-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT cygwin DOT com
Delivered-To: mailing list cygwin-developers AT cygwin DOT com
Date: Sat, 28 Sep 2002 22:37:59 +0400
From: egor duda <deo AT logos-m DOT ru>
Reply-To: egor duda <cygwin-developers AT cygwin DOT com>
Organization: deo
X-Priority: 3 (Normal)
Message-ID: <44642850720.20020928223759@logos-m.ru>
To: Robert Collins <rbcollins AT cygwin DOT com>
CC: cygwin-developers AT cygwin DOT com
Subject: Re: Many pthread failures in the test suite, one setgroup failure
In-Reply-To: <1033140780.9593.0.camel@lifelesswks>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi!

Friday, 27 September, 2002 Robert Collins rbcollins AT cygwin DOT com wrote:

>> RC> BTW: While I don't run the cygwin test suite, I do have many of the
>> RC> exact same test cases in my test suite. And I strongly expect to see any
>> RC> such regressions before committing code.
>> 
>> just check what pthread_create() returns when given NULL in attr
>> (second) parameter. It's a simple 2-line test program. My reading of
>> the code + running under gdb shows that it returns EAGAIN.

RC> I have checked, and it works.

Oh, the wonders of the OOP. There's a lot of them left for the
unexperienced person like me.

I guess i know why it works for you. Hint: Try gcc 3.x to build
cygwin1.dll. Me and Chris, are using it, obviously, while you're
probably using 2.95, right?

Well, i'm not C++ guru at all, but stepping through assembly code i
found the following.

class verifyable_object contains no virtual functions, hence no
pointer to VMT in it. This means that compiler assumes that magic
member is placed at offset 0 from the beginning of class. class
pthread is a subclass of class verifyable_object, but it _does_
have VMT to accommodate virtual method 'create'. As far as i can
understand from assembly, pointer to VMT is placed at the beginning of
object instance, at offset 0, while members are placed after it, so
'magic' has offset 4.

Now, in verifyable_object_isvalid you're casing pointer to variable of
subclass to pointer to base class. Ain't it case of 'never do like
this'? I suppose to safely perform cast from subclass to base class
one should always use dynamic_cast().

Again, i know not very much about C++ (and, frankly, occasions like
this make me feel that i'd better cling to good old C, where 'what you
do is what you get'), so i don't think i'd be able to provide a patch.
But i can say for sure that in gcc 3.2 line

  if ((*object)->magic != magic)

in verifyable_object_isvalid() is trying to compare pointer to class
pthread VMT to PTHREAD_MAGIC and obviously fails.

Egor.            mailto:deo AT logos-m DOT ru ICQ 5165414 FidoNet 2:5020/496.19