Tag: sigsegv

JVM在Lucene DataInput.readVInt上崩溃

在使用Lucene索引文档时，我的JVM（1.6.0_29）在密集使用时不断崩溃。 我明白了： # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00002b6b196d767c, pid=26417, tid=1183217984 # # JRE version: 6.0_29-b11 # Java VM: Java HotSpot(TM) 64-Bit Server VM (20.4-b02 mixed mode linux-amd64 compressed oops) # Problematic frame: # J org.apache.lucene.store.DataInput.readVInt()I # # If you would like to […]

使用SWIG创建Java共享库时出现SIGSEGV错误

所以，我正在尝试使用SWIG将C库（libnfc）移植到Java。 我已经到了编译共享库的地步，并且基本的“nfc_version（）”方法调用将起作用。 但是，调用“nfc_init（）”进行设置会导致SIGSEGV错误。 直接调用nfc库很好。 我用来生成共享库的命令： swig -java -I../libnfc/include nfclib.i gcc -c -I/usr/lib/jvm/java-7-openjdk-i386/include/ -I/usr/lib/jvm/java-7-openjdk-i386/include/linux nfclib_wrap.c gcc -shared nfclib_wrap.o ../build/libnfc/libnfc.so libnfc_wrap.so libnfc.i文件： %module nfc %{ #include #include #include %} %include %include %include 即它应该包括libnfc提供的所有方法。 这是我得到的错误日志： http ： //openetherpad.org/AyVDsO4XTg 显然，可能无法从我提供的信息中获得特定的解决方案。 但任何有关尝试的事情的建议都会非常感激（我的知识就在这里）。

Java致命错误SIGSEGV

我从Java编译器收到一条我不明白的错误消息。 我已经在OSX 10.6,10.9和Ubuntu 14.04上使用Java 6和7测试了我的代码。当我使用Eclipse调试器或解释器（使用-Xint选项）运行时，一切运行正常。 否则，我收到以下消息： Java 1.6： Invalid memory access of location 0x8 rip=0x1024e9660 Java 1.7： # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x000000010f7a8262, pid=20344, tid=18179 # # JRE version: Java(TM) SE Runtime Environment (7.0_60-b19) (build 1.7.0_60-b19) # Java VM: Java HotSpot(TM) 64-Bit […]

strace’ing java进程时有很多SIGSEGV

当我调试CI服务器上的一个unit testing（实际上是maven构建）时发生了有趣的事情。 我使用strace -ff -e trace=network -p [pid]连接到java进程以跟踪构建过程的网络活动。 这就是我所看到的： Process 26324 attached Process 26325 attached (waiting for parent) Process 26325 resumed (parent 26312 ready) Process 26325 detached Process 26324 detached Process 26320 detached Process 26317 detached Process 26308 resumed [pid 26308] — SIGCHLD (Child exited) @ 0 (0) — Process 26307 resumed Process 26308 detached […]

Java VM：1.6.0_17和1.6.0_18都可以重现SIGSEGV，如何报告？

编辑 ：这个可重现的SIGSEGV发生在具有多个proc和超过2GB内存的Linux机器上，因此Java默认为-server模式。 有趣的是，如果我强迫“-client”再也没有崩溃……（我仍然不太确定如何处理我可重复的SIGSEGV，但它仍然很有趣）。 首先请注意，这与以下内容有点相关但不同，因为在我们的情况下，它只发生了一个SIGSEGV，我们可以可靠地触发它： JVM OutOfMemory错误“死亡螺旋”（不是内存泄漏） 它是相关的，因为它发生在我们为应用程序提供“大量数据”时：数据来自文本文件然后数字嘎吱嘎吱（是的，Java中的财务数字运算）。 我只能使用有效的Java代码可靠地触发JVM到SIGSEGV。 注意 ：我总是会崩溃JVM 1.6.0_17和JVM 1.6.0_18这个问题并不是关于如何解决这个问题（例如，使用VM参数可以解决问题，但我不是在那之后，我想知道如何处理这种始终可重复的SIGSEGV）。 我有一个解决方法，只是在启动我们的应用程序时使用Java 1.5（同时仍然使用Java 1.6在同一台机器上运行IntelliJ IDEA等），但我的问题是，是否应该报告这个和如果它应该，如何报告它知道日志本身包含专有信息（完整的hs_err _…_日志）。 可以排除硬件错误： 这种情况发生在经常达到几个月正常运行时间的工作站上（我只在重要的安全补丁影响我已经发布的严格和强化的Debian Linux时重新启动它，这实际上并不经常发生）以及哪些应用程序永远不会崩溃（使它非常不太可能是那台机器上的硬件问题[更多下面]） 相同的应用程序在相同负载下的JVM 1.5下在同一台机器上完美运行（这就是我测试应用程序的方式：我只需在1.5 VM下启动它） 相同的应用程序在相同（巨大）负载下的超过一百台客户端机器上运行完美（在Windows + JVM 1.5或1.6上从未崩溃一次，并且从未在OS X + JVM 1.5或1.6上崩溃一次[崩溃意味着即时电话来自客户的电话]） 同一台机器上的其他应用程序和相同的1.6.0_17或1.6.0_18 JVM永远不会崩溃（例如，我有两个IntelliJ IDEA实例作为同一台机器上的两个不同用户运行而且它们不会崩溃） 机器用memtest“定期”测试（在安装新的操作系统之前，最后一次发生在安装Debian Lenny时，不久前） 这是可重复的按需SIGSEGV： … $uname -a Linux saturn 2.6.26-2-686 #1 SMP Wed Nov 4 20:45:37 UTC 2009 i686 GNU/Linux … $ […]