This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: Patch: FYI: re-enable xlib peers
- From: "Scott Gilbertson" <scottg at mantatest dot com>
- To: <tromey at redhat dot com>
- Cc: "Java Patch List" <java-patches at gcc dot gnu dot org>
- Date: Mon, 22 Aug 2005 19:35:07 -0400
- Subject: Re: Patch: FYI: re-enable xlib peers
>
> > Scott> then says "Aborted". Interpreted, it immediately aborts
> > Scott> without apparently doing anything at all.
> >
> > I don't see this. This kind of error is pretty serious ...
>
> It doesn't happen with every program, and I can't really see what was
going
> on in order to produce a small test case. It looks as though a throw
isn't
> working, but a trivial exception-throwing example works fine. I just
> fetched a new tree, which I'm building now, and I'll see if the abort
still
> happens with that build.
>
Yes, it happens with the code I fetched today.
The backtrace looks just like before, including the line:
#5 0x408416e9 in _Jv_Throw (value=0x2b1948) at
../../../gcc/libjava/exception.cc:111
(see code snippet below)
It's probably a matter of something corrupting the stack, I guess, but I'm
not sure how to find out what's doing it.
----------------------------------------------------------
The backtrace:
#0 0x4147aca1 in kill () from /lib/i686/libc.so.6
#1 0x413f63a1 in pthread_kill () from /lib/i686/libpthread.so.0
#2 0x413f671b in raise () from /lib/i686/libpthread.so.0
#3 0x4147a908 in raise () from /lib/i686/libc.so.6
#4 0x4147bf70 in abort () from /lib/i686/libc.so.6
#5 0x40846eb1 in _Jv_Throw (value=0x2727f8) at
../../../gcc/libjava/exception.cc:111
#6 0x40a47c91 in java.net.URLClassLoader.findClass(java.lang.String)
(this=0x2728e8,
className=0x0) at URLClassLoader.java:1011
#7 0x4138a45c in __JCR_END__ () from
/var/local/gcc/tip_20050822/lib/libgcj.so.7
#8 0x002728e8 in ?? ()
#9 0x00000000 in ?? ()
#10 0x00061f88 in ?? ()
#11 0x40a2c623 in java.lang.ClassLoader.loadClass(java.lang.String, boolean)
(
this=0x0, name=0x4138a45c, resolve=64) at ClassLoader.java:317
----------------------------------------------------------
Line 111 is the "abort" at the bottom of the following snippet.
extern "C" void
_Jv_Throw (jthrowable value)
{
java_exception_header *xh
= static_cast<java_exception_header *>(_Jv_AllocRawObj (sizeof (*xh)));
if (value == NULL)
value = new java::lang::NullPointerException ();
xh->value = value;
xh->unwindHeader.exception_class = __gcj_exception_class;
xh->unwindHeader.exception_cleanup = NULL;
/* We're happy with setjmp/longjmp exceptions or region-based
exception handlers: entry points are provided here for both. */
_Unwind_Reason_Code code;
#ifdef SJLJ_EXCEPTIONS
code = _Unwind_SjLj_RaiseException (&xh->unwindHeader);
#else
code = _Unwind_RaiseException (&xh->unwindHeader);
#endif
/* If code == _URC_END_OF_STACK, then we reached top of stack without
finding a handler for the exception. Since each thread is run in
a try/catch, this oughtn't happen. If code is something else, we
encountered some sort of heinous lossage from which we could not
recover. As is the way of such things, almost certainly we will have
crashed before now, rather than actually being able to diagnose the
problem. */
abort();
}