[
https://issues.apache.org/jira/browse/DRILL-4884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15606084#comment-15606084
]
Dechang Gu commented on DRILL-4884:
-----------------------------------
When I run a similar query with limit 65536 on 1.9.0 master commit 4ee1d4c, all
the drillbits are crashed with SIGSEGV fatal error.
Here is what I did:
0: jdbc:drill:schema=dfs.tpchPar100> select l_orderkey, count(*) as cnt from
lineitem group by l_orderkey limit 6;
+-------------+------+
| l_orderkey | cnt |
+-------------+------+
| 103069602 | 4 |
| 103070305 | 1 |
| 103070470 | 1 |
| 103072326 | 2 |
| 103072898 | 7 |
| 103075718 | 5 |
+-------------+------+
6 rows selected (21.493 seconds)
0: jdbc:drill:schema=dfs.tpchPar100> select l_orderkey, count(*) as cnt from
lineitem group by l_orderkey limit 65536;
Error: CONNECTION ERROR: Connection /10.10.120.101:51025 <-->
ucs-node4.perf.lab/10.10.120.104:31010 (user client) closed unexpectedly.
Drillbit down?
[Error Id: d65fd84b-6336-4540-afe0-de0b9459dcfe ] (state=,code=0)
and in the drillbit.out:
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007f8a28735cc6, pid=3997, tid=140229356377856
#
# JRE version: OpenJDK Runtime Environment (7.0_65-b17) (build
1.7.0_65-mockbuild_2014_07_16_06_06-b00)
# Java VM: OpenJDK 64-Bit Server VM (24.65-b04 mixed mode linux-amd64
compressed oops)
# Problematic frame:
# J 3152% C2
org.apache.drill.exec.physical.impl.limit.LimitRecordBatch.limitWithNoSV(I)V
(111 bytes) @ 0x00007f8a28735cc6 [0x00007f8a28735c20+0xa6]
#
# Failed to write core dump. Core dumps have been disabled. To enable core
dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /tmp/jvm-3997/hs_error.log
[thread 140229298657024 also had an error]
[thread 140230122809088 also had an error]
[thread 140229306025728 also had an error]
[thread 140229336438528 also had an error]
#
# If you would like to submit a bug report, please include
# instructions on how to reproduce the bug and visit:
# http://icedtea.classpath.org/bugzilla
#
10:51:34,766 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Could
NOT find resource [logback.groovy]
10:51:34,766 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Could
NOT find resource [logback-test.xml]
10:51:34,767 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Found
resource [logback.xml] at [file:/mapr/drillPerf/drillbit/conf/logback.xml]
10:51:34,769 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource
[logback.xml] occurs multiple times on the classpath.
10:51:34,769 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource
[logback.xml] occurs at [file:/opt/mapr/drill/drill-1.9.0/conf/logback.xml]
10:51:34,769 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource
[logback.xml] occurs at [file:/mapr/drillPerf/drillbit/conf/logback.xml]
10:51:34,985 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction
- debug attribute not set
10:51:34,994 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - About
to instantiate appender of type
[ch.qos.logback.core.rolling.RollingFileAppender]
10:51:35,007 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - Naming
appender as [FILE]
10:51:35,074 |-INFO in
ch.qos.logback.core.rolling.FixedWindowRollingPolicy@7a674e9b - No compression
will be used
10:51:35,074 |-WARN in
ch.qos.logback.core.rolling.FixedWindowRollingPolicy@7a674e9b - Large window
sizes are not allowed.
10:51:35,074 |-WARN in
ch.qos.logback.core.rolling.FixedWindowRollingPolicy@7a674e9b - MaxIndex
reduced to 21
10:51:35,085 |-INFO in ch.qos.logback.core.joran.action.NestedComplexPropertyIA
- Assuming default type [ch.qos.logback.classic.encoder.PatternLayoutEncoder]
for [encoder] property
10:51:35,150 |-INFO in ch.qos.logback.core.rolling.RollingFileAppender[FILE] -
Active log file name: /var/log/drill/drillbit_ucs-node4.perf.lab.log
10:51:35,150 |-INFO in ch.qos.logback.core.rolling.RollingFileAppender[FILE] -
File property is set to [/var/log/drill/drillbit_ucs-node4.perf.lab.log]
10:51:35,153 |-INFO in ch.qos.logback.classic.joran.action.LoggerAction -
Setting additivity of logger [org.apache.drill] to false
10:51:35,153 |-INFO in ch.qos.logback.classic.joran.action.LevelAction -
org.apache.drill level set to INFO
10:51:35,153 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction -
Attaching appender named [FILE] to Logger[org.apache.drill]
10:51:35,154 |-INFO in ch.qos.logback.classic.joran.action.LevelAction - ROOT
level set to INFO
10:51:35,154 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction -
Attaching appender named [FILE] to Logger[ROOT]
10:51:35,154 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction
- End of configuration.
10:51:35,155 |-INFO in ch.qos.logback.classic.joran.JoranConfigurator@1459e0e5
- Registering current configuration as safe fallback point
Oct 25, 2016 10:51:42 AM org.glassfish.jersey.server.ApplicationHandler
initialize
INFO: Initiating Jersey application, version Jersey: 2.8 2014-04-29 01:25:26...
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further
details.
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007f02d07c1686, pid=6410, tid=139647908550400
#
# JRE version: OpenJDK Runtime Environment (7.0_65-b17) (build
1.7.0_65-mockbuild_2014_07_16_06_06-b00)
# Java VM: OpenJDK 64-Bit Server VM (24.65-b04 mixed mode linux-amd64
compressed oops)
# Problematic frame:
# J 3823% C2
org.apache.drill.exec.physical.impl.limit.LimitRecordBatch.limitWithNoSV(I)V
(111 bytes) @ 0x00007f02d07c1686 [0x00007f02d07c15e0+0xa6]
#
# Failed to write core dump. Core dumps have been disabled. To enable core
dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /tmp/jvm-6410/hs_error.log
[thread 139648545396480 also had an error]
[thread 139648551712512 also had an error]
> Drill produced IOB exception while querying data of 65536 limitation using
> non batched reader
> ---------------------------------------------------------------------------------------------
>
> Key: DRILL-4884
> URL: https://issues.apache.org/jira/browse/DRILL-4884
> Project: Apache Drill
> Issue Type: Bug
> Components: Query Planning & Optimization
> Affects Versions: 1.8.0
> Environment: CentOS 6.5 / JAVA 8
> Reporter: Hongze Zhang
> Assignee: Jinfeng Ni
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> Drill produces IOB while using a non batched scanner and limiting SQL by
> 65536.
> SQL:
> {noformat}
> select id from xx limit 1 offset 65535
> {noformat}
> Result:
> {noformat}
> at
> org.apache.drill.common.exceptions.UserException$Builder.build(UserException.java:534)
> ~[classes/:na]
> at
> org.apache.drill.exec.work.fragment.FragmentExecutor.sendFinalState(FragmentExecutor.java:324)
> [classes/:na]
> at
> org.apache.drill.exec.work.fragment.FragmentExecutor.cleanup(FragmentExecutor.java:184)
> [classes/:na]
> at
> org.apache.drill.exec.work.fragment.FragmentExecutor.run(FragmentExecutor.java:290)
> [classes/:na]
> at
> org.apache.drill.common.SelfCleaningRunnable.run(SelfCleaningRunnable.java:38)
> [classes/:na]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [na:1.8.0_101]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [na:1.8.0_101]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_101]
> Caused by: java.lang.IndexOutOfBoundsException: index: 131072, length: 2
> (expected: range(0, 131072))
> at io.netty.buffer.DrillBuf.checkIndexD(DrillBuf.java:175)
> ~[classes/:4.0.27.Final]
> at io.netty.buffer.DrillBuf.chk(DrillBuf.java:197)
> ~[classes/:4.0.27.Final]
> at io.netty.buffer.DrillBuf.setChar(DrillBuf.java:517)
> ~[classes/:4.0.27.Final]
> at
> org.apache.drill.exec.record.selection.SelectionVector2.setIndex(SelectionVector2.java:79)
> ~[classes/:na]
> at
> org.apache.drill.exec.physical.impl.limit.LimitRecordBatch.limitWithNoSV(LimitRecordBatch.java:167)
> ~[classes/:na]
> at
> org.apache.drill.exec.physical.impl.limit.LimitRecordBatch.doWork(LimitRecordBatch.java:145)
> ~[classes/:na]
> at
> org.apache.drill.exec.record.AbstractSingleRecordBatch.innerNext(AbstractSingleRecordBatch.java:93)
> ~[classes/:na]
> at
> org.apache.drill.exec.physical.impl.limit.LimitRecordBatch.innerNext(LimitRecordBatch.java:115)
> ~[classes/:na]
> at
> org.apache.drill.exec.record.AbstractRecordBatch.next(AbstractRecordBatch.java:162)
> ~[classes/:na]
> at
> org.apache.drill.exec.physical.impl.validate.IteratorValidatorBatchIterator.next(IteratorValidatorBatchIterator.java:215)
> ~[classes/:na]
> at
> org.apache.drill.exec.record.AbstractRecordBatch.next(AbstractRecordBatch.java:119)
> ~[classes/:na]
> at
> org.apache.drill.exec.record.AbstractRecordBatch.next(AbstractRecordBatch.java:109)
> ~[classes/:na]
> at
> org.apache.drill.exec.record.AbstractSingleRecordBatch.innerNext(AbstractSingleRecordBatch.java:51)
> ~[classes/:na]
> at
> org.apache.drill.exec.physical.impl.svremover.RemovingRecordBatch.innerNext(RemovingRecordBatch.java:94)
> ~[classes/:na]
> at
> org.apache.drill.exec.record.AbstractRecordBatch.next(AbstractRecordBatch.java:162)
> ~[classes/:na]
> at
> org.apache.drill.exec.physical.impl.validate.IteratorValidatorBatchIterator.next(IteratorValidatorBatchIterator.java:215)
> ~[classes/:na]
> at
> org.apache.drill.exec.record.AbstractRecordBatch.next(AbstractRecordBatch.java:119)
> ~[classes/:na]
> at
> org.apache.drill.exec.record.AbstractRecordBatch.next(AbstractRecordBatch.java:109)
> ~[classes/:na]
> at
> org.apache.drill.exec.record.AbstractSingleRecordBatch.innerNext(AbstractSingleRecordBatch.java:51)
> ~[classes/:na]
> at
> org.apache.drill.exec.physical.impl.project.ProjectRecordBatch.innerNext(ProjectRecordBatch.java:132)
> ~[classes/:na]
> at
> org.apache.drill.exec.record.AbstractRecordBatch.next(AbstractRecordBatch.java:162)
> ~[classes/:na]
> at
> org.apache.drill.exec.physical.impl.validate.IteratorValidatorBatchIterator.next(IteratorValidatorBatchIterator.java:215)
> ~[classes/:na]
> at
> org.apache.drill.exec.physical.impl.BaseRootExec.next(BaseRootExec.java:104)
> ~[classes/:na]
> at
> org.apache.drill.exec.physical.impl.ScreenCreator$ScreenRoot.innerNext(ScreenCreator.java:81)
> ~[classes/:na]
> at
> org.apache.drill.exec.physical.impl.BaseRootExec.next(BaseRootExec.java:94)
> ~[classes/:na]
> at
> org.apache.drill.exec.work.fragment.FragmentExecutor$1.run(FragmentExecutor.java:256)
> ~[classes/:na]
> at
> org.apache.drill.exec.work.fragment.FragmentExecutor$1.run(FragmentExecutor.java:250)
> ~[classes/:na]
> at java.security.AccessController.doPrivileged(Native Method)
> ~[na:1.8.0_101]
> at javax.security.auth.Subject.doAs(Subject.java:422) ~[na:1.8.0_101]
> at
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1657)
> ~[hadoop-common-2.7.1.jar:na]
> at
> org.apache.drill.exec.work.fragment.FragmentExecutor.run(FragmentExecutor.java:250)
> [classes/:na]
> ... 4 common frames omitted
> {noformat}
> Code from IteratorValidatorBatchIterator.java said that it is OK incoming
> returning 65536 records:
> {noformat}
> if (incoming.getRecordCount() > MAX_BATCH_SIZE) { // MAX_BATCH_SIZE == 65536
> throw new IllegalStateException(
> String.format(
> "Incoming batch [#%d, %s] has size %d, which is beyond the"
> + " limit of %d",
> instNum, batchTypeName, incoming.getRecordCount(),
> MAX_BATCH_SIZE
> ));
> }
> {noformat}
> Code from LimitRecordBatch.java shows that a loop will not break as expected
> when the incoming returns 65536 records:
> {noformat}
> private void limitWithNoSV(int recordCount) {
> final int offset = Math.max(0, Math.min(recordCount - 1, recordsToSkip));
> recordsToSkip -= offset;
> int fetch;
> if(noEndLimit) {
> fetch = recordCount;
> } else {
> fetch = Math.min(recordCount, offset + recordsLeft);
> recordsLeft -= Math.max(0, fetch - offset);
> }
> int svIndex = 0;
> for(char i = (char) offset; i < fetch; svIndex++, i++) { // since
> fetch==recordCount==65536, param i can be increased from 65535 to 65536, then
> be limited to 0 by the char type limitation, the loop abnormally continues.
> outgoingSv.setIndex(svIndex, i);
> }
> outgoingSv.setRecordCount(svIndex);
> }
> {noformat}
> The IllegalStateException should be thrown when incoming returns 65535
> records rather than 65536.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
