I tested this on F-8 with IcedTea-b24 (rawhide) on i386 and it works.
I, also, tested this on F-8 with IcedTea-b21 (not rawhide) on x86_64 and it works.

Actually, the game works really well. Any idea how else I can reproduce this?
Can you attach the log (/home/hans/.freecol/hs_err_pid13245.log)?

Changing status to NEEDINFO.

Note- I, also, tested this on F-8 with IcedTea-b24 (rawhide) on x86_64 and it works.

After a few tries, I was finally able to reproduce this. I am looking into the
problem:

Stack: [0x0000000040b0b000,0x0000000040c0c000],  sp=0x0000000040c0a100,  free
space=1020k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [ld-linux-x86-64.so.2+0x12d41]

[error occurred during error reporting (printing native stack), id 0xb]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  sun.awt.image.JPEGImageDecoder.initIDs(Ljava/lang/Class;)V+0
j  sun.awt.image.JPEGImageDecoder.<clinit>()V+22
v  ~StubRoutines::call_stub
j 
sun.awt.image.InputStreamImageSource.getDecoder(Ljava/io/InputStream;)Lsun/awt/image/ImageDecoder;+135
j  sun.awt.image.FileImageSource.getDecoder()Lsun/awt/image/ImageDecoder;+27
j  sun.awt.image.InputStreamImageSource.doFetch()V+30
j  sun.awt.image.ImageFetcher.fetchloop()V+33
j  sun.awt.image.ImageFetcher.run()V+5
v  ~StubRoutines::call_stub

Hmm,

Strange that it was hard to reproduce for you, it crashed reproducible for me
(tried 3 times). Maybe this is timing related?

I was able to get this working with the version of IcedTea in the repo. This
will be in rawhide when the next release (b25) is out.

Workaround: Build IcedTea from the mercurial repo and change JAVA_HOME in
/usr/bin/freecol to:

/path/to/openjdk/build/linux-amd64/j2sdk-image/bin/java

(In reply to comment #4)
> Hmm,
> 
> Strange that it was hard to reproduce for you, it crashed reproducible for me
> (tried 3 times). Maybe this is timing related?
> 

I believe my setup was a little messed up, I fixed it and was able to reproduce
it again.

Thx

Duplicate of this bug:
http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=98

(In reply to comment #7)
> Duplicate of this bug:
> http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=98

Ah yes that explains, notice the following important comment which I've just
added to that bug:

Notice that not only the path (/usr/lib instead of /usr/lib64) is a problem,
but also the soname used to open, libjpeg.so will only be present if
libjpeg-devel (Fedora) or distro used equivalent -devel package is installed.

When dlopening libs the full soname should be used, not the .so symlink which
is only there for determining which lib to use when linking during compile of
software!

libjpeg-devel is a requirement for IcedTea. 

IMO, This is not a bug.

No it isn't:

[hans@localhost ~]$ rpm -q --requires java-1.7.0-icedtea
java-1.7.0-icedtea-1.7.0.0-0.24.b24.fc9.x86_64
/bin/sh  
/bin/sh  
/usr/sbin/alternatives  
/usr/sbin/alternatives  
config(java-1.7.0-icedtea) = 1.7.0.0-0.24.b24.fc9
jpackage-utils >= 1.7.3-1jpp.3
ld-linux-x86-64.so.2()(64bit)  
ld-linux-x86-64.so.2(GLIBC_2.3)(64bit)  
libX11.so.6()(64bit)  
libXext.so.6()(64bit)  
libXi.so.6()(64bit)  
libXtst.so.6()(64bit)  
libasound.so.2()(64bit)  
libasound.so.2()(64bit)  
libasound.so.2(ALSA_0.9)(64bit)  
libasound.so.2(ALSA_0.9.0rc4)(64bit)  
libawt.so()(64bit)  
libc.so.6()(64bit)  
libc.so.6(GLIBC_2.2.5)(64bit)  
libc.so.6(GLIBC_2.3)(64bit)  
libc.so.6(GLIBC_2.3.2)(64bit)  
libc.so.6(GLIBC_2.4)(64bit)  
libdl.so.2()(64bit)  
libdl.so.2(GLIBC_2.2.5)(64bit)  
libfreetype.so.6()(64bit)  
libgcc_s.so.1()(64bit) 
libgcc_s.so.1(GCC_3.0)(64bit)  
libgcc_s.so.1(GCC_3.3)(64bit)  
libgcc_s.so.1(GCC_4.2.0)(64bit)  
libgif.so.4()(64bit)  
libjava.so()(64bit)  
libjava.so(SUNWprivate_1.1)(64bit)  
libjli.so()(64bit)  
libjli.so(SUNWprivate_1.1)(64bit)  
libjpeg.so.62()(64bit)  
libjvm.so()(64bit)  
libjvm.so(SUNWprivate_1.1)(64bit)  
libm.so.6()(64bit) 
libm.so.6(GLIBC_2.2.5)(64bit)  
libmawt.so()(64bit)  
libmawt.so(SUNWprivate_1.1)(64bit)  
libnet.so()(64bit)  
libnet.so(SUNWprivate_1.1)(64bit)  
libnsl.so.1()(64bit)  
libpng12.so.0()(64bit)  
libpng12.so.0(PNG12_0)(64bit)  
libpthread.so.0()(64bit)  
libpthread.so.0(GLIBC_2.2.5)(64bit)  
libpthread.so.0(GLIBC_2.3.2)(64bit)  
libpthread.so.0(GLIBC_2.3.3)(64bit)
libthread_db.so.1()(64bit)  
libthread_db.so.1(GLIBC_2.2.5)(64bit)  
libverify.so()(64bit)  
libverify.so(SUNWprivate_1.1)(64bit)  
libz.so.1()(64bit)  
openssl  
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(VersionedDependencies) <= 3.0.3-1
rtld(GNU_HASH)  
tzdata-java  

And the fact that it isn't a Requires, but only a BuildRequires is correct, no
normal package should ever Require a -devel package. Really I might not know
much about java, but trust me on this one, you _must_ dlopen the full soname,
not the .so symlink which is there for development purposes only. I've got 200
(mostly C) packages I maintain (with close to 0 open bugs) and 10 years of C
experience saying so. If still in doubt ask on fedora-devel-list or fedora-devel
on IRC I'm sure others will agree with me.

:) I am not disagreeing with you. I just want to do this the best way. I was
considering adding this as a requirement (it is only a build requirement) at the
moment, but if that is not the best idea, I will look into doing it another way.

thanks

I will fix it to dlopen /usr/lib(64)/libjpeg.so.62.0.0 and add libjpeg-6b-40 as
a requirement to the spec file.

libjpeg-6b not libjpeg-6b-40

libjpeg-devel is still a build requirement. 

These headers:
/usr/include/jconfig.h
/usr/include/jerror.h
/usr/include/jmorecfg.h
/usr/include/jpeglib.h

Are needed by several sources, and only included in the libjpeg-devel package. I
have left the configure script and all build requirements unchanged.

libjpeg = 6b has been added as a requirement to the spec file.

This will be in rawhide within the next couple of days.