Avoid core dump in pgstat_read_statsfile() - Mailing list pgsql-hackers

From Bertrand Drouvot
Subject Avoid core dump in pgstat_read_statsfile()
Date
Msg-id aAieZAvM+K1d89R2@ip-10-97-1-34.eu-west-3.compute.internal
Whole thread Raw
Responses Re: Avoid core dump in pgstat_read_statsfile()
List pgsql-hackers
Hi hackers,

please find attached a patch to $SUBJECT.

Indeed one could generate a core dump similar to:

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000000000a7a7a7 in pgstat_init_entry (kind=129, shhashent=0x7a55845cfd98) at pgstat_shmem.c:314
314             chunk = dsa_allocate0(pgStatLocal.dsa, pgstat_get_kind_info(kind)->shared_size);
(gdb) bt
#0  0x0000000000a7a7a7 in pgstat_init_entry (kind=129, shhashent=0x7a55845cfd98) at pgstat_shmem.c:314
#1  0x0000000000a72935 in pgstat_read_statsfile () at pgstat.c:1982
#2  0x0000000000a700a8 in pgstat_restore_stats () at pgstat.c:507

by:

1. creating a custom stat kind (non fixed_amount and write_to_file enabled)
2. generate stats
3. stop the engine
4. change the custom PGSTAT_KIND id linked to 1., compile and install
5. re-start the engine

I think that a check on pgstat_get_kind_info() is missing for this scenario, the
patch adds it. Such a check already exists for PGSTAT_FILE_ENTRY_FIXED and
for stats entry identified by name on disk, but not for PGSTAT_FILE_ENTRY_HASH.

The v18 existing checks mentioned above as well as the new check were missing
in pre-18 but I don't think it's worth a back-patch as the issue is unlikely to
occur without custom stats. Adding a v18 open item then.

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com

Attachment

pgsql-hackers by date:

Previous
From: Frédéric Yhuel
Date:
Subject: Re: [BUG] temporary file usage report with extended protocol and unnamed portals
Next
From: Devrim Gündüz
Date:
Subject: Re: What's our minimum supported Python version?