Re: Crash issue in PG18.5 regression

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: Álvaro Herrera <alvherre(at)kurilemu(dot)de>, "Masashi Kamura (Fujitsu)" <kamura(dot)masashi(at)fujitsu(dot)com>
Cc: "'pgsql-hackers(at)lists(dot)postgresql(dot)org'" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Jeff Davis <pgsql(at)j-davis(dot)com>
Subject: Re: Crash issue in PG18.5 regression
Date: 2026-08-11 09:19:12
Message-ID: a9c06b03-94ec-4871-9271-cb776a2d0378@iki.fi
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 11/08/2026 09:32, Álvaro Herrera wrote:
> On 2026-Aug-11, Masashi Kamura (Fujitsu) wrote:
>
>> We found that the program crashes when following the steps below.
>>
>> 1) Create the instance
>> initdb -D data --encoding=UTF8 --no-locale
>>
>> 2) Execute following SQL
>> SELECT to_date('01 ŞUB 2010', 'DD TMMON YYYY');
>>
>> We are analyzing the cause and the following commit seems the cause.
>> https://github.com/postgres/postgres/commit/011384ba45f
>>
>> Could you please check this?
>
> I confirm that this crashes with my regular build options also, as long
> as initdb --no-locale is used. The backtrace from the crash point is
>
> #0 __GI___towupper_l (wc=74, locale=locale(at)entry=0x0) at ./wctype/wcfuncs_l.c:69
> #1 0x0000563291e315b8 in strupper_libc_mb (dest=0x7ffe3664f100 "\002", destsize=80, src=0x5632b0c066d8 "Jan",
> srclen=3, locale=0x5632b0c02898) at ../../source/REL_18_STABLE/src/backend/utils/adt/pg_locale_libc.c:398
> #2 strupper_libc (dst=dst(at)entry=0x7ffe3664f100 "\002", dstsize=dstsize(at)entry=80, src=src(at)entry=0x5632b0c066d8 "Jan",
> srclen=<optimized out>, locale=locale(at)entry=0x5632b0c02898)
> at ../../source/REL_18_STABLE/src/backend/utils/adt/pg_locale_libc.c:147
> #3 0x0000563291e2f029 in pg_strupper (dst=dst(at)entry=0x7ffe3664f100 "\002", dstsize=dstsize(at)entry=80,
> src=src(at)entry=0x5632b0c066d8 "Jan", srclen=<optimized out>, locale=locale(at)entry=0x5632b0c02898)
> at ../../source/REL_18_STABLE/src/backend/utils/adt/pg_locale.c:1325
>
> The relevant code in src/backend/utils/adt/pg_locale_libc.c's
> strupper_libc_mb() from frame 1 is
>
> 397 │ for (curr_char = 0; workspace[curr_char] != 0; curr_char++)
> 398 │ workspace[curr_char] = towupper_l(workspace[curr_char], loc);
>
> where the important detail is that 'loc' is 0, which is not a valid
> locale handle.
>
> The locale code is quite the maze,

Indeed :-(.

> but I'll see if I can find why is the locale object not
> initialized.
For C locale, there is no locale object. Before commit 011384ba45f, none
of the callers called pg_strupper() with the C locale, they checked and
special-cased it and called asc_toupper() directly. See str_toupper().

Interestingly this only fails on REL_18_STABLE. On REL_19_STABLE,
pg_strupper() checks if locale->ctype is NULL, and does the equivalent
of asc_toupper() internally. On REL_17_STABLE and below didn't have
pg_strupper() so the equivalent of commit 011384ba45f uses str_toupper()
instead on those branches, which works.

I think the best fix is to make pg_strupper() in REL_18_STABLE also work
with the C locale. It's an accident waiting to happen if it doesn't.
(And same for all the other pg_str*() functions, of course)

- Heikki

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Yilin Zhang 2026-08-11 09:21:03 Re: Per-table resync for logical replication subscriptions
Previous Message Zsolt Parragi 2026-08-11 09:08:31 Re: Unlogged materialized views