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

On Mon, Aug 19, 2024 at 2:17 AM Xiaoran Wang <fanfuxiaoran(at)gmail(dot)com> wrote:
> If the code in PG_TRY contains any non local control flow other than
> ereport(ERROR) like goto, break etc., the PG_CATCH or PG_END_TRY cannot
> be called, then the PG_exception_stack will point to the memory whose
> stack frame has been released. So after that, when the pg_re_throw
> called, __longjmp() will crash and report Segmentation fault error.
>
> Addition to sigjmp_buf, add another field 'int magic' which is next to
> the sigjum_buf in the local stack frame memory. The magic's value is always
> 'PG_exception_magic 0x12345678'. And in 'pg_re_throw' routine, check if
> the magic's value is still '0x12345678', if not, that means the memory
> where the 'PG_exception_stack' points to has been released, and the 'sigbuf'
> must be invalid.
>
> The related code is in patch 0001

This is an interesting idea. I suspect if we do this we want a
different magic number and a different error message than what you
chose here, but those are minor details.

I'm not sure how reliable this would be at actually finding problems,
though. It doesn't seem guaranteed that the magic number will get
overwritten if you do something wrong; it's just a possibility. Maybe
that's still useful enough that we should adopt this, but I'm not
sure.

Personally, I don't think I've ever made this particular mistake. I
think a much more common usage error is exiting the catch-block
without either throwing an error or rolling back a subtransaction. But
YMMV, of course.

--
Robert Haas
EDB: http://www.enterprisedb.com