icu_collation_attributes() crashes server with certain attribute combinations

[noinkling]

=# SELECT * FROM icu_collation_attributes('und-u-ks-level1-ka-shifted-kv-space');
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.

Same with:

• und-u-ks-level1-kv-punct|symbol|currency
• und-u-ka-shifted-kv-punct|symbol|currency
• Probably other combinations?

They all work if I set the second argument (exclude_defaults) to true though.

These combinations work fine (although there isn't actually a kv row in the result, it changes what's in the parentheses of displayname instead):

• und-u-ks-level1-kv-space
• und-u-ka-shifted-kv-space
• und-u-kv-punct|symbol|currency
• ...And a whole bunch more.

Postgres 13 (x64), Windows 10, ICU 67.1 (extension compiled with MSVC). Haven't tested on Linux.

Relevant section from the server log:

[4968] LOG:  server process (PID 8840) was terminated by exception 0xC0000409
[4968] DETAIL:  Failed process was running: SELECT * FROM icu_collation_attributes('und-u-ks-level1-ka-shifted-kv-space');
[4968] HINT:  See C include file "ntstatus.h" for a description of the hexadecimal value.

I think it has something to do with the displayname - maybe a long description is too much for its allocated buffer or something?

[dverite]

Thanks for the report. I don't reproduce it on linux, but I think that commit 6515081 unfortunately missed one of these uloc_getDisplay* calls, and as you suspect, the long displayname triggers an allocation bug. I'll commit a fix shortly.
The missing kv tag is normal, icu_ext doesn't know about kv yet. I'll look at adding this separately.

[dverite]

I hope the bug is fixed by the just-pushed commit d6662df.

[noinkling]

That fixes it 👍