Another quick workaround is try to switch the jitter (from -client to -server). In JDK6 and below, these are in fact, separate compilers. I had similar crashes with Java6 on OSX at one point and switching the HotSpot compiler fixed them. -Ray
On Thu, Apr 2, 2009 at 11:16 AM, Scott Blum <sco...@google.com> wrote: > This looks to me like a HotSpot problem.. the jitter is crashing trying to > compile some JDT code. > Current thread (0x08ab8800): JavaThread "CompilerThread0" daemon > [_thread_in_native, id=2484, stack(0xe037f000,0xe0400000)] > > Current CompileTask: > C2:498 > > org.eclipse.jdt.internal.compiler.lookup.ParameterizedMethodBinding.<init>(Lorg/eclipse/jdt/internal/compiler/lookup/ParameterizedTypeBinding;Lorg/eclipse/jdt/internal/compiler/lookup/MethodBinding;)V > (596 bytes) > > So here's how you could try to come up with a workaround / file an issue > against the JVM: > > - Grab our JDT 3.4.2 jar out of the GWT tools repository > - Open it up and find the source for ParameterizedMethodBinding > - Add this source file to your project (you'll need to put gwt-dev-windows > on your path if it's not) > > You should now be able to run a compile and repro the crash. If you > *can't* repro the crash anymore, it's possible your compiler is producing a > slightly different .class file for that class than the class file we ship > (which was built by the JDT guys). > > Assuming you can repro the crash, start commenting out lines of code in the > offending constructor until it no longer crashes. Or start refactoring out > pieces of the constructor into individual methods. By playing around, you > can probably figure out what's killing it. > > > On Fri, Mar 27, 2009 at 2:26 PM, Vitali Lovich <vlov...@gmail.com> wrote: > >> Ugggh... you want me to do all the work don't you :D >> >> On a separate note 5094 compilation is broken (JUnitShell fails to >> compile). In 5096 the problem is resolved. >> >> >> On Fri, Mar 27, 2009 at 2:03 PM, Scott Blum <sco...@google.com> wrote: >> >>> I can has hs_err_pid17105.log? >>> >>> >>> On Fri, Mar 27, 2009 at 12:36 PM, Vitali Lovich <vlov...@gmail.com>wrote: >>> >>>> >>>> [java] Compiling module >>>> com.google.gwt.benchmarks.viewer.ReportViewer >>>> [java] >>>> # >>>> [java] # An unexpected error has been detected by Java Runtime >>>> Environment: >>>> [java] # >>>> [java] # SIGSEGV (0xb) at pc=0x0625665c, pid=17105, tid=3762477968 >>>> [java] # >>>> [java] # Java VM: Java HotSpot(TM) Server VM (10.0-b23 mixed mode >>>> linux-x86) >>>> [java] # Problematic frame: >>>> [java] # V [libjvm.so+0x25665c] >>>> [java] # >>>> [java] # An error report file with more information is saved as: >>>> [java] # >>>> /home/vlovich/workspace/gwt/tools/benchmark-viewer/hs_err_pid17105.log >>>> [java] # >>>> [java] # If you would like to submit a bug report, please visit: >>>> [java] # http://java.sun.com/webapps/bugreport/crash.jsp >>>> [java] # The crash happened outside the Java Virtual Machine in >>>> native code. >>>> [java] # See problematic frame for where to report the bug. >>>> [java] # >>>> >>>> This is kind of annoying because GWT fails to build with the newer JDKs >>>> due to the issue mentioned before with the change to generics. So it's a >>>> two step workaround: Use the older sun JDK to compile the classes & after >>>> it crashes, use run ant again with the newer JDK so that the GWT compiler >>>> doesn't crash the VM. >>>> >>>> This also happens if I try to use the older JDK with my projects, but >>>> that's not really an issue since I just use the latest OpenJDK in the >>>> Ubuntu >>>> repos. >>>> >>>> Might be relevant that I'm using 64-bit jdks. >>>> >>>> >>>> >>> >>> >>> >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
