Hi, On Tue, May 12, 2026 at 11:51 PM Ashutosh Bapat < [email protected]> wrote:
> On Tue, May 12, 2026 at 11:23 PM SATYANARAYANA NARLAPURAM > <[email protected]> wrote: > > > > Hi hackers, > > > > My PG19 fuzz tests detected the $subject issue in dependency.c. > > > > Repro: It is not 100% deterministic because of the timeout, if hard to > follow can write > > an injection point test. > > > > \set ON_ERROR_STOP off > > > > CREATE TABLE n1(id int PRIMARY KEY, name text); > > > > -- Many indexes ensure the cascade takes enough time after the propgraph > > -- element's deleteOneObject() for statement_timeout to fire. > > DO $$ BEGIN > > FOR i IN 1..50 LOOP > > EXECUTE format('CREATE INDEX idx_%s ON n1 (id) WHERE id > %s', i, i); > > END LOOP; > > END $$; > > CREATE PROPERTY GRAPH pg1 VERTEX TABLES (n1 LABEL l1 PROPERTIES(id, > name)); > > > > CREATE TABLE n2(id int PRIMARY KEY, name text); > > CREATE PROPERTY GRAPH pg2 VERTEX TABLES (n2 LABEL l2 PROPERTIES(id, > name)); > > > > SET statement_timeout = '3ms'; > > DROP TABLE n1 CASCADE; > > RESET statement_timeout; > > > > DROP TABLE n2 CASCADE; > > > > SELECT 1 AS status; > > > > The static lists propgraph_orphan_label_graphids and > propgraph_orphan_property_graphids > > in dependency.c are allocated in TopTransactionContext during > deleteOneObject(). They are > > only reset on the success path of > performDeletion()/performMultipleDeletions(), in > > run_deferred_propgraph_orphan_cleanup(). If a transaction aborts after > the lists have been > > populated, for example due to statement_timeout, or any other error > thrown during the cascade), > > AbortTransaction() frees TopTransactionContext but the static pointers > remain set. A subsequent > > property graph cascade in the same backend session then passes the > dangling pointers to > > list_append_unique_oid(), which walks freed memory. With assertions > enabled this trips > > > > TRAP: failed Assert("IsOidList(list)"), File: "list.c", Line: 726 > > > > I am not able to find any of the variables mentioned in the above > paragraph in dependency.c. Am I missing something? My branch's HEAD is > pointing at 422e54e3092afd09997d27cc7c99598f91075b0d. Patch doesn't > apply. Am I missing something? > Looks like I ended up applying some patches which had the issue. Don't see this in the HEAD. Please ignore, apologies for the confusion. Thanks, Satya
