Thread: BUG #17481: sometime pg_stat_statements coredump

The following bug has been logged on the website:

Bug reference:      17481
Logged by:          tangcheng
Email address:      mailtch@163.com
PostgreSQL version: 14.2
Operating system:   debian 11
Description:

In my database , use pg_stat_statement, but sometime, coredump
occurred，Details are as follows：

Using host libthread_db library"/lib/x86 64-1inux-gnu/libthread db.so.1"
Core was generated by `postgres: XXXX XXXXX(6294) CALL Program terminated
with signal SIGSEGV, Segmentation fault.
#0  0x0000556d1bc6ac9d in CleanQuerytext()
(gdb) bt
#0  0x0000556d1bc6ac9d in CleanQuerytext()
#1  0x00007f8450d3522f in pgss_store() from
/usr/local/pgsql-14.2/1ib/pg_stat_statements.so
#2  0x00007f8450d362bd in
pgss_ProcessUtility()from/usr/1ocal/pgsq1-14.2/1ib/pg_stat_statements.so 
#3  0x0000556d1bb42c7f in PortalRunUtility() 
#4  0x0000556d1bb42dab in PortalRunMulti () 
#5  0x0000556d1bb43275 in PortalRun()
#6  0x0000556d1bb409fe in PostgresMain () 
#7  0x0000556d1bac74f1 in ServerLoop()
#8 0x0000556d1bac8322 in PostmasterMain() 
#9 0x0000556d1b86d860 in main (()

PG Bug reporting form <noreply@postgresql.org> writes:
> In my database , use pg_stat_statement, but sometime, coredump 
> occurred，Details are as follows：

Not much info here.  Can you install the debug symbols for the postgres
package you're using and repeat the backtrace?  Another potentially useful
bit of info would be the source text for the query that's causing the
failure, which you could get with "p debug_query_string" in gdb.

            regards, tom lane

On Mon, May 16, 2022 at 11:21:21AM -0400, Tom Lane wrote:
> Not much info here.  Can you install the debug symbols for the postgres
> package you're using and repeat the backtrace?  Another potentially useful
> bit of info would be the source text for the query that's causing the
> failure, which you could get with "p debug_query_string" in gdb.

CleanQuerytext() would crash on a NULL string AFAIK, but this really
smells like a case where a utility code path is freeing the pointer of
the query string that PGSS is attempting to look at.  I have seen this
problem in the past, where this subtle issue could be created even if
the code was rather careful in the query string handling.  Here, are
we dealing with a CALL that involves plpgsql?  Or is that a different
language, like something out of core?
--
Michael