java - GWT 编译导致 SIGSEGV

标签 java maven gwt segmentation-fault gwt-maven-plugin

有谁知道什么可能导致 gwt-maven-plugin start 和“编译模块”语句之间的 GWT 编译失败?

我们正常运行带有信息的 GWT,所以我在日志中看到的只是插件启动,随后不久就是 SIGSEGV。当我在本地运行调试并且没有看到问题时,我可以看到在 GWT 插件执行以下步骤之一时引发了违规:

  • 加载继承的模块
  • 评论“在...中找到的公共(public)资源”(我看到在类路径中找到的 .pom 文件有两条警告)
  • 在...中找到可翻译的源代码
  • 持久单元缓存目录集
  • 查找之前缓存的编译单元。

我从一个干净的目录开始,所以我和我的缓存位于目标之下,所以我认为它不在最后两个目录中。由于该错误与 zip lib 条目相关,因此我怀疑类路径和解析可能是问题所在。

环境

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

最佳答案

根据堆栈跟踪,该错误甚至在涉及 GWT 编译器之前就发生:当 gwt-maven-plugin 尝试确定模块是否需要重新编译时(或者实际上是否应该编译它们:如果没有入口点,插件会跳过编译)。

该算法可能存在缺陷(例如,它排除了名称以 com.google.gwt. 开头的继承模块,但可能包含来自依赖项的模块(例如 GIN),并且 GWT 中的某些模块不在该层次结构中,而是在 com.google.web.bindery 中),并且可能存在错误,但我想说在这种情况下,它会因格式错误的 JAR 或类似内容而卡住。

也许尝试清理本地存储库 (~/.m2/repository) 以重新下载依赖项?

或者,使用 mvnDebug 命令运行 Maven 并附加一个调试器,在堆栈跟踪中标识的方法中的某处设置断点,以尝试找出哪个 JAR 可能已损坏(至少是哪个 JAR 导致 JVM 崩溃)

关于java - GWT 编译导致 SIGSEGV,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/25554968/

相关文章:

Spring Boot 应用程序中的 javax.servlet

spring - HTTP 状态 500 - servlet 调度程序的 Servlet.init() 抛出异常

gwt - 如何在 GWT 中的单元格表上创建无限滚动?

java - 使用DTO绑定(bind)多个动态创建字段的相同属性名

java - Weblogic 8.1 到 Websphere 8.5 迁移

java - Java 中是否已经存在 i18n 时间单位列表?

xml - 如何通过 Maven 将 zip 文件部署到 Nexus 存储库

java - 避免图像的透明像素

eclipse - 在 Eclipse 应用程序运行时排除 Maven 依赖

java - 我的数据库不支持创建的查询