[
https://issues.apache.org/jira/browse/LUCENE-6943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15070960#comment-15070960
]
Uwe Schindler edited comment on LUCENE-6943 at 12/24/15 12:47 PM:
------------------------------------------------------------------
bq. we were earlier using MMapDirectory but we switched to NIOFS if you check
the latest log file here:
https://issues.apache.org/jira/secure/attachment/12779429/hs_err_pid9254.log
Sorry, this is definitely using MMapDirectory, because this one uses
ByteBufferIndexInput as implementation class!
{noformat}
Stack: [0x00007fc83191e000,0x00007fc831a1f000], sp=0x00007fc831a195c0, free
space=1005k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
J 1583 C2 org.apache.lucene.store.ByteBufferIndexInput.readByte()B (126 bytes)
@ 0x00007fe487f50c0c [0x00007fe487f50bc0+0x4c]
{noformat}
Please check your solrconfig.xml!
In addition: MMapDirectory tries its best to prevent SIGSEGV by early throwing
AlreadyClosedException. Can you check the log files if you see any occurence of
stuff like AlreadyClosedException or other IOExceptions? If you see those, the
SIGSEGV was prevented by the tracking code, but under high load with high
concurrency this cannot be safely tracked, as we would otherwise significantly
slowdown searches. So it may throw AlreadyClosed/IOExceptions or crash. But
both tell you that there is a programming error (because something closes
IndexReaders while searches are running).
Switching to NIOFSDirectory would just prevent hard crushes by slowing down
searches, but the error in your / Solr's code is still there. So please look
for IO/AlreadyClosed exceptions in the logs (with MMap or NIO doesnt matter).
was (Author: thetaphi):
bq. we were earlier using MMapDirectory but we switched to NIOFS if you check
the latest log file here:
https://issues.apache.org/jira/secure/attachment/12779429/hs_err_pid9254.log
Sorry, this is definitely using MMapDirectory, because this one uses
ByteBufferIndexInput as implementation class!
{noformat}
Stack: [0x00007fc83191e000,0x00007fc831a1f000], sp=0x00007fc831a195c0, free
space=1005k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
J 1583 C2 org.apache.lucene.store.ByteBufferIndexInput.readByte()B (126 bytes)
@ 0x00007fe487f50c0c [0x00007fe487f50bc0+0x4c]
{noformat}
Please check your solrconfig.xml!
In addition: MMapDirectory tries its best to prevent SIGSEGV by early throwing
AlreadyClosedException. Can you check the log files if you see any occurence of
stuff like AlreadyClosedException or other IOExceptions? If you see those, the
SIGSEGV was prevented by the tracking code, but under high load with high
concurrency this cannot be safely tracked, as we would otherwise significantly
slowdown searches. So it may throw AlreadyClosed/IOExceptions or crash. But
both tell you that there is a programming error (because something closes
IndexReaders while searches are running).
> Jvm Crashes occassionaly with Lucene 4.6.1
> ------------------------------------------
>
> Key: LUCENE-6943
> URL: https://issues.apache.org/jira/browse/LUCENE-6943
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/query/scoring
> Affects Versions: 4.6.1
> Reporter: amit bhengra
> Attachments: hs_err_pid9254.log, hs_err_pid9889.log
>
>
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # SIGSEGV (0xb) at pc=0x00007f5625212cd7, pid=9889, tid=139920130201344
> #
> # JRE version: Java(TM) SE Runtime Environment (7.0_60-b19) (build
> 1.7.0_60-b19)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.60-b09 mixed mode
> linux-amd64 )
> # Problematic frame:
> # J 11490 C2 org.apache.lucene.store.ByteBufferIndexInput.readByte()B (126
> bytes) @ 0x00007f5625212cd7 [0x00007f5625212c80+0x57]
> #
> # Failed to write core dump. Core dumps have been disabled. To enable core
> dumping, try "ulimit -c unlimited" before starting Java again
> #
> # If you would like to submit a bug report, please visit:
> # http://bugreport.sun.com/bugreport/crash.jsp
> #
> Register to memory mapping:
> RAX=0x00007f55de053510 is an oop
> {instance class}
> - klass: {other class}
> RBX=0x00007f549dffc028 is an oop
> org.apache.lucene.codecs.lucene41.Lucene41PostingsReader
> - klass: 'org/apache/lucene/codecs/lucene41/Lucene41PostingsReader'
> RCX=0x0000000000000004 is an unknown value
> RDX=0x0000000000000080 is an unknown value
> RSP=0x00007f41b1a7f640 is pointing into the stack for thread:
> 0x00007f48f81a4000
> RBP=0x00007f4b1bff3630 is an oop
> java.nio.DirectByteBufferR
> - klass: 'java/nio/DirectByteBufferR'
> RSI=0x00007f4b1bff35a8 is an oop
> org.apache.lucene.store.MMapDirectory$MMapIndexInput
> - klass: 'org/apache/lucene/store/MMapDirectory$MMapIndexInput'
> RDI=0x00000000237c532a is an unknown value
> R8 =0x00000000237c4da3 is an unknown value
> R9 =0x00007f4b1bff35a8 is an oop
> org.apache.lucene.store.MMapDirectory$MMapIndexInput
> - klass: 'org/apache/lucene/store/MMapDirectory$MMapIndexInput'
> R10=0x00007f3a8f98a000 is an unknown value
> R11=0x00000000237c4da3 is an unknown value
> R12=0x00007f41b1a81f30 is pointing into the stack for thread:
> 0x00007f48f81a4000
> R13=0x0000000000000093 is an unknown value
> R14=0x000000000000431f is an unknown value
> R15=0x00007f48f81a4000 is a thread
> Stack: [0x00007f41b1985000,0x00007f41b1a86000], sp=0x00007f41b1a7f640, free
> space=1001k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
> code)
> J 11490 C2 org.apache.lucene.store.ByteBufferIndexInput.readByte()B (126
> bytes) @ 0x00007f5625212cd7 [0x00007f5625212c80+0x57]
> J 4940 C2
> org.apache.lucene.codecs.lucene41.Lucene41PostingsReader$BlockDocsAndPositionsEnum.nextPosition()I
> (118 bytes) @ 0x00007f5624515cb4 [0x00007f5624515980+0x334]
> J 10578 C2 org.apache.lucene.search.ExactPhraseScorer.phraseFreq()I (624
> bytes) @ 0x00007f56256de588 [0x00007f56256de4e0+0xa8]
> J 10629 C2 org.apache.lucene.search.ExactPhraseScorer.advance(I)I (152 bytes)
> @ 0x00007f5625729d84 [0x00007f5625729ba0+0x1e4]
> J 10433 C2 org.apache.lucene.search.MinShouldMatchSumScorer.advance(I)I (113
> bytes) @ 0x00007f5625653c34 [0x00007f5625653ae0+0x154]
> J 5630 C2 org.apache.lucene.search.BooleanScorer2.advance(I)I (14 bytes) @
> 0x00007f5624642a10 [0x00007f5624642820+0x1f0]
> J 5826 C2 org.apache.lucene.search.DisjunctionScorer.advance(I)I (87 bytes) @
> 0x00007f56246f140c [0x00007f56246f13c0+0x4c]
> J 8801 C2
> org.apache.lucene.search.join.FkToChildBlockJoinQuery$FkToChildBlockJoinScorer.advance(I)I
> (284 bytes) @ 0x00007f56251274c0 [0x00007f5625127440+0x80]
> J 5630 C2 org.apache.lucene.search.BooleanScorer2.advance(I)I (14 bytes) @
> 0x00007f56246429fc [0x00007f5624642820+0x1dc]
> J 4797 C2
> org.apache.lucene.search.FilteredQuery$LeapFrogScorer.score(Lorg/apache/lucene/search/Collector;)V
> (91 bytes) @ 0x00007f56244e9ccc [0x00007f56244e9c40+0x8c]
> J 4613 C2
> org.apache.lucene.search.IndexSearcher.search(Ljava/util/List;Lorg/apache/lucene/search/Weight;Lorg/apache/lucene/search/Collector;)V
> (93 bytes) @ 0x00007f562446cbec [0x00007f562446ca80+0x16c]
> J 6159 C2
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(Lorg/apache/solr/search/SolrIndexSearcher$QueryResult;Lorg/apache/solr/search/SolrIndexSearcher$QueryCommand;)V
> (708 bytes) @ 0x00007f562486cc30 [0x00007f562486c9a0+0x290]
> J 11811 C2
> org.apache.solr.search.SolrIndexSearcher.getDocListC(Lorg/apache/solr/search/SolrIndexSearcher$QueryResult;Lorg/apache/solr/search/SolrIndexSearcher$QueryCommand;)V
> (696 bytes) @ 0x00007f5625c957c0 [0x00007f5625c955c0+0x200]
> J 9702 C2
> org.apache.solr.search.SolrIndexSearcher.search(Lorg/apache/solr/search/SolrIndexSearcher$QueryResult;Lorg/apache/solr/search/SolrIndexSearcher$QueryCommand;)Lorg/apache/solr/search/SolrIndexSearcher$QueryResult;
> (8 bytes) @ 0x00007f5625461404 [0x00007f56254613e0+0x24]
> j
> org.apache.solr.handler.component.QueryComponent.process(Lorg/apache/solr/handler/component/ResponseBuilder;)V+1537
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
