This is the mail archive of the cygwin-developers@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Many pthread failures in the test suite, one setgroup failure


On Sat, Sep 28, 2002 at 10:37:59PM +0400, egor duda wrote:
>Hi!
>
>Friday, 27 September, 2002 Robert Collins rbcollins@cygwin.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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]