问Java7的"Solr/Lucene“bug有多严重？

EN

任何热点bug的问题是，你需要达到编译阈值(例如10000)才能得到它:所以如果你的单元测试是“微不足道的”，你可能不会捕捉到它。

例如，我们在lucene中发现了不正确的结果问题，因为这个特定的测试创建了20,000个文档索引。

在我们的测试中，我们随机化了不同的接口(例如，不同的目录实现)和索引参数等，测试只有1%的时间失败，当然，它可以用相同的随机种子重现。我们还对test创建的每个索引运行checkindex，这会进行一些健全性测试，以确保索引不会损坏。

对于我们发现的测试，如果你有一个特定的配置:例如RAMDirectory + PulsingCodec +为字段存储的有效载荷，那么在它达到编译阈值后，test上的枚举循环返回错误的计算，在这种情况下，一个术语的返回文档数量!=为该术语存储的docFreq。

我们有大量的压力测试，重要的是要注意到这个测试中的正常断言实际上是通过的，它是最后失败的checkindex部分。

最大的问题是，lucene的增量索引基本上是通过将多个段合并成一个段来工作的:因此，如果这些枚举计算无效数据，这些无效数据就会存储到新合并的索引中:也就是损坏。

我想说，这个bug比我们之前遇到的循环优化器热点bug(例如，sign-flip stuff，https://issues.apache.org/jira/browse/LUCENE-2975)更加隐蔽。在这种情况下，我们得到了奇怪的负文档增量，这使得它很容易被捕获。我们也只需要手动展开一个方法来躲避它。另一方面，我们最初唯一的“测试”是一个巨大的10 we的http://www.pangaea.de/索引，所以把范围缩小到这个bug是很痛苦的。

在这种情况下，我花了大量时间(例如，上周的每晚)尝试手动展开/内联各种内容，尝试创建一些解决方法，这样我们就可以避开bug，并且不会创建损坏的索引。我可以躲开一些案子，但还有更多的案子我不能...我相信如果我们能在我们的测试中触发这个东西，就会有更多的案例出现……

复制bug的简单方法。打开eclipse (我的例子是Indigo)，然后转到Help/Search。输入搜索字符串，您将注意到eclipse崩溃。请看一下日志。

# Problematic frame:
# J  org.apache.lucene.analysis.PorterStemmer.stem([CII)Z
#
# Failed to write core dump. Minidumps are not enabled by default on client versions of Windows
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.sun.com/bugreport/crash.jsp
#

---------------  T H R E A D  ---------------

Current thread (0x0000000007b79000):  JavaThread "Worker-46" [_thread_in_Java, id=264, stack(0x000000000f380000,0x000000000f480000)]

siginfo: ExceptionCode=0xc0000005, reading address 0x00000002f62bd80e

Registers:

截至2012年12月2日，该问题仍然存在于Oracle JDK Java -version java版本"1.7.0_09“java运行时环境(build 1.7.0_09-b05) java HotSpot(TM) 64位服务器VM (build 23.5-b02，混合模式)和OpenJDK java版本"1.7.0_09-icedtea”OpenJDK运行时环境(fedora-2.3.3.fc17.1-x86_64) openjdk 64位服务器VM (build 23.2-b09，混合模式)中。

奇怪的是，单独使用-XX:-UseLoopPredicate或-XX:LoopUnrollLimit=1选项中的任何一个都可以防止错误的发生，但是当它们一起使用时- JDK会失败参见例如https://bugzilla.redhat.com/show_bug.cgi?id=849279