Re: Improve pg_re_throw: check if sigjmp_buf is valid and report error

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Xiaoran Wang <fanfuxiaoran(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Improve pg_re_throw: check if sigjmp_buf is valid and report error
Date: 2024-08-20 03:44:03
Message-ID: 1461089.1724125443@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Xiaoran Wang <fanfuxiaoran(at)gmail(dot)com> writes:
>> Yeah, that's the big problem. I don't have any confidence at all
>> that this would detect misuse. It'd require that the old stack
>> frame gets overwritten, which might not happen for a long time,
>> and it'd require that somebody eventually do a longjmp, which again
>> might not happen for a long time --- and when those did happen, the
>> error would be detected in someplace far away from the actual bug,
>> with little evidence remaining to help you localize it.

> Exactly, it cannot tell you which PG_TRY left the invalid sigjmp_buf,
> but to implement that is easy I think, recording the line num maybe.

I don't think you get to assume that the canary word gets overwritten
but debug data a few bytes away survives.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ashutosh Bapat 2024-08-20 03:56:59 Re: define PG_REPLSLOT_DIR
Previous Message Xiaoran Wang 2024-08-20 03:39:42 Re: Improve pg_re_throw: check if sigjmp_buf is valid and report error