runtime error: index out of range [320] with length 320

[bajinsheng]

Bug Report

1. Minimal reproduce step (Required)

CREATE TABLE t0(c0 NUMERIC);
CREATE TABLE t1(c0 NUMERIC);
INSERT INTO t0 VALUES (0), (NULL), (1), (2);
INSERT INTO t1(c0) VALUES (NULL), (3), (4), (5);
CREATE VIEW v0(c0) AS SELECT t0.c0 FROM t0;

SELECT t0.c0 FROM v0, t0 LEFT JOIN t1 ON t0.c0 WHERE ((INET_ATON('5V')) IS NULL); -- runtime error: index out of range [320] with length 320

2. What did you expect to see? (Required)

No error

3. What did you see instead (Required)

Error

4. What is your TiDB version? (Required)

| Release Version: v7.6.0-alpha-347-g598ccada40-dirty
Edition: Community
Git Commit Hash: 598ccada4065e4871bc5bce53a039cbb598a6d82
Git Branch: master
UTC Build Time: 2023-12-01 01:44:42
GoVersion: go1.21.0
Race Enabled: false
Check Table Before Drop: false
Store: unistore |

[XuHuaiyu]

391777 [2023/12/04 15:36:18.269 +08:00] [ERROR] [conn.go:981] ["connection running loop panic"] [conn=2950692866] [session_alias=] [lastSQL="SELECT t0.c0 FROM v0, t0 LEFT JOIN t1 ON t0.c0 WHERE ((INET_ATON('5V')) IS NULL)"] [err="runtime error: index out of range [280] with length 256"] 
[stack="github.com/pingcap/tidb/pkg/server.(*clientConn).Run.func1
	/home/jenkins/agent/workspace/build-common/go/src/github.com/pingcap/tidb/pkg/server/conn.go:984
runtime.gopanic
	/usr/local/go/src/runtime/panic.go:914
github.com/pingcap/tidb/pkg/server.(*clientConn).writeResultSet.func1
	/home/jenkins/agent/workspace/build-common/go/src/github.com/pingcap/tidb/pkg/server/conn.go:2168
runtime.gopanic
	/usr/local/go/src/runtime/panic.go:914
runtime.goPanicIndex
	/usr/local/go/src/runtime/panic.go:114
github.com/pingcap/tidb/pkg/util/chunk.(*Column).GetDecimal
	/home/jenkins/agent/workspace/build-common/go/src/github.com/pingcap/tidb/pkg/util/chunk/column.go:583
github.com/pingcap/tidb/pkg/util/chunk.Row.GetMyDecimal
	/home/jenkins/agent/workspace/build-common/go/src/github.com/pingcap/tidb/pkg/util/chunk/row.go:106
github.com/pingcap/tidb/pkg/server/internal/column.DumpTextRow
	/home/jenkins/agent/workspace/build-common/go/src/github.com/pingcap/tidb/pkg/server/internal/column/column.go:165
github.com/pingcap/tidb/pkg/server.(*clientConn).writeChunks
	/home/jenkins/agent/workspace/build-common/go/src/github.com/pingcap/tidb/pkg/server/conn.go:2284
github.com/pingcap/tidb/pkg/server.(*clientConn).writeResultSet
	/home/jenkins/agent/workspace/build-common/go/src/github.com/pingcap/tidb/pkg/server/conn.go:2187
github.com/pingcap/tidb/pkg/server.(*clientConn).handleStmt
	/home/jenkins/agent/workspace/build-common/go/src/github.com/pingcap/tidb/pkg/server/conn.go:2055
github.com/pingcap/tidb/pkg/server.(*clientConn).handleQuery
	/home/jenkins/agent/workspace/build-common/go/src/github.com/pingcap/tidb/pkg/server/conn.go:1816
github.com/pingcap/tidb/pkg/server.(*clientConn).dispatch
	/home/jenkins/agent/workspace/build-common/go/src/github.com/pingcap/tidb/pkg/server/conn.go:1303
github.com/pingcap/tidb/pkg/server.(*clientConn).Run
	/home/jenkins/agent/workspace/build-common/go/src/github.com/pingcap/tidb/pkg/server/conn.go:1082
github.com/pingcap/tidb/pkg/server.(*Server).onConn
	/home/jenkins/agent/workspace/build-common/go/src/github.com/pingcap/tidb/pkg/server/server.go:701"]

[XuHuaiyu]

tidb:4000 [test]> desc SELECT t0.c0 FROM v0, t0 LEFT JOIN t1 ON t0.c0 WHERE ((INET_ATON('5V')) IS NULL);
+--------------------------------+---------+-----------+---------------+---------------------------------------------------+
| id                             | estRows | task      | access object | operator info                                     |
+--------------------------------+---------+-----------+---------------+---------------------------------------------------+
| HashJoin_14                    | 32.77   | root      |               | CARTESIAN inner join                              |
| ├─Selection_15(Build)          | 3.20    | root      |               | isnull(inet_aton("5V"))                           |
| │ └─TableReader_18             | 4.00    | root      |               | data:TableFullScan_17                             |
| │   └─TableFullScan_17         | 4.00    | cop[tikv] | table:t0      | keep order:false, stats:pseudo                    |
| └─HashJoin_19(Probe)           | 10.24   | root      |               | CARTESIAN left outer join, left cond:[test.t0.c0] |
|   ├─Selection_26(Build)        | 3.20    | root      |               | isnull(inet_aton("5V"))                           |
|   │ └─TableReader_25           | 4.00    | root      |               | data:TableFullScan_24                             |
|   │   └─TableFullScan_24       | 4.00    | cop[tikv] | table:t1      | keep order:false, stats:pseudo                    |
|   └─Selection_23(Probe)        | 3.20    | root      |               | isnull(inet_aton("5V"))                           |
|     └─TableReader_22           | 4.00    | root      |               | data:TableFullScan_21                             |
|       └─TableFullScan_21       | 4.00    | cop[tikv] | table:t0      | keep order:false, stats:pseudo                    |
+--------------------------------+---------+-----------+---------------+---------------------------------------------------+
11 rows in set, 2 warnings (0.00 sec)

[guo-shaoge]

The above image is the schema of TableReader_18 (build side of HashJoin_14), we can see its output type is TypeLongLong.

And HashJoin_14 use its build side as its output chunk. So the real output type of HashJoin_14 is TypeLongLong. (I give detailed analysis in above image).

But the schema of HashJoin_14 is MyDeciaml. So when return results to clients, TiDB tries to decode chunk of TypeLongLong as TypeMyDecimal.

So in short, the output type of TableReader_14 is wrong, which cause this panic. (I think the selection push down make things wrong, because before selection push down, the output type is still decimal. It changes to LongLong after logical optimization)

[winoros]

Before the second round of column pruning, the plan is something like Selection->Join->{Proj(1)->Scan, Child_1}.
After the second round of the column pruning, the plan becomes Join->{Selection->Proj()->Scan, Child_1}.
An empty project occurs, and the column mapping is wrong when generating physical plans.