MIME-Version: 1.0
References: <2074634.1744839761@sss.pgh.pa.us>
 <0A3CF5C4-9947-42E3-89A9-34FCF7BA95BA@yesql.se>
 <2078511.1744841564@sss.pgh.pa.us>
 <DCD56158-A642-4954-87FF-9DAD5425F3FF@yesql.se>
 <2084687.1744844690@sss.pgh.pa.us>
 <CAOYmi+n+DHpaEV5hymhufutTgc+S=+pDQfXEUi4hMAV1eO8aTw@mail.gmail.com>
 <2087556.1744846124@sss.pgh.pa.us>
 <0A596D8B-24F3-408F-B89B-B42014B00A05@yesql.se>
 <2202326.1744903233@sss.pgh.pa.us>
In-Reply-To: <2202326.1744903233@sss.pgh.pa.us>
From: Jacob Champion <jacob.champion@enterprisedb.com>
Date: Thu, 17 Apr 2025 08:48:05 -0700
Message-ID: 
 <CAOYmi+mxjW0GhSGPKoOy3TYrFcdTM=5FcUn=u1i7CFhb2303Zg@mail.gmail.com>
Subject: Re: jsonapi: scary new warnings with LTO enabled
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Daniel Gustafsson <daniel@yesql.se>, pgsql-hackers@lists.postgresql.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAOYmi%2BmxjW0GhSGPKoOy3TYrFcdTM%3D5FcUn%3Du1i7CFhb2303Zg%40mail.gmail.com>
Precedence: bulk

On Thu, Apr 17, 2025 at 8:20=E2=80=AFAM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I confirm this silences those warnings on my Fedora 41 box.

Instead of doing

    lex =3D calloc(...);
    /* (error out on NULL return) */
    makeJsonLexContextCstringLen(lex, ...);

we need to do

    lex =3D makeJsonLexContextCstringLen(NULL, ...);
    /* (error out on NULL return) */

so that JSONLEX_FREE_STRUCT is set correctly. Otherwise we'll leak the
main allocation:

    =3D=3D12550=3D=3DERROR: LeakSanitizer: detected memory leaks
    Direct leak of 120 byte(s) in 1 object(s) allocated from:
        #0 0xaaaae34d2a84 in __interceptor_calloc
(/home/jacob/src/postgres/worktree-oauth/build-clang/src/interfaces/libpq/f=
uzz_libpq_handle_oauth_sasl_error+0x112a84)
(BuildId: 359bf20b63a97771ccb3bd2c238485920485521f)
        #1 0xaaaae3510ff0 in handle_oauth_sasl_error
/home/jacob/src/postgres/worktree-oauth/build-clang/../src/interfaces/libpq=
/fe-auth-oauth.c:511:8

> I'm content to do it like this, but maybe Jacob wants to
> investigate alternatives?

I was more worried about it when you said you wanted to get rid of the
stack allocation API. (I like having the flexibility to choose between
the two forms, not just for performance but also for struct
embedding.) But I'm perfectly happy with just adjusting these sites.

Thanks!
--Jacob