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
-~----------~----~----~----~------~----~------~--~---

Reply via email to