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.
