Re: 0.98 Release Imminent

Andrew John Hughes wrote:
> 2009/2/4 Andrew Haley <[email protected]>:
>> Andrew John Hughes wrote:
>>> 2009/2/4 Andrew Haley <[email protected]>:
>>>> Andrew John Hughes wrote:
>>>>> I plan to release 0.98 on Thursday before FOSDEM, now that the
>>>>> security issue has been patched:
>>>>>
>>>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38417
>>>>>
>>>>> If there are any major bugs that mean a release should not go ahead,
>>>>> please let me know ASAP.
>>>> I have found a deadlock in gcj in AWT even processing.  I don't know
>>>> if it affects all of Classpath, but I think so.
>>> Do you have any more details? I'll see if I can replicate it here.
>> Found it, and it's already fixed in Classpath.  It's this:
>>
>> http://article.gmane.org/gmane.comp.java.classpath.patches/12149
>>
>> Despite the fact that this patch was written in mid-2007 it is still not
>> in the gcc 4.3 branch.  Unfortunately, gcc 4.3.3 was released last
>> Sunday.  :-(
>>
>> It looks like the last Classpath import for gcc 4.3 was this:
>>
>> 2007-08-04  Matthias Klose  <[email protected]>
>>
>>        Import GNU Classpath (libgcj-import-20070727).
>>
>> which means that this change of 2007-08-23 missed gcc 4.3, even though
>> 4.3 wasn't released until 2008-03-05.
>>
>> Thus, every gcj ever released has this evil deadlock, even that in
>> Fedora 10.
> 
> Ouch... we really should be doing better at keeping these in sync.

Indeed.  The Right Thing to do, when a nasty bug is found, is to make
sure it gets back-ported everywhere.  In August 2007 we were working flat
out on OpenJDK, so we dropped the ball.

> This is partly why I want to get another Classpath release sorted.  At
> the moment, GCJ and Classpath are pretty much in sync (I'll merge
> across Mario's patch and any remaining fixes against the 0.98 tag once
> made).

Be careful; gcc is in Stage 4 at the moment, so only fixes for regressions
(and changes to documentation) are allowed.  If a libgcj bug is really evil
we can allow it, but the regression that has probably have been caused by

2009-02-03  Andrew John Hughes  <ahughes <at> redhat.com>

	* native/jni/native-lib/cpproc.c:
	(cpproc_forkAndExec): Handle return of
	chdir.

shows just how tricky "obvious" bug fixes can be.  In this case,
cpproc_forkAndExec is being handed a null directory, which means
"don't change the working dir".  Doing this by calling chdir and
ignoring the retcode is wrong too, but less wrong than the "fix".

> This should mean 4.4 ~= 0.98 and we can then port across any
> appropriate bug/security fixes that occur more easily.  We shouldn't
> just stop merging code from Classpath once a gcc is frozen (though
> obviously we shouldn't merge new features to such a branch either).

Indeed not.

Andrew.