有人知道在GWT -maven-plugin开始和"Compiling module"语句之间可能导致GWT编译失败的原因吗?
我们正常运行带有信息的GWT，所以我在日志中看到的是插件启动，随后是SIGSEGV。当我在本地运行调试时，没有看到问题，我可以看到，当GWT插件执行这些步骤之一时，违规被抛出:
- 加载继承模块
- 审查"在…中找到的公共资源"(对于在类路径中找到的.pom文件，我看到了两个警告)
- 持久单元缓存目录集
- 查找先前缓存的编译单元。
我从一个干净的目录开始，所以我和我的缓存是在目标下，所以我不认为它是在最后两个。由于错误与zip库条目相关，我怀疑类路径和解析可能是问题所在。
env
jdk 1.7.0 u55 + GWT 2.5.1 + GWT -maven-plugin 2.5.1-rc1
请让我知道，如果你有任何想法，我正在增加日志级别，改变内存，希望有一个可重复的情况。由于
选项>- 增加GWT内存和限制工作线程(完成:1线程，4g堆，没有变化)
- 升级插件到2.5.1或2.6.1
- 升级jdk到u67
- 升级gwt到2.6.1
除了
[INFO]——gwt-maven-plugin:2.5.1-rc1:compile(默认)@ mymodule——＃Java运行时环境检测到致命错误:＃# SIGSEGV (0xb) at pc=0x00000036a3089aab, pid=14610, tid=140310347593472＃Java(TM) SE Runtime Environment (7.0_55-b13) (build 1.7.0_55-b13)# Java VM: Java HotSpot(TM) 64位Server VM (24.55-b03混合模式linux-amd64压缩oops)#问题框架:# C [libc.so]。6 + 0 x89aab] memcpy x15b + 0……堆栈:[0x00007f9c8c5d3000,0x00007f9c8c6d4000]， sp=0x00007f9c8c6d0c68，可用空间=1015k本机帧:(J=编译Java代码，J=解释Java代码，Vv=VM代码，C=本机代码)C [libc.so。6 + 0 x89aab] memcpy x15b + 0C [libzip。所以xd0 + 0 x50b0] ZIP_GetEntry + 0C [libzip。所以xad + 0 x3eed] Java_java_util_zip_ZipFile_getEntry + 0J java.util.zip.ZipFile.getEntry (J (BZ) JJava框架:(J=编译Java代码，J=解释Java代码，Vv=虚拟机代码)J java.util.zip.ZipFile.getEntry (J (BZ) JJ 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; + 2j sun.net.www.protocol.jar.JarURLConnection.connect V + 62 ()j sun.net.www.protocol.jar.JarURLConnection.getInputStream () Ljava/io/InputStream; + 1j java.net.URLClassLoader.getResourceAsStream (Ljava/lang/String;) Ljava/io/InputStream; + 18J org.codehaus.mojo.gwt.AbstractGwtModuleMojo.readModule (Ljava/lang/String;) Lorg codehaus/魔力/gwt/GwtModule;j org.codehaus.mojo.gwt.GwtModule.getLocalInherits () Ljava/util/组;+ 74j org.codehaus.mojo.gwt.GwtModule.addInheritedModules (Ljava/util/组;Ljava/util/组;)V + 42j org.codehaus.mojo.gwt.GwtModule.getInherits () Ljava/util/组;+ 32j org.codehaus.mojo.gwt.GwtModule.getEntryPoints () Ljava/util/列表;+ 20j org.codehaus.mojo.gwt.shell.CompileMojo.compilationRequired (Ljava/lang/String; Ljava/io/文件;)Z + 35j org.codehaus.mojo.gwt.shell.CompileMojo.compile ((Ljava/lang/String;)V + 432j org.codehaus.mojo.gwt.shell.CompileMojo.doExecute () V + 57j org.codehaus.mojo.gwt.shell.AbstractGwtShellMojo.execute () V + 1j org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (Lorg/apache maven/执行/MavenSession; Lorg/apache maven/插件/MojoExecution;)V + 166j org.apache.maven.lifecycle.internal.MojoExecutor.execute (Lorg/apache maven/执行/MavenSession; Lorg/apache maven/插件/MojoExecution; Lorg/apache maven生命周期/内部/ProjectIndex; Lorg/apache maven生命周期//DependencyContext;内部)V + 215j org.apache.maven.lifecycle.internal.MojoExecutor.execute (Lorg/apache maven/执行/MavenSession; Lorg/apache maven/插件/MojoExecution; Lorg/apache maven生命周期/内部/ProjectIndex; Lorg/apache maven生命周期/内部/DependencyContext; Lorg/apache maven生命周期//PhaseRecorder;内部)V + 6j org.apache.maven.lifecycle.internal.MojoExecutor.execute (Lorg/apache maven/执行/MavenSession; Ljava/util/列表;Lorg apache maven/生命周期/内部/ProjectIndex;)V + 60j org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (Lorg/apache maven/执行/MavenSession; Lorg/apache maven/执行/MavenSession; Lorg/apache maven生命周期/内部/ReactorContext; Lorg/apache maven/项目/MavenProject; Lorg/apache maven生命周期//TaskSegment;内部)V + 151j org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (Lorg/apache maven/执行/MavenSession; Lorg/apache maven生命周期/内部/ReactorContext; Lorg/apache maven/项目/MavenProject; Lorg/apache maven生命周期//TaskSegment;内部)V + 7j org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (Lorg/apache maven/执行/MavenSession; Lorg/apache maven生命周期/内部/ReactorContext; Lorg/apache maven生命周期/内部/ProjectBuildList; Ljava/util/列表;Lorg apache maven/生命周期/内部/ReactorBuildStatus;)V + 77j org.apache.maven.lifecycle.internal.LifecycleStarter.execute (Lorg/apache maven/执行/MavenSession;)V + 336j org.apache.maven.DefaultMaven.doExecute (Lorg/apache maven/执行/MavenExecutionRequest;) Lorg/apache maven/执行/MavenExecutionResult; + 557j org.apache.maven.DefaultMaven.execute (Lorg/apache maven/执行/MavenExecutionRequest;) Lorg/apache maven/执行/MavenExecutionResult; + 11j org.apache.maven.cli.MavenCli.execute (Lorg/apache maven/cli/MavenCli CliRequest;美元)我+ 19j org.apache.maven.cli.MavenCli.doMain (Lorg/apache maven/cli/MavenCli CliRequest;美元)我+ 61j org.apache.maven.cli.MavenCli.main ((Ljava/lang/String; Lorg codehaus/丛/classworlds/ClassWorld;)我+ 18v ~ StubRoutines:: call_stubj sun.reflect.NativeMethodAccessorImpl.invoke0 (Ljava/lang/反映/方法;Ljava/lang/对象;(Ljava/lang/对象;)Ljava/lang/对象;+ 0j sun.reflect.NativeMethodAccessorImpl.invoke (Ljava/lang/对象;(Ljava/lang/对象;)Ljava/lang/对象;+ 87j sun.reflect.DelegatingMethodAccessorImpl.invoke (Ljava/lang/对象;(Ljava/lang/对象;)Ljava/lang/对象;+ 6j java.lang.reflect.Method.invoke (Ljava/lang/对象;(Ljava/lang/对象;)Ljava/lang/对象;+ 57j org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced ((Ljava/lang/String;)V + 45j org.codehaus.plexus.classworlds.launcher.Launcher.launch ((Ljava/lang/String;)V + 2j org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode ((Ljava/lang/String;)我+ 101j org.codehaus.plexus.classworlds.launcher.Launcher.main ((Ljava/lang/String;)V + 1v ~ StubRoutines: call_stub
根据stacktrace，这个错误甚至在GWT编译器参与之前就发生了:当GWT -maven-plugin试图识别模块是否需要重新编译时(或者实际上它们是否应该被编译:如果没有入口点，插件会跳过编译)。
该算法可能存在缺陷(例如，它排除了名称以com.google.gwt.开头的继承模块，但可能包括来自依赖项的模块)。GIN -在GWT中有一些模块不在这个层次结构中，但在com.google.web.bindery中-)并且可能有bug，但我想说在这种情况下，它会阻塞在一个畸形的JAR或类似的东西上。
也许尝试清理您的本地repo (~/.m2/repository)重新下载依赖关系?
或者，使用mvnDebug命令运行Maven并为其附加一个调试器，在堆栈跟踪中确定的方法中设置一个断点，以尝试找出哪个JAR可能损坏(至少哪个使JVM崩溃)