libgcj/1107: Thread problems on SPARC/Solaris 2.7

joerg.brunsmann@fernuni-hagen.de joerg.brunsmann@fernuni-hagen.de
Wed Dec 20 12:06:00 GMT 2000 

>Number:         1107
>Category:       libgcj
>Synopsis:       Thread problems on SPARC/Solaris 2.7
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    bryce
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Dec 20 12:06:02 PST 2000
>Closed-Date:    Sun Apr 23 08:18:04 PDT 2000
>Last-Modified:  Sun Apr 23 08:20:00 PDT 2000
>Originator:     joerg.brunsmann@fernuni-hagen.de
>Release:        egcs-19991102, libgcj-snapshot-1999-11-12
>Organization:
>Environment:
SPARC Soloris 2.7
>Description:
1. Multithreaded program dumps core
2. wait/notify doesn't work
>How-To-Repeat:
configure --enable-threads=posix  --enable-java-gc=bo
ehm --with-as=/gnu/bin/as --with-ld=/gnu/bin/ld
Core dump problem:

1. Download:
http://www.informatik.fernuni-hagen.de/import/pi3/joerg/gcjthreads.tar.gz
2. make
3. WebServer 4444
4. In a web browser load http://localhost:4444
5. Reload the page 11 (sic!) times -> core dump (this is 
reproducable)

Wait/notify problem:

1. Edit WebServer.java and set workers to 5 
2. start WebServer 4444
3. Reload http://localhost:4444 five times
4. Reload again -> you get a response which means that
 wait/notify doesn't work

If you start the WebServer with a java vm the code works.

Also I needed to do a flush() on the printstream to get a 
result back to the web client which is not needed when
this program is used with a java vm. To see where these
flush() are needed edit the Worker.java file and search
for "libgcj". I can't say if this is a bug.

Also: if you uncomment the line

  public static final int HTTP_BAD_METHOD = 405;

in Worker.java you get:

gcj -c -o Worker.o Worker.java
Worker.java:133: Undefined variable `HTTP_BAD_METHOD'.
           ps.print("HTTP/1.0 " + HTTP_BAD_METHOD +
                                  ^
which is correct, but the gcj does not return to the
command shell which is a bug.


>Fix:
Need to disable the use of recursive mutexes on Solaris 2.7
>Release-Note:

>Audit-Trail:

Formerly PR libgcj/101

Responsible-Changed-From-To: tromey->green
Responsible-Changed-By: green
Responsible-Changed-When: Sun Mar  5 01:15:36 2000
Responsible-Changed-Why:
    I'll look at this.
    I realize it's been a while now, but your test code is
    missing.  Could you please make it available again?
    
    Thanks

From: green@cygnus.com
To: green@cygnus.com, java-gnats@sourceware.cygnus.com,
  joerg.brunsmann@fernuni-hagen.de, tromey@cygnus.com
Cc:  
Subject: Re: libgcj/101
Date: 5 Mar 2000 09:15:36 -0000

 Synopsis: Thread problems on SPARC/Solaris 2.7
 
 Responsible-Changed-From-To: tromey->green
 Responsible-Changed-By: green
 Responsible-Changed-When: Sun Mar  5 01:15:36 2000
 Responsible-Changed-Why:
     I'll look at this.
     I realize it's been a while now, but your test code is
     missing.  Could you please make it available again?
     
     Thanks
 
 http://sourceware.cygnus.com/cgi-bin/gnatsweb.pl?cmd=view&pr=101&database=java

From: Bryce McKinlay <bryce@albatross.co.nz>
To: green@cygnus.com
Cc: java-gnats@sourceware.cygnus.com
Subject: Re: libgcj/101
Date: Sun, 05 Mar 2000 22:37:12 +1300

 green@cygnus.com wrote:
 
 >      I'll look at this.
 >      I realize it's been a while now, but your test code is
 >      missing.  Could you please make it available again?
 
 Anthony,
 
 We already tracked this one down - sorry, I must have neglected to update the PR.
 Problem (1) is resolved and the cause of the problem (2) is a broken
 implementation of recursive mutexes on Solaris 2.7. The workaround for this would
 be to have configure disable the use of recursive mutexes on this platform, but
 nobody has done this yet. Solaris 2.6 and 2.8 should both work fine.
 
 regards
 
   [ bryce ]
 
 
 
 
Responsible-Changed-From-To: green->bryce
Responsible-Changed-By: bryce
Responsible-Changed-When: Sun Mar  5 16:07:16 2000
Responsible-Changed-Why:
    I looked at this.
State-Changed-From-To: open->analyzed
State-Changed-By: bryce
State-Changed-When: Sun Mar  5 16:07:16 2000
State-Changed-Why:
    Problem (1) is resolved and the cause of the problem (2) is a broken
    implementation of recursive mutexes on Solaris 2.7.

From: bryce@albatross.co.nz
To: bryce@albatross.co.nz, green@cygnus.com, java-gnats@sourceware.cygnus.com,
  joerg.brunsmann@fernuni-hagen.de
Cc:  
Subject: Re: libgcj/101
Date: 6 Mar 2000 00:07:16 -0000

 Synopsis: Thread problems on SPARC/Solaris 2.7
 
 Responsible-Changed-From-To: green->bryce
 Responsible-Changed-By: bryce
 Responsible-Changed-When: Sun Mar  5 16:07:16 2000
 Responsible-Changed-Why:
     I looked at this.
 State-Changed-From-To: open->analyzed
 State-Changed-By: bryce
 State-Changed-When: Sun Mar  5 16:07:16 2000
 State-Changed-Why:
     Problem (1) is resolved and the cause of the problem (2) is a broken
     implementation of recursive mutexes on Solaris 2.7.
 
 http://sourceware.cygnus.com/cgi-bin/gnatsweb.pl?cmd=view&pr=101&database=java

From: Bryce McKinlay <bryce@albatross.co.nz>
To: java-gnats@sourceware.cygnus.com, bryce@albatross.co.nz,
        joerg.brunsmann@fernuni-hagen.de
Cc:  
Subject: Re: libgcj/101
Date: Fri, 24 Mar 2000 02:07:34 +1200

 Joerg,
 
 I posted a patch that should fix this PR:
  http://sourceware.cygnus.com/ml/java-patches/2000-q1/msg00248.html
 
 Can you try it on Solaris and get back to me?
 
   [ bryce ]
 
 http://sourceware.cygnus.com/cgi-bin/gnatsweb.pl?cmd=view&pr=101&database=java
 
 
 

From: Joerg Brunsmann <Joerg.Brunsmann@FernUni-Hagen.de>
To: java-gnats@sourceware.cygnus.com
Cc:  
Subject: Re: libgcj/101
Date: Thu, 23 Mar 2000 18:48:44 +0100 (MET)

 Hi,
 
 just tried the new code with 
 
   gcc version 2.96 20000320 (experimental) 
 
 but unfortunalely I get this:
 
 Any suggestion?
 
 Joerg
 
 ....
 ude -I../libffi/include -fno-rtti -fvtable-thunks -W -Wall -D_GNU_SOURCE -g -O2
  -Wp,-MD,.deps/prims.pp -c  -fPIC -DPIC ../../../libjava/prims.cc -o .libs/prims
 .lo
 In file included from java/lang/String.h:9,
                  from ../../../libjava/java/lang/Class.h:18,
                  from ../../../libjava/gcj/cni.h:17,
                  from ../../../libjava/prims.cc:32:
 ../../../libjava/gcj/array.h: In instantiation of `JArray<jchar>':
 ../../../libjava/gcj/array.h:75:   instantiated from here
 ../../../libjava/gcj/array.h:29: Internal compiler error 108.
 ../../../libjava/gcj/array.h:29: Please submit a full bug report.
 ../../../libjava/gcj/array.h:29: See
 ../../../libjava/gcj/array.h:29: <URL: http://www.gnu.org/software/gcc/bugs.html >
 ../../../libjava/gcj/array.h:29: for instructions.
 make[2]: *** [prims.lo] Error 1                                           

From: Tom Tromey <tromey@cygnus.com>
To: Joerg Brunsmann <Joerg.Brunsmann@FernUni-Hagen.de>
Cc: bryce@albatross.co.nz, java-gnats@sourceware.cygnus.com
Subject: Re: libgcj/101
Date: Thu, 23 Mar 2000 09:51:24 -0800 (PST)

 My suggestion is to submit a bug report.
 It has been about 2 weeks since the cvs gcc could compile libgcj.
 Maybe more complaints will help.
 
 Tom

From: Bryce McKinlay <bryce@albatross.co.nz>
To: Joerg Brunsmann <Joerg.Brunsmann@FernUni-Hagen.de>
Cc: java-gnats@sourceware.cygnus.com
Subject: Re: libgcj/101
Date: Tue, 28 Mar 2000 14:37:04 +1200

 Can you try it again now? cvs gcc/gcj is now working again (for me at least), and
 the new threads code has been checked in to libgcj cvs. I'd like to get a report on
 how the new code works for Solaris. Can you also run it against the new threads test
 cases in testsuite/libjava.lang/Thread_*.java?
 
 cheers
 
   [ bryce ]
 
 
 Joerg Brunsmann wrote:
 
 >  just tried the new code with
 >
 >    gcc version 2.96 20000320 (experimental)
 >
 >  but unfortunalely I get this:
 >
 >  Any suggestion?
 

From: Joerg Brunsmann <Joerg.Brunsmann@FernUni-Hagen.de>
To: java-gnats@sourceware.cygnus.com
Cc:  
Subject: Re: libgcj/101
Date: Tue, 28 Mar 2000 21:18:17 +0200 (MET DST)

 Hi,
 
 with gcj of 27 march and a libgcj cvs checkout i get on
 sparc/solaris 2.7:
 
 Reading symbols from /usr/lib/libthread.so.1...done.
 #0  0x100 in ?? ()
 (gdb) where
 #0  0x100 in ?? ()
 #1  0xff11ec30 in GC_init_inner () at ../../../boehm-gc/misc.c:523
 #2  0xff11b870 in GC_generic_malloc_inner (lb=10, k=0)
     at ../../../boehm-gc/malloc.c:61
 #3  0xff11ba08 in GC_generic_malloc (lb=10, k=0)
     at ../../../boehm-gc/malloc.c:129
 #4  0xff2caaac in _Jv_AllocBytes (size=10) at ../../../libjava/boehm.cc:324
 #5  0xff222ca0 in _Jv_makeUtf8Const (s=0xff2f4c28 "()V", len=3)
     at ../../../libjava/prims.cc:225
 #6  0xff2b40f0 in __static_initialization_and_destruction_0 (__initialize_p=1,
     __priority=65535) at ../../../libjava/java/lang/natClass.cc:70
 #7  0xff2b41e0 in global constructors keyed to java::lang::Class::forName ()
     at ../../../libjava/java/lang/natClass.cc:73
 #8  0xff2d29dc in __do_global_ctors_aux ()
 #9  0xff222544 in _init ()
 #10 0xff3b9ac0 in ?? ()
 #11 0xff3b9914 in ?? ()
 #12 0xff3c1400 in ?? ()
 #13 0xff3b2fa0 in ?? ()             
 
 Any suggestions?
 
 Thanks,
 
 Joerg

From: Bryce McKinlay <bryce@albatross.co.nz>
To: Joerg Brunsmann <Joerg.Brunsmann@FernUni-Hagen.de>
Cc: java-gnats@sourceware.cygnus.com
Subject: Re: libgcj/101
Date: Wed, 29 Mar 2000 12:46:36 +1200

 Joerg Brunsmann wrote:
 
 >  #5  0xff222ca0 in _Jv_makeUtf8Const (s=0xff2f4c28 "()V", len=3)
 >      at ../../../libjava/prims.cc:225
 >  #6  0xff2b40f0 in __static_initialization_and_destruction_0 (__initialize_p=1,
 >      __priority=65535) at ../../../libjava/java/lang/natClass.cc:70
 >  #7  0xff2b41e0 in global constructors keyed to java::lang::Class::forName ()
 >      at ../../../libjava/java/lang/natClass.cc:73
 
 >  Any suggestions?
 
 Looks like it could be the infamous Solaris vs. libtool vs. C++ static
 initializers bug? I think I remember having this problem when I was using libgcj
 on Solaris x86. I don't really know how I fixed it...
 
  [ bryce ]
 
 
State-Changed-From-To: analyzed->feedback
State-Changed-By: tromey
State-Changed-When: Sat Apr 22 19:42:25 2000
State-Changed-Why:
    Does this still happen to you?
    If so, tell me the current status.
    If not, tell me and I will close the PR.
    I think Bryce's reimplementation of the POSIX threads
    code should fix this problem.

From: tromey@cygnus.com
To: bryce@albatross.co.nz, java-gnats@sourceware.cygnus.com,
  joerg.brunsmann@fernuni-hagen.de
Cc:  
Subject: Re: libgcj/101
Date: 23 Apr 2000 02:42:26 -0000

 Synopsis: Thread problems on SPARC/Solaris 2.7
 
 State-Changed-From-To: analyzed->feedback
 State-Changed-By: tromey
 State-Changed-When: Sat Apr 22 19:42:25 2000
 State-Changed-Why:
     Does this still happen to you?
     If so, tell me the current status.
     If not, tell me and I will close the PR.
     I think Bryce's reimplementation of the POSIX threads
     code should fix this problem.
 
 http://sourceware.cygnus.com/cgi-bin/gnatsweb.pl?cmd=view&pr=101&database=java

From: Joerg Brunsmann <Joerg.Brunsmann@FernUni-Hagen.de>
To: bryce@albatross.co.nz, java-gnats@sourceware.cygnus.com, tromey@cygnus.com
Cc:  
Subject: Re: libgcj/101
Date: Sun, 23 Apr 2000 12:21:31 +0200 (MET DST)

 Hi,
 
 just tried the 20000417 egcs snapshot but its compilation
 stops. I don't want to fiddle around with older versions
 and patches. So I suggest to close this PR. I'll try
 periodically snapshots of libgcj and gcj in the future. 
 If I find a working combination I'll run my code. If 
 the wait/notify error persist I'll file a new PR. 
 Thanks for your interest.
 
 Joerg
State-Changed-From-To: feedback->closed
State-Changed-By: tromey
State-Changed-When: Sun Apr 23 08:18:04 2000
State-Changed-Why:
    Joerg said it is ok to close; he'll resubmit if necessary
    once he can try things.

From: tromey@cygnus.com
To: bryce@albatross.co.nz, java-gnats@sourceware.cygnus.com,
  joerg.brunsmann@fernuni-hagen.de
Cc:  
Subject: Re: libgcj/101
Date: 23 Apr 2000 15:18:05 -0000

 Synopsis: Thread problems on SPARC/Solaris 2.7
 
 State-Changed-From-To: feedback->closed
 State-Changed-By: tromey
 State-Changed-When: Sun Apr 23 08:18:04 2000
 State-Changed-Why:
     Joerg said it is ok to close; he'll resubmit if necessary
     once he can try things.
 
 http://sourceware.cygnus.com/cgi-bin/gnatsweb.pl?cmd=view&pr=101&database=java
>Unformatted:

More information about the Gcc-prs mailing list