有谁知道gwt-maven-plugin start和“Compiling module”语句之间可能导致GWT编译失败的原因是什么?
我们正常运行GWT信息所以我在日志中看到的只是插件启动,然后是SIGSEGV。当我在本地运行调试并且没有看到问题时,我可以看到在GWT插件执行以下步骤之一时违规被抛出:
我从一个干净的目录开始,所以我和我的缓存都在目标之下,所以我不认为它在最后两个。由于错误与zip lib条目有关,我怀疑类路径和分辨率可能是问题。
的env
jdk 1.7.0 u55 + gwt 2.5.1 + gwt-maven-plugin 2.5.1-rc1
如果您有任何想法,请告诉我,我正在提高日志级别,改变内存并希望获得可重现的案例。感谢
选项
除了
[INFO] --- gwt-maven-plugin:2.5.1-rc1:compile (default) @ mymodule --- # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00000036a3089aab, pid=14610, tid=140310347593472 # # JRE version: Java(TM) SE Runtime Environment (7.0_55-b13) (build 1.7.0_55-b13) # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.55-b03 mixed mode linux-amd64 compressed oops) # Problematic frame: # C [libc.so.6+0x89aab] memcpy+0x15b ... ... Stack: [0x00007f9c8c5d3000,0x00007f9c8c6d4000], sp=0x00007f9c8c6d0c68, free space=1015k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [libc.so.6+0x89aab] memcpy+0x15b C [libzip.so+0x50b0] ZIP_GetEntry+0xd0 C [libzip.so+0x3eed] Java_java_util_zip_ZipFile_getEntry+0xad J java.util.zip.ZipFile.getEntry(J[BZ)J Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) J java.util.zip.ZipFile.getEntry(J[BZ)J J java.util.zip.ZipFile.getEntry(Ljava/lang/String;)Ljava/util/zip/ZipEntry; J java.util.jar.JarFile.getEntry(Ljava/lang/String;)Ljava/util/zip/ZipEntry; j sun.net.www.protocol.jar.URLJarFile.getEntry(Ljava/lang/String;)Ljava/util/zip/ZipEntry;+2 j sun.net.www.protocol.jar.JarURLConnection.connect()V+62 j sun.net.www.protocol.jar.JarURLConnection.getInputStream()Ljava/io/InputStream;+1 j java.net.URLClassLoader.getResourceAsStream(Ljava/lang/String;)Ljava/io/InputStream;+18 J org.codehaus.mojo.gwt.AbstractGwtModuleMojo.readModule(Ljava/lang/String;)Lorg/codehaus/mojo/gwt/GwtModule; j org.codehaus.mojo.gwt.GwtModule.getLocalInherits()Ljava/util/Set;+74 j org.codehaus.mojo.gwt.GwtModule.addInheritedModules(Ljava/util/Set;Ljava/util/Set;)V+42 j org.codehaus.mojo.gwt.GwtModule.getInherits()Ljava/util/Set;+32 j org.codehaus.mojo.gwt.GwtModule.getEntryPoints()Ljava/util/List;+20 j org.codehaus.mojo.gwt.shell.CompileMojo.compilationRequired(Ljava/lang/String;Ljava/io/File;)Z+35 j org.codehaus.mojo.gwt.shell.CompileMojo.compile([Ljava/lang/String;)V+432 j org.codehaus.mojo.gwt.shell.CompileMojo.doExecute()V+57 j org.codehaus.mojo.gwt.shell.AbstractGwtShellMojo.execute()V+1 j org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(Lorg/apache/maven/execution/MavenSession;Lorg/apache/maven/plugin/MojoExecution;)V+166 j org.apache.maven.lifecycle.internal.MojoExecutor.execute(Lorg/apache/maven/execution/MavenSession;Lorg/apache/maven/plugin/MojoExecution;Lorg/apache/maven/lifecycle/internal/ProjectIndex;Lorg/apache/maven/lifecycle/internal/DependencyContext;)V+215 j org.apache.maven.lifecycle.internal.MojoExecutor.execute(Lorg/apache/maven/execution/MavenSession;Lorg/apache/maven/plugin/MojoExecution;Lorg/apache/maven/lifecycle/internal/ProjectIndex;Lorg/apache/maven/lifecycle/internal/DependencyContext;Lorg/apache/maven/lifecycle/internal/PhaseRecorder;)V+6 j org.apache.maven.lifecycle.internal.MojoExecutor.execute(Lorg/apache/maven/execution/MavenSession;Ljava/util/List;Lorg/apache/maven/lifecycle/internal/ProjectIndex;)V+60 j org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(Lorg/apache/maven/execution/MavenSession;Lorg/apache/maven/execution/MavenSession;Lorg/apache/maven/lifecycle/internal/ReactorContext;Lorg/apache/maven/project/MavenProject;Lorg/apache/maven/lifecycle/internal/TaskSegment;)V+151 j org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(Lorg/apache/maven/execution/MavenSession;Lorg/apache/maven/lifecycle/internal/ReactorContext;Lorg/apache/maven/project/MavenProject;Lorg/apache/maven/lifecycle/internal/TaskSegment;)V+7 j org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(Lorg/apache/maven/execution/MavenSession;Lorg/apache/maven/lifecycle/internal/ReactorContext;Lorg/apache/maven/lifecycle/internal/ProjectBuildList;Ljava/util/List;Lorg/apache/maven/lifecycle/internal/ReactorBuildStatus;)V+77 j org.apache.maven.lifecycle.internal.LifecycleStarter.execute(Lorg/apache/maven/execution/MavenSession;)V+336 j org.apache.maven.DefaultMaven.doExecute(Lorg/apache/maven/execution/MavenExecutionRequest;)Lorg/apache/maven/execution/MavenExecutionResult;+557 j org.apache.maven.DefaultMaven.execute(Lorg/apache/maven/execution/MavenExecutionRequest;)Lorg/apache/maven/execution/MavenExecutionResult;+11 j org.apache.maven.cli.MavenCli.execute(Lorg/apache/maven/cli/MavenCli$CliRequest;)I+19 j org.apache.maven.cli.MavenCli.doMain(Lorg/apache/maven/cli/MavenCli$CliRequest;)I+61 j org.apache.maven.cli.MavenCli.main([Ljava/lang/String;Lorg/codehaus/plexus/classworlds/ClassWorld;)I+18 v ~StubRoutines::call_stub j sun.reflect.NativeMethodAccessorImpl.invoke0(Ljava/lang/reflect/Method;Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+0 j sun.reflect.NativeMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+87 j sun.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+6 j java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+57 j org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced([Ljava/lang/String;)V+45 j org.codehaus.plexus.classworlds.launcher.Launcher.launch([Ljava/lang/String;)V+2 j org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode([Ljava/lang/String;)I+101 j org.codehaus.plexus.classworlds.launcher.Launcher.main([Ljava/lang/String;)V+1 v ~StubRoutines::call_stub
答案 0 :(得分:1)
根据堆栈跟踪,即使在涉及GWT编译器之前也会发生错误:当gwt-maven-plugin尝试识别模块是否需要重新编译时(或实际上是否应该编译它们:如果没有入口点,插件会跳过编译。
该算法可能存在缺陷(例如,它排除了名称以com.google.gwt.
开头的继承模块,但可能包含来自依赖项的模块 - 例如GIN-并且GWT中存在的模块不属于此层次结构中的模块 - 但是在com.google.web.bindery
- )并且可能是马车,但是在这种情况下我会说它在一个畸形的JAR或类似的东西上窒息。
也许尝试清理本地仓库(~/.m2/repository
)以重新下载依赖项?
或者,使用mvnDebug
命令运行Maven并为其附加调试器,在stacktrace中标识的方法中的某处设置断点,以尝试找出哪个JAR可能已损坏(至少哪一个)使JVM崩溃)