Segmentation fault on EXECUTE empty string

[M-Butter]

When I have a procedure that contains an EXECUTE statement with an empty string ('') as argument, or just comment ('--') as argument, and I run plpgsql_check on that function, then a segmentation fault is the result:

[mb@mb-laptop ~]$ psql -d postgres psql (16.1) Type "help" for help.

postgres=# create database test; CREATE DATABASE

postgres=# \c test You are now connected to database "test" as user "mb".

test=# create schema test; CREATE SCHEMA

test=# create extension plpgsql_check; CREATE EXTENSION

test=# select extversion from pg_extension where extname = 'plpgsql_check'; extversion ------------ 2.6 (1 row)

test=# CREATE OR REPLACE PROCEDURE test.test_execute_empty() LANGUAGE 'plpgsql' AS $BODY$ begin execute ''; end; $BODY$; CREATE PROCEDURE

test=# call test.test_execute_empty(); CALL

test=# select * from plpgsql_check_function('test.test_execute_empty', 0, 'text', false, false, false, false); server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. The connection to the server was lost. Attempting reset: Failed. The connection to the server was lost. Attempting reset: Failed.

From the server log:

2023-11-22 08:40:08.297 CET [141327] LOG: server process (PID 250331) was terminated by signal 11: Segmentation fault 2023-11-22 08:40:08.297 CET [141327] DETAIL: Failed process was running: select * from plpgsql_check_function('test.test_execute_empty', 0, 'text', false, false, false, false); 2023-11-22 08:40:08.297 CET [141327] LOG: terminating any other active server processes 2023-11-22 08:40:08.299 CET [250699] FATAL: the database system is in recovery mode 2023-11-22 08:40:08.300 CET [141327] LOG: all server processes terminated; reinitializing 2023-11-22 08:40:08.336 CET [250703] LOG: database system was interrupted; last known up at 2023-11-22 08:36:22 CET 2023-11-22 08:40:09.461 CET [250703] LOG: database system was not properly shut down; automatic recovery in progress 2023-11-22 08:40:09.465 CET [250703] LOG: redo starts at 5/646B3FC8 2023-11-22 08:40:09.466 CET [250703] WARNING: could not open directory "base/996474": No such file or directory 2023-11-22 08:40:09.466 CET [250703] CONTEXT: WAL redo at 5/646B40C8 for Database/DROP: dir 1663/996474 2023-11-22 08:40:09.466 CET [250703] WARNING: some useless files may be left behind in old database directory "base/996474" 2023-11-22 08:40:09.466 CET [250703] CONTEXT: WAL redo at 5/646B40C8 for Database/DROP: dir 1663/996474 2023-11-22 08:40:09.478 CET [250703] LOG: invalid record length at 5/64B24988: expected at least 24, got 0 2023-11-22 08:40:09.478 CET [250703] LOG: redo done at 5/64B24950 system usage: CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.01 s 2023-11-22 08:40:09.486 CET [250704] LOG: checkpoint starting: end-of-recovery immediate wait 2023-11-22 08:40:09.530 CET [250704] LOG: checkpoint complete: wrote 968 buffers (5.9%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.022 s, sync=0.018 s, total=0.046 s; sync files=305, longest=0.004 s, average=0.001 s; distance=4546 kB, estimate=4546 kB; lsn=5/64B24988, redo lsn=5/64B24988 2023-11-22 08:40:09.554 CET [141327] LOG: database system is ready to accept connections 2023-11-22 08:40:09.558 CET [250711] LOG: pg_cron scheduler started

[okbob]

should be fixed by 463ac3acf402ad716cc533851058b0a8ad0d4c6d commit.

You are first man who used empty string there in my 20 years work with plpgsql :-).

[M-Butter]

Hello Pavel,

The problem originates from a migrated Oracle procedure that contained an execute immediate 'create table ...' statement. Our migration software decided that the create table statement needed extra attention, so commented it out inside the create table string. The empty string was just a simplified version of that, which caused the same problem.

Thanks for fixing, Martin.

[okbob]

st 22. 11. 2023 v 13:37 odesílatel M-Butter @.***> napsal:

Hello Pavel,

The problem originates from a migrated Oracle procedure that contained an execute immediate 'create table ...' statement. Our migration software decided that the create table statement needed extra attention, so commented it out inside the create table string. The empty string was just a simplified version of that, which caused the same problem.

Thanks for fixing,

Thank you for report

Pavel

Martin.

— Reply to this email directly, view it on GitHub https://github.com/okbob/plpgsql_check/issues/161#issuecomment-1822694648, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEFO47Y3WMULTYGRS5D6W3YFXWZHAVCNFSM6AAAAAA7VZGGLOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMRSGY4TINRUHA . You are receiving this because you commented.Message ID: @.***>