Community
Participate
Working Groups
Build ID: 3.4.0.I20080521-2000 Steps To Reproduce: I ran into an issue where I get a java core dump when using ImageDescriptor.createImage. The issue only happens in linux redhat (not SLED or windows XP). The following works just fine: try{ String f = "http://www.labpixies.com/campaigns/weather/images/thumbnail.jpg"; ImageDescriptor thumbDescr = ImageDescriptor.createFromURL(new URL(f)); if (thumbDescr != null) { Image image = thumbDescr.createImage(); System.out.println(image); } }catch(Exception e){ e.printStackTrace(); } BUT if you download the image to local file system and try using that file java will core dump: try{ String f = "file:///home/user1/thumbnail.jpg"; ImageDescriptor thumbDescr = ImageDescriptor.createFromURL(new URL(f)); if (thumbDescr != null) { Image image = thumbDescr.createImage(); System.out.println(image); } }catch(Exception e){ e.printStackTrace(); } The core dump is here: 0SECTION THREADS subcomponent dump routine NULL ================================= NULL 1XMCURTHDINFO Current Thread Details NULL ---------------------- 3XMTHREADINFO "Worker-6" TID:0x08936500, j9thread_t:0xA2D603C8, state:R, prio=5 3XMTHREADINFO1 (native thread ID:0x6038, native priority:0x5, native policy:UNKNOWN) 4XESTACKTRACE at org/eclipse/swt/internal/gtk/OS._gdk_pixbuf_new_from_file(Native Method) 4XESTACKTRACE at org/eclipse/swt/internal/gtk/OS.gdk_pixbuf_new_from_file(Bytecode PC:9) 4XESTACKTRACE at org/eclipse/swt/graphics/Image.<init>(Bytecode PC:64(Compiled Code)) 4XESTACKTRACE at org/eclipse/jface/resource/URLImageDescriptor.createImage(Bytecode PC:22) 4XESTACKTRACE at org/eclipse/jface/resource/ImageDescriptor.createImage(Bytecode PC:5) 4XESTACKTRACE at org/eclipse/jface/resource/ImageDescriptor.createImage(Bytecode PC:2) More information:
What version of RHEL are you using? What is your gtk+ version? Are you on a 32-bit machine or a 64-bit machine? Are you using the 32-bit or 64-bit download of Eclipse? What Java runtime environment are you using?
RHEL 5.1 rpm -q gtk+ = 1.2.10-56.el5 32 bit machine 32 bit eclipse JRE info: java version "1.6.0" Java(TM) SE Runtime Environment (build pxi3260sr1ifix-20080709_02(SR1+133778.1+IZ25540+IZ25963)) IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Linux x86-32 jvmxi3260-20080415_18762 (JIT enabled, AOT enabled) J9VM - 20080415_018762_lHdSMr JIT - r9_20080415_1520 GC - 20080415_AA) JCL - 20080707_01 [db2admin@Rhel5clean4 bin]$ ./notes2 -version java version "1.6.0" Java(TM) SE Runtime Environment (build pxi3260sr1ifix-20080709_02(SR1+133778.1+IZ25540+IZ25963)) IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Linux x86-32 jvmxi3260-20080415_18762 (JIT enabled, AOT enabled) J9VM - 20080415_018762_lHdSMr JIT - r9_20080415_1520 GC - 20080415_AA) JCL - 20080707_01
Bug in the native GTK image loader?
I tried this on my RHEL5 and it worked for me - I'm on GTK 2.10.4-16. I think the only difference between our configs is that I am using Sun JRE 6. Could you try with another JRE?
A bit more info... When I launch my debug session via the IDE, I am launching the new Notes Client that is built on top of eclipse. When testing with an eclipse launch configuration via the IDE, I cannot reproduce this issue no matter what JRE I use. I should have tested this before I wrote the bugzilla. So it seems like it would be an issue with the Notes Client environment, but I can't imaging what it would be. Both environments are using the same JRE. Both are using the same versions of org.eclipse.swt and org.eclipse.swt.linux.x86. I am running the same action with the same file.
> Both are using the same versions of org.eclipse.swt and > org.eclipse.swt.linux.x86. Are we 100% sure of that? Try using the SWT from CVS HEAD and see whether it crashes or not. See: http://www.eclipse.org/swt/cvs.php
I compared the jar names an they had the same exact names (dates). I'll try with SWT from HEAD.
... and sizes?
The file sizes were a tiny bit diferent but I believe it is due to jar signing files. I tried with SWT from HEAD in my Notes environment and I get the same result.
I have also tried to reproduce this on our RHEL4 machine but, once again, it works for me. As the bug seems to happen only with your particular configuration and not with a base Eclipse install, there's not much more I can do at my end. I need you to either set me up with access to your system or somehow instruct me how to recreate your exact workspace in order to proceed. Needless to say, this bug is not under consideration for 3.4.1 as I can't even recreate it yet.
Tryig to get some of our eclipe/UI experts to take a look on our end.
OK - keep us posted.
We can't reproduce this issue anymore.
Please reopen if you get it again.