[BUG] Possible occurrence of segfault in ecpg test

Started by Daniil Davydovover 1 year ago2 messageshackers
Jump to latest
#1Daniil Davydov
3danissimo@gmail.com

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

Attachments:

0001-Fix-refer-to-a-null-pointer.patchtext/x-patch; charset=US-ASCII; name=0001-Fix-refer-to-a-null-pointer.patchDownload+71-64
#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Daniil Davydov (#1)
Re: [BUG] Possible occurrence of segfault in ecpg test

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