Re: Server crash with certain encodings

On 29 February 2016 at 03:31, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> 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
>

Yes, I get a similar stack trace:

#0 0x00007ffd8ff7f1d5 in __GI_raise (sig=sig(at)entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x00007ffd8ff82388 in __GI_abort () at abort.c:90
#2 0x00007ffd8ffba7bb in __libc_message (do_abort=do_abort(at)entry=2,
fmt=fmt(at)entry=0x7ffd900b7368 "*** Error in `%s': %s: 0x%s ***\n")
at ../sysdeps/unix/sysv/linux/libc_fatal.c:199
#3 0x00007ffd8ffc4a16 in malloc_printerr (action=3, str=0x7ffd900b330a
"free(): invalid pointer", ptr=<optimized out>) at malloc.c:4923
#4 0x00007ffd8ffc5793 in _int_free (av=<optimized out>, p=0x7ffd8eb98245,
have_lock=0) at malloc.c:3779
#5 0x000000000085fd27 in free_struct_lconv (s=s(at)entry=0xfb6d00
<CurrentLocaleConv.10495>) at pg_locale.c:394
#6 0x000000000086063a in PGLC_localeconv () at pg_locale.c:460
#7 0x00000000007e72eb in cash_in (fcinfo=<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?
>

It's utter nonsense. I was playing around with locales, encodings and
things of that ilk. So yes, it probably should complain about what I set
lc_monetary to in this case.

Thom