我已经在我的开发环境中运行的Glassfish 4的Java Glassfish的4个崩溃， “双自由或损坏（fasttop）”
Windows
java version "1.7.0_40"
Java(TM) SE Runtime Environment (build 1.7.0_40-b43)
Java HotSpot(TM) 64-Bit Server VM (build 24.0-b56, mixed mode)
一切完美的作品。
上周我部署一个Debian的Linux服务器上运行：
java version "1.7.0_25"
OpenJDK Runtime Environment (IcedTea 2.3.10) (7u25-2.3.10-1~deb7u1)
OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)
当在Linux环境下的应用程序崩溃间歇性运行。它已经运行好几天没有崩溃，然后在几个小时内崩溃了几次。当它崩溃时，glassfish或jvm日志文件中没有错误消息，这个过程就消失了，并且在一种情况下，jvm.log中包含一条被截断的行。到目前为止，我已经找到了唯一的线索是，系统日志和用户日志包含：
的grep的Java *
syslog:Jan 14 13:41:19 omega-rm java: *** glibc detected *** /usr/lib/jvm/java-7-openjdk-amd64/bin/java: double free or corruption (fasttop): 0x00007fb6ac076730 ***
syslog.1:Jan 13 19:48:04 omega-rm java: *** glibc detected *** /usr/lib/jvm/java-7-openjdk-amd64/bin/java: double free or corruption (fasttop): 0x00007fb037835c90 ***
user.log:Jan 13 19:48:04 omega-rm java: *** glibc detected *** /usr/lib/jvm/java-7-openjdk-amd64/bin/java: double free or corruption (fasttop): 0x00007fb037835c90 ***
user.log:Jan 14 13:41:19 omega-rm java: *** glibc detected *** /usr/lib/jvm/java-7-openjdk-amd64/bin/java: double free or corruption (fasttop): 0x00007fb6ac076730 ***
user.log.1:Jan 8 10:19:30 omega-rm java: *** glibc detected *** /usr/lib/jvm/java-7-openjdk-amd64/bin/java: double free or corruption (fasttop): 0x0000000007974a90 ***
user.log.1:Jan 8 14:29:11 omega-rm java: *** glibc detected *** /usr/lib/jvm/java-7-openjdk-amd64/bin/java: double free or corruption (fasttop): 0x00000000082431f0 ***
user.log.1:Jan 8 14:57:19 omega-rm java: *** glibc detected *** /usr/lib/jvm/java-7-openjdk-amd64/bin/java: double free or corruption (fasttop): 0x00007f805f87f490 ***
user.log.1:Jan 8 18:23:42 omega-rm java: *** glibc detected *** /usr/lib/jvm/java-7-openjdk-amd64/bin/java: double free or corruption (fasttop): 0x00007eff39829ca0 ***
所有的错误似乎比在结束地址相同等。所有的时间都与服务器崩溃的时间相对应，所以看起来这是服务器消失的原因。
有问题的应用程序是一个文档存储系统，它接受多种格式的文档并将它们存储在MongoDB中。在可能的情况下，它还会将图像呈现为JPG格式。
它使用Apache PDF Box和Java Advanced Imaging来渲染JPG。它运行Spring Framework，SpringData MongoDB和Spring Security。它偶尔使用jtds进行数据库访问，但这种情况并不常见，我相当确信在崩溃时没有数据库活动发生。最近发生了图像重新处理，但在大多数崩溃时都已成功完成（未针对所有崩溃进行验证，但对最近一次崩溃进行了详细验证，并且每个图像都已生成并保存为最近保存的文档）。最新文档上传后50秒发生崩溃。
几乎我在网上找到的所有讨论都发生在C或C++程序中，并且在那里会有意义。我可以想到它在Java程序中发生的唯一方法是通过JNI（我没有使用，也许我使用的一些库做JNI，但如果是这样，我不知道它）或者一个JVM错误。
有没有人有任何建议，试图缩小什么是造成这个问题？
是否有任何记录或诊断信息可打开以获取更多详细信息？
目前我唯一能想到的就是尝试运行一段时间的应用程序，并关闭某些功能（目前我最担心使用PDF Box的PDF渲染），并查看哪些功能组合稳定，而不是。如果可能的话，我宁愿有一个更明确的方法（并且不需要等待几天，看看测试是否奏效！）。
只有一个建议和猜测，但对我来说，它看起来好像是JVM导致了问题。我也注意到你正在使用openjdk。我一直用甲骨文的'官方'二进制代码取代开放Java，这对Ubunto来说并不是特别困难（因为Debian也可能很容易）。我相信Open Java与Java标准并不完全兼容，但不要在此引用我的意思。您可以安装Oracle Java吗？ – Kerry
谢谢，我自己也好奇。从理论上讲，我可以完全访问机器，因此我可以安装任何版本的Java。在实践中，我发现它是一个完整的噩梦，甚至得到我已经安装的一个。我也做了一些Google搜索，尽管我没有发现任何明确的东西，但它看起来像OpenJDK使用Oracle使用的相同的HotSpot JVM。 –
Tim，这是一个非常不错的Ubuntu指南：https://help.ubuntu.com/community/Java使用'update-alternatives'，这是我总是这样做的方式。我认为'update-alternatives'无论如何都来自Debian基地，所以它应该可以提供给你。 – Kerry