libjava test suite keeps getting stuck

Thu Apr 19 19:37:00 GMT 2001

On Thu, Apr 19, 2001 at 08:13:35PM -0600, Tom Tromey wrote:
> >>>>> "Zack" == Zack Weinberg <zackw@Stanford.EDU> writes:
>> Zack> There's a libtool bug and at least one libjava bug confusing the
> Zack> issue. The libtool bug: it links libgcc_s and libc ahead of
> Zack> libpthread, which obviously will cause problems, because
> Zack> libpthread won't get to override libc symbols. I think this is
> Zack> the transitive dependencies issue that was being discussed the
> Zack> other week.
>> I thought Alexandre Oliva checked in a fix for this bug a while back.
> This is the patch I'm thinking of:
>> 2001年04月12日 Alexandre Oliva <aoliva@redhat.com>
>> * ltconfig, ltmain.sh, libtool.m4, ltcf-c.sh, ltcf-cxx.sh,
> ltcf-gcj.sh: Upgraded to libtool 1.4a 1.641.2.226.

I've got that, but it doesn't seem to do the trick.
...
> Zack> That exception should have been caught inside Divide_1::probe.
> Zack> All the operations which divide by zero (which this program
> Zack> does, deliberately) are wrapped in try/catch clauses.
>> To me this sounds like some sort of problem with throwing exceptions
> from signal handlers.
>> Zack> #6 0x404c1c4c in uw_frame_state_for (context=0xbfee95f4, fs=0xbfee9534)
> Zack> at ../../../gcc_vanilla/gcc/unwind-dw2.c:966
>> Oh, wait -- this is the trunk! I think you didn't mention that.
>> Throwing exceptions from signal handlers is known to be broken on the
> trunk. The new EH work didn't include a fix to libjava to keep this
> working.

Oh, okay, I must have missed the report.
> I believe Andrew is going to look at this problem (he is the Java EH
> expert), but he is on vacation.
>> Jim Wilson proposed disabling Java on the trunk for the time being.
> That's ok with me as long as we can turn it on again once this problem
> is resolved.

Maybe just #if 0 out HANDLE_(SEGV|FPE) for the moment? Lots of test
suite breakage, but hopefully no infinite loops.
zw