gregfelice commented on issue #2535:
URL: https://github.com/apache/age/issues/2535#issuecomment-5369730273
Confirmed on current master (`4d9b2506`, AGE 1.8.0) built against PostgreSQL
18.4 — this is not fixed, and it is not specific to 1.7.0.
The crash is a NULL pointer dereference in `create_vertex`,
`src/backend/executor/cypher_create.c:524-528`:
```c
elemTupleSlot->tts_values[vertex_tuple_properties] =
scanTupleSlot->tts_values[node->prop_attr_num]; /* line 526 */
elemTupleSlot->tts_isnull[vertex_tuple_properties] =
scanTupleSlot->tts_isnull[node->prop_attr_num];
```
Under gdb at the fault:
```
#0 create_vertex (css=0x..., node=0x..., next=0x0, list=0x...)
at src/backend/executor/cypher_create.c:526
#1 process_pattern (css=0x...) at src/backend/executor/cypher_create.c:168
#2 exec_cypher_create (node=0x...) at
src/backend/executor/cypher_create.c:227
(gdb) p scanTupleSlot $1 = (TupleTableSlot *) 0x0
(gdb) p node->prop_attr_num $2 = 1
(gdb) p css->slot $3 = (TupleTableSlot *) 0x0
```
`scanTupleSlot` is `econtext->ecxt_scantuple` (line 492), which
`exec_cypher_create` assigns at lines 214-216:
```c
econtext->ecxt_scantuple =
node->ss.ps.lefttree->ps_ProjInfo->pi_exprContext->ecxt_scantuple;
```
When the write clause's child is a projection-only node carrying no scan
tuple — which is what `CREATE ... WITH <constants> WHERE <constant predicate>`
plans to — that chain yields NULL, and line 526 dereferences it without a check.
Worth noting a NULL guard alone is probably not the right fix. The vertex
properties still have to be read from somewhere valid, so the question is why
the child plan has no scan tuple in this shape, not just how to avoid touching
it.
### This crash site accounts for five open issues
I ran each of these on master under gdb. All five stop at
`cypher_create.c:526` with `scanTupleSlot == NULL`:
| Issue | Reported trigger |
|---|---|
| #2501 | `cypher(CREATE ...)` inside SQL `WHERE NOT EXISTS` with a nested
`cypher(MATCH ...)` |
| #2508 | `CREATE (a) WITH a WHERE exists { RETURN 1 } RETURN 1` |
| #2527 | `CREATE p0 = (...)` then `WITH ... WHERE <constant preds>` then
`MATCH` |
| #2530 | multi-row `CREATE` then full-path `MERGE` (reached via
`exec_cypher_merge`:695) |
| #2535 | this issue |
They look like five different bugs from the outside and are one bug
underneath. #2508's reporter had already observed that `CREATE (a) WITH 1 AS x`
also crashes, which is this issue exactly.
This issue carries the smallest reproducer of the five:
```cypher
CREATE (n)
WITH 1 AS y
WHERE ('zrEJOrLh' CONTAINS (('E' + 'J') + 'OrL'))
RETURN y
```
I have not closed anything — #2501 is the earliest report, so consolidating
there instead may be preferable. That is a maintainer's call; I am only
recording that the five share one root cause so the fix is not attempted five
times.
Full triage of the current fuzz-report backlog, including the crash sites
that are genuinely distinct from this one, is in the comments on #2506, #2507,
#2534, #2536 and #2537.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
