Re: Server crash with certain encodings

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Thom Brown <thom(at)linux(dot)com>
Cc: pgsql-bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: Server crash with certain encodings
Date: 2016-02-29 03:31:27
Message-ID: 20894.1456716687@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Thom Brown <thom(at)linux(dot)com> writes:
> I can crash the server in 9.4, 9.5 and 9.6 when doing the following on
> Linux:

Hm, would you confirm that you get a stack trace like this:

#0 0x000000397ee32625 in raise () from /lib64/libc.so.6
#1 0x000000397ee33e05 in abort () from /lib64/libc.so.6
#2 0x000000397ee70537 in __libc_message () from /lib64/libc.so.6
#3 0x000000397ee75f4e in malloc_printerr () from /lib64/libc.so.6
#4 0x000000397ee78cad in _int_free () from /lib64/libc.so.6
#5 0x000000000076ce70 in free_struct_lconv () at pg_locale.c:394
#6 PGLC_localeconv () at pg_locale.c:460
#7 0x0000000000717cd5 in cash_in (fcinfo=<value optimized out>) at cash.c:112

Looks like we're getting confused about allocation/freeing of lconv
data --- I've not dug into it more closely than to reproduce the crash.

Aside from that, though, it's not really clear to me that it's sensible to
allow an lc_monetary (or lc_anything) setting that specifies an encoding
different from the database encoding. Should your example have failed at
the SET lc_monetary step? If not, what would you expect that to mean?

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Michael Paquier 2016-02-29 06:43:03 Re: Re: BUG #13685: Archiving while idle every archive_timeout with wal_level hot_standby
Previous Message Thom Brown 2016-02-29 02:15:54 Server crash with certain encodings