here is vtable dump for klass
as you can see , klass->engine of dynamic version is NULL 
whereas static version got proper instance though....
so klass->engine->verify(klass); invokes SEGV.......
but why does it happened??? some linker problem??
$ diff static dynamic -ud
--- static      2010-01-09 02:43:35.750000000 +0900
+++ dynamic     2010-01-09 02:43:36.187500000 +0900
@@ -1,23 +1,23 @@
 (gdb) print *klass
-$1 = (java::lang::Class) {
+$2 = (java::lang::Class) {
   <> = {<No data fields>},
   members of java::lang::Class:
   static class$ = {
     <> = {<No data fields>},
     members of java::lang::Class:
     static class$ = <same as static member of an already seen type>,
-    next_or_version = 0x0,
-    name = 0xe2e9f4,
+    next_or_version = 0x40062e08,
+    name = 0x6c7f70b4,
     accflags = 49,
-    superclass = 0xb5c900,
+    superclass = 0x6c587100,
     constants = {
       size = 37,
-      tags = 0xb5c180 "",
-      data = 0xb5c0e0
+      tags = 0x6c587580 "",
+      data = 0x6c5874e0
     },
     {
-      methods = 0xb5c1c0,
-      element_type = 0xb5c1c0
+      methods = 0x6c5875c0,
+      element_type = 0x6c5875c0
     },
     method_count = 82,
     vtable_method_count = 65,
@@ -26,15 +26,15 @@
 ---Type <return> to continue, or q <return> to quit---
     field_count = 0,
     static_field_count = 0,
-    vtable = 0xb5bf28,
+    vtable = 0x6c587328,
     otable = 0x0,
     otable_syms = 0x0,
     atable = 0x0,
     atable_syms = 0x0,
     itable = 0x0,
     itable_syms = 0x0,
-    catch_classes = 0xb5c828,
-    interfaces = 0xb5c840,
+    catch_classes = 0x6c587c28,
+    interfaces = 0x6c587c40,
     loader = 0x0,
     interface_count = 4,
     state = 1 '\001',
@@ -52,37 +52,37 @@
     hack_signers = 0x0,
     chain = 0x0,
     aux_info = 0x0,
-    engine = 0x1173040,
-    reflection_data = 0xe2ea20 "\001"
+    engine = 0x0,
+    reflection_data = 0x6c7f70e0 "\001"
   },
-  next_or_version = 0x0,
-  name = 0xdfea20,
+  next_or_version = 0x40062e08,
+  name = 0x6c8cb860,
   accflags = 1057,
-  superclass = 0xb5c900,
+  superclass = 0x6c587100,
   constants = {
     size = 24,
-    tags = 0xb1c838 "",
-    data = 0xb19d00
+    tags = 0x6c6a12d8 "",
+    data = 0x6c69e7a0
   },
   {
-    methods = 0xb1c860,
-    element_type = 0xb1c860
+    methods = 0x6c6a1300,
+    element_type = 0x6c6a1300
   },
   method_count = 37,
   vtable_method_count = 34,
-  fields = 0xb1cb60,
+  fields = 0x6c6a1600,
   size_in_bytes = 44,
   field_count = 13,
 ---Type <return> to continue, or q <return> to quit---
   static_field_count = 4,
-  vtable = 0xb13888,
+  vtable = 0x6c698328,
   otable = 0x0,
   otable_syms = 0x0,
   atable = 0x0,
   atable_syms = 0x0,
   itable = 0x0,
   itable_syms = 0x0,
-  catch_classes = 0xb1cc30,
+  catch_classes = 0x6c6a16d0,
   interfaces = 0x0,
   loader = 0x0,
   interface_count = 0,
@@ -101,6 +101,6 @@
 ---Type <return> to continue, or q <return> to quit---
   chain = 0x0,
   aux_info = 0x0,
-  engine = 0x1173040,
-  reflection_data = 0xdfea40 "\002"
+  engine = 0x0,
+  reflection_data = 0x6c8cb880 "\002"

\ No newline at end of file

maybe this could be linker problem. jcr section doesn't seem preserved in shared library.

00ffd668 d ___JCR_LIST__
010021c4 d ___JCR_END__

004097b4 d ___JCR_LIST__
004097c0 d ___JCR_END__

[ Replying to your post on binutils list ]

jojelino wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42658
> 
> it is critical when linking libgcj library hence it uses .jcr section to 
> initialize java class CTORs
> 
> how can we workaround this phenomenon??
> 
> $ nm -sn cyggcj-11.dll |grep JCR
> 6c9487d0 d ___JCR_END__
> 6c9487d0 d ___JCR_LIST__

  I can't reproduce this: after bootstrapping GCC at r.155680, I get:

$ nm -sn i686-pc-cygwin/libjava/.libs/cyggcj-11.dll |grep JCR
6c93ecd0 d ___JCR_LIST__
6c94382c d ___JCR_END__

Also, gcj-dbtool works for me:

$ PATH=./i686-pc-cygwin/libjava/.libs:$PATH  ./i686-pc-cygwin/libjava/.libs/gcj
-dbtool.exe  --help
gcj-dbtool: Manipulate gcj map database files

  Usage:
    gcj-dbtool -n file.gcjdb [size]     - Create a new gcj map database
    gcj-dbtool -a file.gcjdb file.jar file.so
            - Add the contents of file.jar to a gcj map database
    gcj-dbtool -f file.gcjdb file.jar file.so
            - Add the contents of file.jar to a gcj map database
    gcj-dbtool -t file.gcjdb            - Test a gcj map database
    gcj-dbtool -l file.gcjdb            - List a gcj map database
    gcj-dbtool [-][-0] -m dest.gcjdb [source.gcjdb]...
            - Merge gcj map databases into dest
              Replaces dest
              To add to dest, include dest in the list of sources
              If the first arg is -, read the list from stdin
              If the first arg is -0, filenames separated by nul
    gcj-dbtool -p [LIBDIR]              - Print default database name



What version of binutils are you using, and how do you configure your GCC build?

Created attachment 19517 [details]
diff file i used

here is configuration 
./configure --prefix=/usr --disable-win32-registry --enable-threads=posix --enable-languages=c,c++,java --with-win32-nlsapi=unicode --enable-tls --disable-bootstrap --enable-shared --enable-interpreter --disable-sjlj-exceptions --enable-java-awt=gtk

Comment on attachment 19517 [details]
diff file i used

here is configuration
./configure --prefix=/usr --disable-win32-registry --enable-threads=posix --enable-languages=c,c++,java --with-win32-nlsapi=unicode --enable-tls --disable-bootstrap --enable-shared --enable-interpreter --disable-sjlj-exceptions --enable-java-awt=gtk

and i used binutils 
GNU ld (GNU Binutils) 2.20.51.20100108

(In reply to comment #4)
> Created an attachment (id=19517) [edit]
> diff file i used

  I don't like the look of this one:

diff --git a/libjava/configure.host b/libjava/configure.host
old mode 100644
new mode 100755
index 3baaf27..74aac08
--- a/libjava/configure.host
+++ b/libjava/configure.host
@@ -353,7 +353,7 @@ case "${host}" in
   	BACKTRACESPEC=
 	# Win32 DLLs are limited to 64k exported symbols each.
 	enable_libgcj_sublibs_default=yes
-	libgcj_sublib_ltflags='-no-undefined -bindir $(bindir)'
+	libgcj_sublib_ltflags='-Wl,--export-all-symbols -no-undefined -bindir $(bindir)'


I don't know what the intent is of this change.  It shouldn't be necessary, I hope, and one possible result of exporting all the undesired symbols is that you may have pushed the number of exports from the dll over 65535, which breaks it.  Can you please run "objdump -p cyggcj-11.dll > hdrs.txt" and attach hdrs.txt to the PR?

Created attachment 19520 [details]
gzipped text

oh my. it counts more than 65535.. [167929]
and gzipped file exceed limit 1000k so i can't attach it at once.

--export-all-symbols was added because of undefined symbol error.

(In reply to comment #7)
> Created an attachment (id=19520) [edit]
> gzipped text
> 
> oh my. it counts more than 65535.. [167929]

  !LOL!  That's rather a lot!

> and gzipped file exceed limit 1000k so i can't attach it at once.

  No, OK, never mind; we have found the problem!
 
> --export-all-symbols was added because of undefined symbol error.

  Well it is the wrong answer; as you can see it is too crude.  It is vital that the version script is applied to filter out the undesired symbols from being exported.

  Where did the undefined symbols come from?  They must also be a result of that patch somehow, no?  Do you get any problem at all from plain unmodified GCC head?

Comment on attachment 19520 [details]
gzipped text

oh my i ran objdump -t instead of objdump -p
i'm sorry for this.

Created attachment 19521 [details]
undefined symbol list

this is undefined symbol list when i link without --export-all-symbols
when linking libgcj-noncore.dll

Ah.  It's probably caused by --enable-java-awt.  AWT isn't yet supported on cygwin yet; looks like it will need some adjustment to the way .o files are divided between the two dlls, most likely.

Can you confirm whether or not you get this bug with completely clean unmodified sources?  I'm guessing that, without your patch to configure, it would have errored out with the option present?

(In reply to comment #11)
> Ah.  It's probably caused by --enable-java-awt.  AWT isn't yet supported on
> cygwin yet; looks like it will need some adjustment to the way .o files are
> divided between the two dlls, most likely.
> 
> Can you confirm whether or not you get this bug with completely clean
> unmodified sources?  I'm guessing that, without your patch to configure, it
> would have errored out with the option present?
> 

whenever i fetch gcc from git, i must run git reset --hard so it will be unmodified source at first. after that, i apply these patches.
unless it doesn't compile at all ;<

Created attachment 19522 [details]
hdrs (with --export-all-symbols) which i should have attached

it counts 57439 whoa,
what happens if total number of export symbols of dlls exceed 65535?
i'm just curious about it.

(In reply to comment #12)
> (In reply to comment #11)
> > Ah.  It's probably caused by --enable-java-awt.  AWT isn't yet supported on
> > cygwin yet; looks like it will need some adjustment to the way .o files are
> > divided between the two dlls, most likely.
> > 
> > Can you confirm whether or not you get this bug with completely clean
> > unmodified sources?  I'm guessing that, without your patch to configure, it
> > would have errored out with the option present?
> > 
> 
> whenever i fetch gcc from git, i must run git reset --hard so it will be
> unmodified source at first. after that, i apply these patches.
> unless it doesn't compile at all ;<

Well, I don't use the git repository, and it isn't the source from which releases are taken, and it often gets broken.  So it might not be a real bug in the main gcc sources in svn.  I'll try building the svn version with your configure line and see what happens.

(In reply to comment #13)
> Created an attachment (id=19522) [edit]
> hdrs (with --export-all-symbols) which i should have attached
> 
> it counts 57439 whoa,
> what happens if total number of export symbols of dlls exceed 65535?
> i'm just curious about it.

Total disaster.  Attempts to access exports >65536 wrap round.  Can end up jumping into random places or loading from invalid memory addreses or almost anything.  Usually dies in early startup.

just waiting to see if this can be reproduced with clean sources.

Confirmed that it was just a glitch of some kind.