Andrew John Hughes wrote: > 2009/2/4 Andrew Haley <aph@xxxxxxxxxx>: >> Andrew John Hughes wrote: >>> 2009/2/4 Andrew Haley <aph@xxxxxxxxxx>: >>>> 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 <doko@xxxxxxxxxx> >> >> 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.
