This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: libjava test suite keeps getting stuck
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