Re: libjava gcc-3_0-branch, klass timing out in testsuite again

Re: libjava gcc-3_0-branch, klass timing out in testsuite again

[Fergus Henderson]

On 05-May-2001, Mike Stump <mrs@windriver.com> wrote:
> Fergus Henderson <fjh@cs.mu.oz.au>:
> > You may also prefer hard-coding the class name instead of using
> > `typeof(*this)', especially since typeof is only supported in GNU C,
> > not GNU C++, I think.  As you can see I haven't tested this code ;-)
> 
> I believe I've used typeof in C++ just fine...

Sorry, you are correct, I was mistaken: typeof works fine in C++.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: < http://www.cs.mu.oz.au/~fjh >  |     -- the last words of T. S. Garp.

Re: libjava gcc-3_0-branch, klass timing out in testsuite again

[Jeff Sturm]

On Mon, 7 May 2001, Bryce McKinlay wrote:
> I've verified that it doesn't cause any regressions on
> i686-pc-linux-gnu, but I don't know if it actually fixes the
> original problem as I have not seen it. Could someone check?

Yes, it does appear to fix the problem, at least on alpha-linux.  Thanks
to Fergus for the expert advice and Bryce for patching the tree!

Jeff

Re: libjava gcc-3_0-branch, klass timing out in testsuite again

[Bryce McKinlay]

Fergus Henderson wrote:

> If you're going to be making assumptions about how vtables are layed out,
> then I think it's safe to also assume that `char *' and `void *' have
> the same representation, in which case you can write that a little more
> readably using type `char *' for the vtable_ptr:
>
>     union Self {
>         char *vtable_ptr;
>         typeof(*this) self;
>     };
>     ((Self *)this)->vtable_ptr -= 2 * sizeof (void *);
>
> However, this is a matter of taste.  You may prefer the other way.
>
> You may also prefer hard-coding the class name instead of using
> `typeof(*this)', especially since typeof is only supported in GNU C,
> not GNU C++, I think.  As you can see I haven't tested this code ;-)

Thanks for tracking this down Jeff (and thanks Fergus for suggesting the fix). I'm
checking this patch in to the trunk and branch. I've verified that it doesn't cause
any regressions on i686-pc-linux-gnu, but I don't know if it actually fixes the
original problem as I have not seen it. Could someone check?  In any case, its a
damn good cleanup.

regards

  [ bryce ]

Re: libjava gcc-3_0-branch, klass timing out in testsuite again

[Andreas Schwab]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 489 bytes --]

Fergus Henderson <fjh@cs.mu.oz.au> writes:

|> then I think it's safe to also assume that `char *' and `void *' have
|> the same representation

This is required anyway, at least in C.

Andreas.

-- 
Andreas Schwab                                  "And now for something
SuSE Labs                                        completely different."
Andreas.Schwab@suse.de
SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5

Re: libjava gcc-3_0-branch, klass timing out in testsuite again

[Fergus Henderson]

On 05-May-2001, Jeff Sturm <jsturm@one-point.com> wrote:
> 
> That is, it behaves exactly as if these lines in Class.h do nothing:
> 
>     // C++ ctors set the vtbl pointer to point at an offset inside the vtable
>     // object. That doesn't work for Java, so this hack adjusts it back.
>     void *p =  ((void **)this)[0];
>     ((void **)this)[0] = (void *)((char *)p-2*sizeof (void *));
>  
> Rebuilding libjava with -fno-strict-aliasing is the quick fix:
...
> Can some C++ person comment on the code fragment above in terms of
> aliasing?

The above code fragment violates the rule on aliasing 
(3.10 [basic.lval] paragraph 15), because it accesses the object `*this'
with a different type.  Hence it has undefined behaviour.

A possible fix is to use a union:

    union Self {
        void *vtable_ptr;
        typeof(*this) self;
    };
    Self *self = (Self *)this;
    self->vtable_ptr = (void *)((char *)self->vtable_ptr - 2 * sizeof (void *));

This is still not strictly conforming C++, but I think g++ supports it,
even with -fstrict-aliasing.

If you're going to be making assumptions about how vtables are layed out,
then I think it's safe to also assume that `char *' and `void *' have
the same representation, in which case you can write that a little more
readably using type `char *' for the vtable_ptr:

    union Self {
        char *vtable_ptr;
        typeof(*this) self;
    };
    ((Self *)this)->vtable_ptr -= 2 * sizeof (void *);

However, this is a matter of taste.  You may prefer the other way.

You may also prefer hard-coding the class name instead of using
`typeof(*this)', especially since typeof is only supported in GNU C,
not GNU C++, I think.  As you can see I haven't tested this code ;-)

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: < http://www.cs.mu.oz.au/~fjh >  |     -- the last words of T. S. Garp.

Re: libjava gcc-3_0-branch, klass timing out in testsuite again

[Jeff Sturm]

On Fri, 4 May 2001, Gordon Sadler wrote:
> For a more thorough look at what happenned for me on i686 last
> time, please see:
> http://gcc.gnu.org/ml/gcc/2001-04/msg00663.html
> http://gcc.gnu.org/ml/gcc/2001-04/msg00676.html

Your stack trace looks a lot like mine, minus line number information.

Clue #1 is that it aborts in clone(), but line 8 calls equals(),
not clone().  Clue #2 is that the class pointer (actually first word
of the vtable) doesn't point to a class at all.

That is, it behaves exactly as if these lines in Class.h do nothing:

    // C++ ctors set the vtbl pointer to point at an offset inside the
vtable
    // object. That doesn't work for Java, so this hack adjusts it back.
    void *p =  ((void **)this)[0];
    ((void **)this)[0] = (void *)((char *)p-2*sizeof (void *));
 
Rebuilding libjava with -fno-strict-aliasing is the quick fix:

PASS: klass compilation from source
PASS: klass execution from source compiled test
PASS: klass output from source compiled test

Can some C++ person comment on the code fragment above in terms of
aliasing?

Jeff

Re: libjava gcc-3_0-branch, klass timing out in testsuite again

[Gordon Sadler]

On Fri, May 04, 2001 at 08:36:32PM -0700, Jeff Sturm wrote:
> On Fri, 4 May 2001, Gordon Sadler wrote:
> > Exception in thread "main" WARNING: program timed out.
> > FAIL: klass execution from source compiled test
> 
> Though I've never seen this on i686-pc-linux-gnu I get it nightly on 
> alpha-unknown-linux-gnu.  I haven't investigated carefully yet.  (The
> state of gdb on alpha-linux is so bad sometimes I don't even try.)
> 
> I do know the program seems to loop on SIGSEGV somewhere in
> java::lang::Object::clone, around the line
> 
>   if (klass->isArray())
> 
> The klass object appears to have been overwritten:
> 
> (gdb) print klass->name
> $2 = (_Jv_Utf8Const *) 0x23bd86d827ba002e
> 
> Does this look like the same failure?
> 
I haven't taken much/any time on this today other than looking at build
logs. For a more thorough look at what happenned for me on i686 last
time, please see:
http://gcc.gnu.org/ml/gcc/2001-04/msg00663.html
http://gcc.gnu.org/ml/gcc/2001-04/msg00676.html

I look into this current failure on my machine shortly. Have to get
another copy of the JDK for comparisons.

Gordon Sadler

Re: libjava gcc-3_0-branch, klass timing out in testsuite again

[Jeff Sturm]

On Fri, 4 May 2001, Gordon Sadler wrote:
> Exception in thread "main" WARNING: program timed out.
> FAIL: klass execution from source compiled test

Though I've never seen this on i686-pc-linux-gnu I get it nightly on 
alpha-unknown-linux-gnu.  I haven't investigated carefully yet.  (The
state of gdb on alpha-linux is so bad sometimes I don't even try.)

I do know the program seems to loop on SIGSEGV somewhere in
java::lang::Object::clone, around the line

  if (klass->isArray())

The klass object appears to have been overwritten:

(gdb) print klass->name
$2 = (_Jv_Utf8Const *) 0x23bd86d827ba002e

Does this look like the same failure?

Jeff

libjava gcc-3_0-branch, klass timing out in testsuite again

[Gordon Sadler]

I had this problem previously. Then it seemed to mysteriously clear up,
all the while either Tom T or Mark M said they were unable to reproduce.
Odd... The last time it lasted for a week or so. This just started again
as of last night. I run a bootstrap nightly at 3am (CST) after doing a
cvs update, assuming I don't have any hardware/toolchain problems, which
I've had for the odd day or 3 if you check testresults.

This is from libjava/testsuite/libjava.log:
Executing on host: /usr/src/build/gcc/i686-pc-linux-gnu/libjava/testsuite/../libtool --silent --tag=GCJ --mode=link /usr/src/build/gcc/gcc/gcj -B/usr/src/build/gcc/gcc/ --encoding=UTF-8 -B/usr/src/build/gcc/i686-pc-linux-gnu/libjava/testsuite/../ /usr/src/cvs/gcc-3.0/libjava/testsuite/libjava.lang/klass.java /usr/src/build/gcc/i686-pc-linux-gnu//libjava/libgcj.la /usr/src/build/gcc/i686-pc-linux-gnu//boehm-gc/libgcjgc.la /usr/src/build/gcc/i686-pc-linux-gnu//zlib/libzgcj.la   --main=klass -g -L/usr/src/build/gcc/i686-pc-linux-gnu//libjava/.libs -L/usr/src/build/gcc/i686-pc-linux-gnu//boehm-gc/.libs -L/usr/src/build/gcc/i686-pc-linux-gnu//zlib/.libs  -lm   -o /usr/src/build/gcc/i686-pc-linux-gnu/libjava/testsuite/klass    (timeout = 300)
PASS: klass compilation from source
Exception in thread "main" WARNING: program timed out.
FAIL: klass execution from source compiled test
UNTESTED: klass output from source compiled test
PASS: klass byte compilation
Executing on host: /usr/src/build/gcc/gcc/jv-scan /usr/src/cvs/gcc-3.0/libjava/testsuite/libjava.lang/klass.java  --encoding=UTF-8 --print-main     (timeout = 300)
klassoutput is:
klass

Sorry for formatting, build logs tend to be ugly. This is repeated only
when I notice klass showing up in ps listings. Once before I starting
running an every 5 minute cronjob just to killall klass (or is it
lt-klass?). Anyway, it would be nice if someone could resolve this, else
I must resort to not building libjava or another ugly cronjob hack to
kill these processes.

Thanks

Gordon Sadler