Обсуждение: BUG #17067: FailedAssertion at castNodeImpl

The following bug has been logged on the website:

Bug reference:      17067
Logged by:          yaoguang chen
Email address:      cyg0810@gmail.com
PostgreSQL version: 14beta1
Operating system:   Linux supersix 5.4.0-39-generic #43-Ubuntu SMP Fri
Description:

run the following sql command through client and the PostgreSQL database
process will crash:

CREATE TABLE v0 ( v1 FLOAT NOT NULL PRIMARY KEY ) ;
WITH v1 AS ( DELETE FROM v0 WHERE v1 <= - - - 9 RETURNING * ) INSERT INTO v0
VALUES ( - - - - - - 95 ) ;
SELECT v1 FROM ( SELECT * FROM v0 UNION ALL SELECT * FROM v0 GROUP BY
DISTINCT ROLLUP ( v1 , v1 ) , ROLLUP ( v1 , USER ) , GROUPING SETS ( ROW ( )
, ( v1 ) ) , ROLLUP ( v1 < - - 61 AND v1 IN ( -2147483648 , - 94 ) , v1 ) )
v1 ORDER BY ( v1 + - - -1 ) , ( v1 + - - v1 IN ( SELECT v1 FALSE FROM (
SELECT FROM v0 GROUP BY v1 ) PRECISION ) ) ;


log detail:

2021-06-21 10:45:03.577 CST [2780861] HINT:  Future log output will go to
log destination "csvlog".
TRAP: FailedAssertion("ptr == NULL || nodeTag(ptr) == type", File:
"/home/supersix/fuzz/security/PostgreSQL/postgres/build/../src/include/nodes/nodes.h",
Line: 603, PID: 2780889)
postgres: supersix template1 [local]
SELECT(ExceptionalCondition+0xbb)[0x560474d5104b]
postgres: supersix template1 [local] SELECT(+0x2e5bfb)[0x5604746acbfb]
postgres: supersix template1 [local]
SELECT(parseCheckAggregates+0xae)[0x5604746aeaae]
postgres: supersix template1 [local] SELECT(+0x2be52d)[0x56047468552d]
postgres: supersix template1 [local]
SELECT(transformStmt+0x1ab3)[0x560474687163]
postgres: supersix template1 [local] SELECT(+0x2c2f59)[0x560474689f59]
postgres: supersix template1 [local] SELECT(+0x2c326f)[0x56047468a26f]
postgres: supersix template1 [local]
SELECT(transformStmt+0x1cc3)[0x560474687373]
postgres: supersix template1 [local]
SELECT(parse_sub_analyze+0x3f)[0x56047468880f]
postgres: supersix template1 [local] SELECT(+0x2eb7d7)[0x5604746b27d7]
postgres: supersix template1 [local]
SELECT(transformFromClause+0x8d)[0x5604746b4f6d]
postgres: supersix template1 [local] SELECT(+0x2be27d)[0x56047468527d]
postgres: supersix template1 [local]
SELECT(transformStmt+0x1ab3)[0x560474687163]
postgres: supersix template1 [local]
SELECT(parse_analyze+0x7c)[0x560474688a0c]
postgres: supersix template1 [local] SELECT(+0x735a0d)[0x560474afca0d]
postgres: supersix template1 [local]
SELECT(PostgresMain+0x1ae7)[0x560474afeda7]
postgres: supersix template1 [local] SELECT(+0x61676f)[0x5604749dd76f]
postgres: supersix template1 [local]
SELECT(PostmasterMain+0x1182)[0x5604749e06c2]
postgres: supersix template1 [local] SELECT(main+0x533)[0x560474490133]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0x7ffb088d00b3]
postgres: supersix template1 [local] SELECT(_start+0x2e)[0x56047449028e]

On Mon, 21 Jun 2021 at 20:15, PG Bug reporting form
<noreply@postgresql.org> wrote:
> run the following sql command through client and the PostgreSQL database
> process will crash:
>
> CREATE TABLE v0 ( v1 FLOAT NOT NULL PRIMARY KEY ) ;
> WITH v1 AS ( DELETE FROM v0 WHERE v1 <= - - - 9 RETURNING * ) INSERT INTO v0
> VALUES ( - - - - - - 95 ) ;
> SELECT v1 FROM ( SELECT * FROM v0 UNION ALL SELECT * FROM v0 GROUP BY
> DISTINCT ROLLUP ( v1 , v1 ) , ROLLUP ( v1 , USER ) , GROUPING SETS ( ROW ( )
> , ( v1 ) ) , ROLLUP ( v1 < - - 61 AND v1 IN ( -2147483648 , - 94 ) , v1 ) )
> v1 ORDER BY ( v1 + - - -1 ) , ( v1 + - - v1 IN ( SELECT v1 FALSE FROM (
> SELECT FROM v0 GROUP BY v1 ) PRECISION ) ) ;

Thanks for the report.  It looks like a thinko in 1d581ce71.   Code
was added there which insists the initial list element is a List, but
it's an IntList.  I think the code should just use linitial instead of
linitial_node.

I'm quite surprised that we don't have a test that picks this up.

David

On Mon, 21 Jun 2021 at 21:47, David Rowley <dgrowleyml@gmail.com> wrote:
> I'm quite surprised that we don't have a test that picks this up.

I was just looking at [1], line 1858. I see there is a test that runs
through that code, it's just that because the previous step sorts the
List of IntLists by the length of the IntList, that the IntList with 0
items is the initial list.  linitial_node() does allow NULL, so no
failure.

The test in question is this one in groupingsets.sql

select a, b, c
from (values (1, 2, 3), (4, null, 6), (7, 8, 9)) as t (a, b, c)
group by distinct rollup(a, b), rollup(a, c)
order by a, b, c;

Changing it to the following triggers the failure.

select a, b, c
from (values (1, 2, 3), (4, null, 6), (7, 8, 9)) as t (a, b, c)
group by distinct rollup(a, b), rollup(a, c), grouping sets (a)
order by a, b, c;

David

[1] https://coverage.postgresql.org/src/backend/parser/parse_agg.c.gcov.html

On Mon, 21 Jun 2021 at 22:10, Richard Guo <guofenglinux@gmail.com> wrote:
> On Mon, Jun 21, 2021 at 5:48 PM David Rowley <dgrowleyml@gmail.com> wrote:
>> I'm quite surprised that we don't have a test that picks this up.
>
>
>  A distinct group by clause would help to reveal this issue as:
>
>     explain select * from t GROUP BY distinct a, rollup(b);
>
> Maybe we can add a test case to cover it.

Since beta2 deadline is looming, I pushed the simple fix for now. I'll
start a thread on hackers to ask the authors of the patch about
additional testing.

Yaoguang, the fix went in as of [1]. Thanks again for the report.

David

[1] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=8d29d45d9b3cab95a866efbcdd9138b3d76741b3

David Rowley <dgrowleyml@gmail.com> writes:
> On Mon, 21 Jun 2021 at 20:15, PG Bug reporting form
> <noreply@postgresql.org> wrote:
>> run the following sql command through client and the PostgreSQL database
>> process will crash:

> Thanks for the report.  It looks like a thinko in 1d581ce71.   Code
> was added there which insists the initial list element is a List, but
> it's an IntList.  I think the code should just use linitial instead of
> linitial_node.

Hmm, if it's an int-list then the subsequent dup-elimination loop is
also wrong, and for that matter I don't think the preceding lines
would have worked.

> I'm quite surprised that we don't have a test that picks this up.

The code coverage report shows that we *do* have tests that run
through this code, so the existing typing is okay in the test cases
we have.  I'm guessing the real problem is that something upstream is
generating the wrong type of list in this example.

            regards, tom lane

On Tue, 22 Jun 2021 at 01:33, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> David Rowley <dgrowleyml@gmail.com> writes:
> > I'm quite surprised that we don't have a test that picks this up.
>
> The code coverage report shows that we *do* have tests that run
> through this code, so the existing typing is okay in the test cases
> we have.  I'm guessing the real problem is that something upstream is
> generating the wrong type of list in this example.

My analysis into why that test passes is in [1]. Did you miss that or
did you have another idea?

David

[1] https://www.postgresql.org/message-id/CAApHDvq0sqRfWCGj2JfZDs9DEiDfaBs=067Err3=EK09ct8bjg@mail.gmail.com

David Rowley <dgrowleyml@gmail.com> writes:
> On Tue, 22 Jun 2021 at 01:33, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I'm guessing the real problem is that something upstream is
>> generating the wrong type of list in this example.

> My analysis into why that test passes is in [1]. Did you miss that or
> did you have another idea?

Yeah, I hadn't gotten to that yet :-(.  Never mind ...

            regards, tom lane