Thread
-
BUG #17474: Segmentation fault from INSERT ( JumbleExpr )
PG Bug reporting form <noreply@postgresql.org> — 2022-05-05T12:10:19Z
The following bug has been logged on the website: Bug reference: 17474 Logged by: Victor Yegorov Email address: vyegorov@gmail.com PostgreSQL version: 14.2 Operating system: Ubuntu 20.04.4 LTS (focal) Description: Quite simple setup, that works on 13 version, is causing SEGFAULTs on 14.2. Reproducible. *** Table definition *** Table "public.outputs" Column | Type | Collation | Nullable | Default ----------------+-----------+-----------+----------+------------------------------------- id | integer | | not null | nextval('outputs_id_seq'::regclass) transaction_id | integer | | | address | bigint | | | position | integer | | | amount | bigint | | | type | integer | | | req_sigs | integer | | | multisig_type | integer[] | | | Indexes: "outputs_pkey" PRIMARY KEY, btree (id) "address" btree (address) "outputs_amount_idx" btree (amount) "transaction_id" btree (transaction_id) "trx_pos" btree (transaction_id, "position") Foreign-key constraints: "outputs_transaction_id_fkey" FOREIGN KEY (transaction_id) REFERENCES transactions(id) ON DELETE CASCADE Referenced by: TABLE "inputs" CONSTRAINT "inputs_output_id_fkey" FOREIGN KEY (output_id) REFERENCES outputs(id) ON DELETE CASCADE TABLE "output_datas" CONSTRAINT "output_datas_output_id_fkey" FOREIGN KEY (output_id) REFERENCES outputs(id) ON DELETE CASCADE *** INSERT statement *** LOG: server process (PID 2585336) was terminated by signal 11: Segmentation fault DETAIL: Failed process was running: INSERT INTO outputs (transaction_id, address, position, amount, type, req_sigs) VALUES (254800, 163252, 0, 1, 1, 1), (254800, 61860, 1, 1, 1, 1), (254800, 99617, 2, 1, 1, 1), (254800, 163255, 3, 1, 1, 1), (254800, 12098, 4, 1, 1, 1), (254800, 97997, 5, 1, 1, 1), (254800, 13404, 6, 1, 1, 1), (254800, 80413, 7, 1, 1, 1), (254800, 8319, 8, 1, 1, 1), (254800, 163261, 9, 1, 1, 1), (254800, 163262, 10, 1, 1, 1), (254800, 163263, 11, 1, 1, 1), (254800, 163264, 12, 1, 1, 1), (254800, 163265, 13, 1, 1, 1), (254800, 163266, 14, 1, 1, 1), (254800, 163267, 15, 1, 1, 1), (254800, 163197, 16, 1, 1, 1), (254800, 163269, 17, 1, 1, 1), (254800, 163270, 18, 1, 1, 1), (254800, 1238, 19, 1, 1, 1), (254800, 12093, 20, 1, 1, 1), (254800, 24167, 21, 1, 1, 1), (254800, 39000, 22, 1, 1, 1), (254800, 163255, 23, 1, 1, 1), (254800, 163275, 24, 1, 1, 1), (254800, 93813, 25, 1, 1, 1), (254800, 163277, 26, 1, 1, 1), (254800, 163278, 27, 1, 1, 1), (254800, 8285, 28, 1, 1, 1), (254800, 9111, 29, 1, 1, 1), (254800, 54795, 30, 1, 1, 1), (254 Total length of the INSERT statement is round 100Kb. *** Backtrace *** Core was generated by `postgres: 14/main: parser litecoin 10.1.1.20(43434) PARSE '. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x000056397d94c297 in memcpy (__len=1016, __src=<optimized out>, __dest=<optimized out>) at /usr/include/x86_64-linux-gnu/bits/string_fortified.h:34 34 /usr/include/x86_64-linux-gnu/bits/string_fortified.h: No such file or directory. (gdb) bt #0 0x000056397d94c297 in memcpy (__len=1016, __src=<optimized out>, __dest=<optimized out>) at /usr/include/x86_64-linux-gnu/bits/string_fortified.h:34 #1 AppendJumble (item=<optimized out>, item@entry=0x7f403929afd8 "u", size=30595144541, size@entry=4, jstate=<optimized out>, jstate=<optimized out>) at ./build/../src/backend/utils/misc/queryjumble.c:213 #2 0x000056397d94c6c4 in JumbleExpr (jstate=0x7f4038f652e0, node=<optimized out>) at ./build/../src/backend/utils/misc/queryjumble.c:373 #3 0x000056397d94c8c1 in JumbleExpr (jstate=0x7f4038f652e0, node=<optimized out>) at ./build/../src/backend/utils/misc/queryjumble.c:743 #4 0x000056397d94c8c1 in JumbleExpr (jstate=0x7f4038f652e0, node=<optimized out>) at ./build/../src/backend/utils/misc/queryjumble.c:743 #5 0x000056397d94c5dc in JumbleRangeTable (rtable=0x7f403966a020, jstate=0x7f4038f652e0) at ./build/../src/backend/utils/misc/queryjumble.c:300 #6 JumbleQueryInternal (jstate=0x7f4038f652e0, query=0x7f4039669b28) at ./build/../src/backend/utils/misc/queryjumble.c:248 #7 0x000056397d94cfec in JumbleQuery (query=query@entry=0x7f4039669b28, querytext=querytext@entry=0x56397fdb9b59 "") at ./build/../src/backend/utils/misc/queryjumble.c:127 #8 0x000056397d5e26b3 in parse_analyze_varparams (parseTree=parseTree@entry=0x7f4039669aa8, sourceText=sourceText@entry=0x56397fdb9b59 "", paramTypes=paramTypes@entry=0x7fff3a4f6748, numParams=numParams@entry=0x7fff3a4f6734) at ./build/../src/backend/parser/analyze.c:169 #9 0x000056397d80cc1e in exec_parse_message (numParams=<optimized out>, paramTypes=<optimized out>, stmt_name=0x56397fdb9b58 "", query_string=0x56397fdb9b59 "") at ./build/../src/backend/tcop/postgres.c:1458 #10 PostgresMain (argc=argc@entry=1, argv=argv@entry=0x7fff3a4f6a20, dbname=<optimized out>, username=<optimized out>) at ./build/../src/backend/tcop/postgres.c:4515 #11 0x000056397d78cb6b in BackendRun (port=<optimized out>, port=<optimized out>) at ./build/../src/backend/postmaster/postmaster.c:4530 #12 BackendStartup (port=<optimized out>) at ./build/../src/backend/postmaster/postmaster.c:4252 #13 ServerLoop () at ./build/../src/backend/postmaster/postmaster.c:1745 #14 0x000056397d78d9ec in PostmasterMain (argc=<optimized out>, argv=0x56397fbacf10) at ./build/../src/backend/postmaster/postmaster.c:1417 #15 0x000056397d506c8d in main (argc=5, argv=0x56397fbacf10) at ./build/../src/backend/main/main.c:209 -
Re: BUG #17474: Segmentation fault from INSERT ( JumbleExpr )
Tom Lane <tgl@sss.pgh.pa.us> — 2022-05-05T13:44:40Z
PG Bug reporting form <noreply@postgresql.org> writes: > Quite simple setup, that works on 13 version, is causing SEGFAULTs on 14.2. > Reproducible. Can you provide a reproducer SQL script? The stack trace looks like some element of the VALUES list is not in the format that JumbleExpr is expecting, but there's nothing odd-looking about the fragment you showed. regards, tom lane
-
Re: BUG #17474: Segmentation fault from INSERT ( JumbleExpr )
Victor Yegorov <vyegorov@gmail.com> — 2022-05-05T14:34:40Z
чт, 5 мая 2022 г. в 16:44, Tom Lane <tgl@sss.pgh.pa.us>: > PG Bug reporting form <noreply@postgresql.org> writes: > > Quite simple setup, that works on 13 version, is causing SEGFAULTs on > 14.2. > > Reproducible. > > Can you provide a reproducer SQL script? The stack trace looks like > some element of the VALUES list is not in the format that JumbleExpr > is expecting, but there's nothing odd-looking about the fragment > you showed. > I will try to find such a case, though it might not be straightforward. Same query after the restart of Postgres succeeds. So it feels like we're accumulating smth here. -- Victor Yegorov
-
Re: BUG #17474: Segmentation fault from INSERT ( JumbleExpr )
Tom Lane <tgl@sss.pgh.pa.us> — 2022-05-05T15:12:36Z
PG Bug reporting form <noreply@postgresql.org> writes: > (gdb) bt > #0 0x000056397d94c297 in memcpy (__len=1016, __src=<optimized out>, > __dest=<optimized out>) at > /usr/include/x86_64-linux-gnu/bits/string_fortified.h:34 > #1 AppendJumble (item=<optimized out>, item@entry=0x7f403929afd8 "u", > size=30595144541, size@entry=4, jstate=<optimized out>, jstate=<optimized > out>) at ./build/../src/backend/utils/misc/queryjumble.c:213 If we take that at face value --- which isn't a very safe assumption when dealing with optimized code --- it suggests that the loop in AppendJumble has gone crazy and allowed "size" to wrap around to some large value. If that happened then it'd iterate until "item" advances off the end of memory and you get SIGSEGV. I don't see how that could possibly happen though, short of a compiler bug: while (size > 0) { Size part_size; ... part_size = Min(size, JUMBLE_SIZE - jumble_len); ... size -= part_size; } How could the value of part_size exceed size? I've spent time staring at that code before, because Coverity regularly whines about queryjumble.c in terms suggesting that it sees a potential for exactly this kind of bug. But I sure don't see it. regards, tom lane