libgcj signal handling problem

Wed Aug 20 03:53:00 GMT 2003

On Tue, Aug 19, 2003 at 05:42:47PM +0100, Andrew Haley wrote:
> Cesar Eduardo Barros writes:
> > On Tue, Aug 19, 2003 at 03:00:07AM -0700, Andrew Morton wrote:
> > > Andrew Haley <aph@redhat.com> wrote:
> > > >
> > > > Andrew, I have appended a patch. I'd be grateful if you would try
> > > > this patch on the system where you observed the problem.
> > > 
> > > ah, sorry, I was not the person who reported the problem. It was
> > > Cesar Barros (Cc'ed here).
> > > 
> > > Perhaps he can test the change..
> > 
> > If you want me to test, you'll have to wait some hours; it's a K6 350,
> > so it will take some time to compile. I'll get back to you after I have
> > the results. From what I have understood, any box with 2.6.0-test3 will
> > have the same problem, so if you want to test, I'm attaching the
> > original testcase. It will be faster than waiting for me to compile ;-)
>> I want you to test it, so that we can prove the bug is fixed on the
> exact same kernel that displayed the problem. You don't need to
> rebuild all of gcc, just go into i686-linux-gnu/libjava and 'make
> libgcj.la; make install-exec'
>
I applied the patch to the Debian sources of the version I was using
(gcc-3.3_3.3.1ds0-0pre0, which seems to be a gcc snapshot of 20030626)
and recompiled it. I had to fix the file manually after applying the
patch (it got confused by the fact that the variable declarations were
outside the functions), but it compiled fine.
After installing the fixed libgcj4 package, the testcase I attached in a
previous email worked fine. It didn't break anything on 2.4.20 (both the
testcase and iRATE (irate.sf.net) still work fine). And the testcase
which originally discovered the bug (jakarta commons lang's) now runs
without crashing (4 failures, I'll look at it later).
So, I can say the patch fixes the bug and does not seem to break
anything.
I will send tomorrow a pointer to the patch to the Debian BTS to make
sure it gets in the next Debian package (so I don't have to recompile
anything).
-- 
Cesar Eduardo Barros
cesarb@nitnet.com.br
cesarb@dcc.ufrj.br