Bug 216995 - azureus crashes in SWT
azureus crashes in SWT
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: eclipse (Show other bugs)
6
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ben Konrath
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-11-22 20:36 EST by Nicholas Miell
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-11-22 21:49:45 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Nicholas Miell 2006-11-22 20:36:57 EST
Description of problem:
Azureus will occasionally crash in SWT. When this happens, it's persistent state
on disk will cause it to crash immediately after startup every time it is
started until you delete ~/.azureus.

Version-Release number of selected component (if applicable):
azureus-2.5.0.0-8.fc6
libswt3-gtk2-3.2.1-4.fc6
java-1.5.0-sun-1.5.0.09-1jpp (I don't know if this also happens with GCJ).

How reproducible:
Largely unrepoducable, but when it happens, it'll always happen at startup until
you delete ~/.azureus

Additional info:
Backtrace (this is using
http://www.jankratochvil.net/priv/gdb-6.5.50.20061111-cvs.x86_64.gz -- as a
bonus, the generated core dumps crash the current FC6 gdb. Unfortunately, this
gdb snapshot can't seem to find debuginfo files reliably, so this trace is
probably wrong.).

Core was generated by `java
-Dgnu.gcj.runtime.VMClassLoader.library_control=never -Dazureus.install.pa'.
Program terminated with signal 6, Aborted.
#0  0x00000032554301b5 in raise () from /lib64/libc.so.6
(gdb) bt
#0  0x00000032554301b5 in raise () from /lib64/libc.so.6
#1  0x0000003255431b20 in abort () from /lib64/libc.so.6
#2  0x00002aaaab035162 in os::abort ()
   from /usr/lib/jvm/java-1.5.0-sun-1.5.0.09/jre/lib/amd64/server/libjvm.so
#3  0x00002aaaab12ea50 in VMError::report_and_die ()
   from /usr/lib/jvm/java-1.5.0-sun-1.5.0.09/jre/lib/amd64/server/libjvm.so
#4  0x00002aaaab0391cf in JVM_handle_linux_signal ()
   from /usr/lib/jvm/java-1.5.0-sun-1.5.0.09/jre/lib/amd64/server/libjvm.so
#5  0x00002aaaab036d5e in signalHandler ()
   from /usr/lib/jvm/java-1.5.0-sun-1.5.0.09/jre/lib/amd64/server/libjvm.so
#6  <signal handler called>
#7  0x00002aaaaae8b335 in get_method_id ()
   from /usr/lib/jvm/java-1.5.0-sun-1.5.0.09/jre/lib/amd64/server/libjvm.so
#8  0x00002aaaaae69165 in jni_GetStaticMethodID ()
   from /usr/lib/jvm/java-1.5.0-sun-1.5.0.09/jre/lib/amd64/server/libjvm.so
#9  0x00002aaae0707887 in ?? () from /usr/lib64/libgtkjni-2.8.so
#10 0x000000325b034eff in g_logv () from /lib64/libglib-2.0.so.0
#11 0x000000325b0350d3 in g_log () from /lib64/libglib-2.0.so.0
#12 0x00000033a9e3225f in gtk_widget_size_allocate ()
   from /usr/lib64/libgtk-x11-2.0.so.0
#13 0x00002aaadb1aee7a in
Java_org_eclipse_swt_internal_gtk_OS__1gtk_1widget_1size_1allocate () from
/usr/lib64/eclipse/libswt-pi-gtk-3235.so
#14 0x00002aaaae87a562 in ?? ()
#15 0x0000000000210760 in ?? ()
#16 0x00002aaaae87aa4e in ?? ()
#17 0x00000000ffffffff in ?? ()
#18 0x00007fffcc9fb348 in ?? ()
#19 0x00007fffcc9fb270 in ?? ()
#20 0x0000000000000000 in ?? ()
(gdb)
Comment 1 Nicholas Miell 2006-11-22 20:40:41 EST
Ok, it crashed again, so I switched to GCJ and restarted Azureus and this time
it did not crash. So, this seems to be exclusively a problem with SWT and Sun Java.
Comment 2 Andrew Overholt 2006-11-22 20:42:40 EST
(In reply to comment #1)
> So, this seems to be exclusively a problem with SWT and Sun Java.

... which we can't fix because it's closed source.  I'm glad it works with gcj.
 Closing CANTFIX.
Comment 3 Nicholas Miell 2006-11-22 21:06:17 EST
Alternately, SWT's JNI is buggy, but GCJ doesn't show the bug.
Comment 4 Andrew Overholt 2006-11-22 21:08:05 EST
(In reply to comment #3)
> Alternately, SWT's JNI is buggy, but GCJ doesn't show the bug.

:)  Argue that with them upstream if you want.  Without a reproducer with what
we ship (the free stack), it's hard to see how we'll progress fixing this. 
Perhaps it's an azureus bug?
Comment 5 Nicholas Miell 2006-11-22 21:49:45 EST
Sorry, I assumed Red Hat was doing more with this part of the Java stack than
just shipping it. Looks like you aren't and your SWT is surprisingly unmodified
from upstream. :)

I'll file upstream as soon as I can find a version of gdb that both doesn't
crash on the core dump and can actually find the debug symbols.
Comment 6 Andrew Overholt 2006-11-23 00:01:03 EST
(In reply to comment #5)
> Sorry, I assumed Red Hat was doing more with this part of the Java stack than
> just shipping it. Looks like you aren't and your SWT is surprisingly unmodified
> from upstream. :)

We try to do as much upstream as possible.  Plus, upstream does an excellent job
without our help :)

> I'll file upstream as soon as I can find a version of gdb that both doesn't
> crash on the core dump and can actually find the debug symbols.

Cool, thanks.  CC me on the bug if you remember.

Note You need to log in before you can comment on or make changes to this bug.