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 14:59:22 -0400
From: Christopher Faylor <cgf AT redhat DOT com>
To: cygwin-developers AT cygwin DOT com
Subject: Re: Many pthread failures in the test suite, one setgroup failure
Message-ID: <20020928185921.GA8253@redhat.com>
Reply-To: cygwin-developers AT cygwin DOT com
Mail-Followup-To: cygwin-developers AT cygwin DOT 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>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <44642850720.20020928223759@logos-m.ru>
User-Agent: Mutt/1.4i

On Sat, Sep 28, 2002 at 10:37:59PM +0400, egor duda wrote:
>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().

Hmm.  I thought it was always legal to coerce a pointer to a subclass
to a pointer to the base class.  Did you try a dynamic cast to see
if it worked?

Anyway, thanks for the detailed analysis, Egor.  I was actually
wondering if this was a gcc 3.2 "problem".  It must be a gcc 3.3
problem, also, since my normal compiler is gcc 3.3.

cgf