| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Aleksander Alekseev <aleksander(at)tigerdata(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: [PATCH] Fix segmentation fault and infinite loop in jsonb_{plperl,plpython} |
| Date: | 2026-06-16 20:03:28 |
| Message-ID: | 963610.1781640208@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Aleksander Alekseev <aleksander(at)tigerdata(dot)com> writes:
> The second bug affects only jsonb_plperl. It's possible to construct a
> Perl object with circular references which will cause
> SV_to_JsonbValue() to go into an infinite loop here:
> while (SvROK(in))
> in = SvRV(in);
> I suggest fixing it by rewriting the while loop into a recursion with
> check_stack_depth() call. This will make the behavior consistent with
> jsonb_plpython.
Unfortunately, your 0002 is too cute for its own good. I tried it
here, with a not-especially-new gcc compiling at -O2, and found that
the tail recursion in SV_deref() is optimized into a loop. So the
stack doesn't grow and we still have an uninterruptible loop.
I don't immediately see a way to write that function so that the
compiler is certain not to spot the tail recursion. Tricks like
two mutually recursive functions might be seen through at
sufficiently high -O levels.
We could instead add a CHECK_FOR_INTERRUPTS, so that you can at
least break out of the infinite loop. I'm not sure if the case
is worth more effort than that.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Daniel Gustafsson | 2026-06-16 20:11:53 | Re: [oauth] Increased CPU usage during device flow with libcurl 8.20.0 |
| Previous Message | Corey Huinker | 2026-06-16 19:53:34 | Re: More jsonpath methods: translate, split, join |