Re: pg_parse_json() should not leak token copies on failure

From: Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org, Michael Paquier <michael(at)paquier(dot)xyz>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Subject: Re: pg_parse_json() should not leak token copies on failure
Date: 2024-10-07 22:45:25
Message-ID: CAOYmi+kiiM83=H6YQ77NSSCtkGAzAnZfC0vZS=aLM9QZx=Rn_A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Oct 2, 2024 at 10:45 AM Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
> Generally looks good. Should we have a check in
> setJsonLexContextOwnsTokens() that we haven't started parsing yet, for
> the incremental case?

Good catch. Added in v4.

> > At the moment, we have a test matrix consisting of "standard frontend"
> > and "shlib frontend" tests for the incremental parser. I'm planning
> > for the v4 patch to extend that with a "owned/not owned" dimension;
> > any objections?
> >
>
> Sounds reasonable.

This is also done, along with runs of pgindent/perltidy.

I've added a 0002 as well. While running tests under Valgrind, it
complained about the uninitialized dummy_lex on the stack, which is
now fixed. (That bug was introduced with my patch in 0785d1b8b and is
technically orthogonal to 0001, but I figured I could track it here
for now.) This is also how I found out that my existing fuzzers
weren't checking for uninitialized memory, like I thought they were.
Grumble...

Thanks,
--Jacob

Attachment Content-Type Size
since-v3.diff.txt text/plain 11.5 KB
v4-0001-jsonapi-add-lexer-option-to-keep-token-ownership.patch application/octet-stream 17.6 KB
v4-0002-jsonapi-fully-initialize-dummy-lexer.patch application/octet-stream 998 bytes

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2024-10-07 23:25:11 Re: First draft of PG 17 release notes
Previous Message Tom Lane 2024-10-07 22:41:42 Re: On disable_cost