libgcj/1410: Static initializer in DecimalFormat eventually depends on itself

libgcj/1410: Static initializer in DecimalFormat eventually depends on itself

[bryce]

>Number:         1410
>Category:       libgcj
>Synopsis:       Static initializer in DecimalFormat eventually depends on itself
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    tromey
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Dec 20 12:19:40 PST 2000
>Closed-Date:    Fri Feb 25 14:44:38 PST 2000
>Last-Modified:  Fri Feb 25 14:50:00 PST 2000
>Originator:     Bryce McKinlay
>Release:        current cvs tree (19990818)
>Organization:
>Environment:
any
>Description:
A static initializer in java.text.DecimalFormat (984) constructs a 
DecimalFormatSymbols, which calls Resourcebundle.getBundle, 
which uses a URLClassLoader, which uses a URLConnection, 
that contains a static initializer constructing 
SimpleDateFormat, which calls NumberFormat.getInstance(), 
which (guess what!) trys to construct a DecimalFormat. Oops.
>How-To-Repeat:
DecimalFormat df = new DecimalFormat ();
>Fix:
Tentative fix submitted: http://sourceware.cygnus.com/ml/java-patches/1999-q3/msg00196.html -BM
>Release-Note:

>Audit-Trail:

Formerly PR libgcj/38

State-Changed-From-To: open->feedback
State-Changed-By: bryce
State-Changed-When: Thu Sep 16 20:14:23 1999
State-Changed-Why:
    Tenative fix submitted: http://sourceware.cygnus.com/ml/java-patches/1999-q3/msg00196.html -BM
State-Changed-From-To: feedback->closed
State-Changed-By: tromey
State-Changed-When: Fri Nov 12 16:37:07 1999
State-Changed-Why:
    This has been in feedback for months.
    I read the email exchange about the proposed patch,
    and to me it looks like the problem is solved.

From: tromey@cygnus.com
To: bryce@albatross.co.nz, java-gnats@sourceware.cygnus.com, tromey@cygnus.com
Cc:  
Subject: Re: libgcj/38
Date: 13 Nov 1999 00:37:07 -0000

 Synopsis: Static initializer in DecimalFormat eventually depends on itself
 
 State-Changed-From-To: feedback->closed
 State-Changed-By: tromey
 State-Changed-When: Fri Nov 12 16:37:07 1999
 State-Changed-Why:
     This has been in feedback for months.
     I read the email exchange about the proposed patch,
     and to me it looks like the problem is solved.
 
 http://sourceware.cygnus.com/cgi-bin/gnatsweb.pl?cmd=view&database=java&pr=38
State-Changed-From-To: closed->open
State-Changed-By: bryce
State-Changed-When: Sat Nov 13 03:27:44 1999
State-Changed-Why:
    Not yet fixed, sorry.

From: Bryce McKinlay <bryce@albatross.co.nz>
To: tromey@cygnus.com
Cc: java-gnats@sourceware.cygnus.com
Subject: Re: libgcj/38
Date: Sun, 14 Nov 1999 00:24:29 +1300

 tromey@cygnus.com wrote:
 
 >      This has been in feedback for months.
 >      I read the email exchange about the proposed patch,
 >      and to me it looks like the problem is solved.
 
 Actually, this one still isn't fixed. I did post a patch but never checked it in
 because I'm not sure its the right way to fix it. This bug is preventing the
 jBYTEmark benchmark from running on libgcj at the moment. I'm going to look into
 it again soon when I find some time.
 
 regards
 
   [ bryce ]
 
 

From: bryce@albatross.co.nz
To: bryce@albatross.co.nz, java-gnats@sourceware.cygnus.com, tromey@cygnus.com
Cc:  
Subject: Re: libgcj/38
Date: 13 Nov 1999 11:27:44 -0000

 Synopsis: Static initializer in DecimalFormat eventually depends on itself
 
 State-Changed-From-To: closed->open
 State-Changed-By: bryce
 State-Changed-When: Sat Nov 13 03:27:44 1999
 State-Changed-Why:
     Not yet fixed, sorry.
 
 http://sourceware.cygnus.com/cgi-bin/gnatsweb.pl?cmd=view&database=java&pr=38

From: Tom Tromey <tromey@cygnus.com>
To: Bryce McKinlay <bryce@albatross.co.nz>
Cc: java-patches@sourceware.cygnus.com,
        Java Gnats Server <java-gnats@sourceware.cygnus.com>
Subject: Re: libgcj/38
Date: Fri, 25 Feb 2000 00:19:00 -0800 (PST)

 >>>>> "Bryce" == Bryce McKinlay <bryce@albatross.co.nz> writes:
 
 Bryce> This is a new fix for an old bug. The problem is that certain
 Bryce> classes in java.text need to load resources via the URL class
 Bryce> loading mechanism.  This mechanism itself uses those java.text
 Bryce> classes, and in some cases we get an
 Bryce> ExceptionInInitializerError due to intializer co-dependency.
 
 Bryce> +  private void initializeDateFormats()
 
 Shouldn't this be synchronized?
 And shouldn't the body then check again for "locale == null"?
 
 BTW this isn't for PR 32.  It is for PR 38.
 
 Tom

From: Bryce McKinlay <bryce@albatross.co.nz>
To: Tom Tromey <tromey@cygnus.com>
Cc: java-patches@sourceware.cygnus.com,
        Java Gnats Server <java-gnats@sourceware.cygnus.com>
Subject: Re: libgcj/38
Date: Fri, 25 Feb 2000 21:41:08 +1300

 Tom Tromey wrote:
 
 > >>>>> "Bryce" == Bryce McKinlay <bryce@albatross.co.nz> writes:
 >
 > Bryce> This is a new fix for an old bug. The problem is that certain
 > Bryce> classes in java.text need to load resources via the URL class
 > Bryce> loading mechanism.  This mechanism itself uses those java.text
 > Bryce> classes, and in some cases we get an
 > Bryce> ExceptionInInitializerError due to intializer co-dependency.
 >
 > Bryce> +  private void initializeDateFormats()
 >
 > Shouldn't this be synchronized?
 > And shouldn't the body then check again for "locale == null"?
 
 Well now that you point this out, it will have to synchronize around the
 "locale == null" check in getHeaderDateField() too. Bummer.
 
 regards
 
   [ bryce ]
 
 

From: Tom Tromey <tromey@cygnus.com>
To: Bryce McKinlay <bryce@albatross.co.nz>
Cc: tromey@cygnus.com, java-gnats@sourceware.cygnus.com,
        Java Patch List <java-patches@sourceware.cygnus.com>
Subject: Re: libgcj/38
Date: Fri, 25 Feb 2000 00:55:55 -0800 (PST)

 Bryce>  Well now that you point this out, it will have to synchronize
 Bryce>  around the "locale == null" check in getHeaderDateField()
 Bryce>  too. Bummer.
 
 Actually, you don't.  Just have redundant checks.  The outer check (in
 getHeaderDateField) doesn't have to be synchronized, because we do a
 properly synchronized in the init function.
 
 We use this same idiom elsewhere in libgcj.  This gives good
 performance in the common case (no sync needed), but is also
 guaranteed to be correct.
 
 Tom
 

From: Bryce McKinlay <bryce@albatross.co.nz>
To: Tom Tromey <tromey@cygnus.com>
Cc: java-gnats@sourceware.cygnus.com,
        Java Patch List <java-patches@sourceware.cygnus.com>
Subject: Re: libgcj/38
Date: Fri, 25 Feb 2000 22:18:09 +1300

 Tom Tromey wrote:
 
 > Bryce>  Well now that you point this out, it will have to synchronize
 > Bryce>  around the "locale == null" check in getHeaderDateField()
 > Bryce>  too. Bummer.
 >
 > Actually, you don't.  Just have redundant checks.  The outer check (in
 > getHeaderDateField) doesn't have to be synchronized, because we do a
 > properly synchronized in the init function.
 >
 > We use this same idiom elsewhere in libgcj.  This gives good
 > performance in the common case (no sync needed), but is also
 > guaranteed to be correct.
 
 Hmm... I don't think that is 100% safe in this case. ie:
 
 Thread A reaches the null locale check in getHeaderDateField(), and calls
 initializeDateFields() which is synchronized. It finishes initializing
 the 'locale' field before the kernel switches context to Thread B, which
 is sitting just before the null locale check. Thread B sees that locale
 is not null, and so tries, unsynchronized, to access 'dateFormat1'.
 NullPointerException.
 
 But I understand what your getting at. The right solution is to use a
 boolean instead, which gets set after the dateFormal fields have all been
 set. Right?
 
 regards
 
   [ bryce ]
 
 
 

From: Tom Tromey <tromey@cygnus.com>
To: Bryce McKinlay <bryce@albatross.co.nz>
Cc: Tom Tromey <tromey@cygnus.com>, java-gnats@sourceware.cygnus.com,
        Java Patch List <java-patches@sourceware.cygnus.com>
Subject: Re: libgcj/38
Date: Fri, 25 Feb 2000 10:14:03 -0800 (PST)

 Bryce> Hmm... I don't think that is 100% safe in this case. ie:
 
 You're right.
 
 Bryce> But I understand what your getting at. The right solution is to
 Bryce> use a boolean instead, which gets set after the dateFormal
 Bryce> fields have all been set. Right?
 
 Or set the locale field last in initializeDateFormats().  If you go
 this route, be sure to comment it, as it is obscure.  Which one you
 choose is up to you, though...
 
 Tom

From: bryce@sourceware.cygnus.com
To: java-gnats@sourceware.cygnus.com
Cc:  
Subject: libgcj/38
Date: 25 Feb 2000 22:38:34 -0000

 CVSROOT:	/cvs/java
 Module name:	libgcj
 Changes by:	bryce@sourceware.cygnus.com	00/02/25 14:38:34
 
 Modified files:
 	libjava        : ChangeLog 
 	libjava/java/net: URLConnection.java 
 
 Log message:
 	2000-02-25  Bryce McKinlay  <bryce@albatross.co.nz>
 	
 	* java/net/URLConnection.java (initializeDateFormats): New
 	private method.
 	(getHeaderFieldDate): Call initializeDateFormats if required.
 	locale, dateFormat1, dateFormat2, dateFormat3: Don't initialize
 	these.
 	Fix for PR libgcj/38.
 
 Patches:
 http://gcc.gnu.org/cgi-bin/gcc/libjava/ChangeLog.diff?cvsroot=java&r1=1.295&r2=1.296
 http://gcc.gnu.org/cgi-bin/gcc/libjava/java/net/URLConnection.java.diff?cvsroot=java&r1=1.3&r2=1.4
 
State-Changed-From-To: open->closed
State-Changed-By: bryce
State-Changed-When: Fri Feb 25 14:44:38 2000
State-Changed-Why:
    A patch was checked in.

From: bryce@albatross.co.nz
To: bryce@albatross.co.nz, java-gnats@sourceware.cygnus.com, tromey@cygnus.com
Cc:  
Subject: Re: libgcj/38
Date: 25 Feb 2000 22:44:38 -0000

 Synopsis: Static initializer in DecimalFormat eventually depends on itself
 
 State-Changed-From-To: open->closed
 State-Changed-By: bryce
 State-Changed-When: Fri Feb 25 14:44:38 2000
 State-Changed-Why:
     A patch was checked in.
 
 http://sourceware.cygnus.com/cgi-bin/gnatsweb.pl?cmd=view&pr=38&database=java
>Unformatted: