Re: Server crash with certain encodings

Поиск
Список
Период
Сортировка
От Thom Brown
Тема Re: Server crash with certain encodings
Дата
Msg-id CAA-aLv6eKojquBd2y9muZ-uXP3dxH3M7sVcx-qADyNLgV+odtw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Server crash with certain encodings  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-bugs
On 29 February 2016 at 03:31, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Thom Brown <thom@linux.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@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@entry=2,
fmt=fmt@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@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

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Server crash with certain encodings
Следующее
От: Dean Rasheed
Дата:
Сообщение: Re: BUG #13988: "plan should not reference subplan's variable" whilst using row level security