Bug 216995

Summary: azureus crashes in SWT
Product: [Fedora] Fedora Reporter: Nicholas Miell <nmiell>
Component: eclipseAssignee: Ben Konrath <ben>
Status: CLOSED UPSTREAM QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 6   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-11-23 02:49:45 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Nicholas Miell 2006-11-23 01:36:57 UTC
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-23 01:40:41 UTC
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-23 01:42:40 UTC
(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-23 02:06:17 UTC
Alternately, SWT's JNI is buggy, but GCJ doesn't show the bug.

Comment 4 Andrew Overholt 2006-11-23 02:08:05 UTC
(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-23 02:49:45 UTC
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 05:01:03 UTC
(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.