[BUG] Possible occurrence of segfault in ecpg test
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t50720psql -h localhost -U postgresBuilt from patchset v1 (message #1), August 10, 2026 at 03:07 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t50720_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t50720_1 && git checkout t50720_1Patchset v1 (message #1) is on t50720_1
Hi,
The src/interfaces/ecpg/test/sql/bytea.pgc file contains the following code :
***
init();
exec sql truncate test;
exec sql insert into test values(:send_buf[0], :send_buf[1]);
exec sql insert into test values(:send_buf[0], :send_buf[1]);
exec sql select data1 into :recv_vlen_buf from test;
dump_binary(recv_vlen_buf[0].arr, recv_vlen_buf[0].len, 0);
dump_binary(recv_vlen_buf[1].arr, recv_vlen_buf[1].len, 0);
free(recv_vlen_buf);
***
recv_vlen_buf is initialized in the following way :
***
bytea recv_vlen_buf[][DATA_SIZE];
recv_vlen_buf = NULL
***
Thus, if the program behaves in an unexpected way and the transaction
is aborted before it executes the
"select data1 into :recv_vlen_buf from test" query, dump_binary will
refer to a null pointer. So, instead of an error
message, the user will see a segfault.
I think that in all such cases it is worth adding some checks into
.pgc and .c files (like in attached patch)
--
Best regards,
Daniil Davydov
Daniil Davydov <3danissimo@gmail.com> writes:
Thus, if the program behaves in an unexpected way and the transaction
is aborted before it executes the
"select data1 into :recv_vlen_buf from test" query, dump_binary will
refer to a null pointer. So, instead of an error
message, the user will see a segfault.
I think that in all such cases it is worth adding some checks into
.pgc and .c files (like in attached patch)
I cannot get excited about changing this. In the first place,
this is hardly the only conceivable failure here --- for example,
if the query succeeds but returns only one row, the code still
segfaults. In the second place, this is just test code and any
sort of failure is as good as any other in terms of calling our
attention to a problem. In the third place, if we did want to
improve our standard of robustness for the ECPG tests, there are
probably many other places in them with similar issues. Making
that happen seems like a lot of work for little return. So I'm
inclined to just leave it alone.
regards, tom lane