PQclientEncoding() returns -1, resulting in possible assertion failure in psql
От | Peter Geoghegan |
---|---|
Тема | PQclientEncoding() returns -1, resulting in possible assertion failure in psql |
Дата | |
Msg-id | CAM3SWZSU2XSb0cKDreoQnMSge7xN5q32XNC3LE0wfuke-V9BRQ@mail.gmail.com обсуждение исходный текст |
Ответы |
Re: PQclientEncoding() returns -1, resulting in possible assertion failure in psql
(Tom Lane <tgl@sss.pgh.pa.us>)
|
Список | pgsql-bugs |
It's possible to get psql to abort() in an assertion failure from legitimate input. If the server is shutdown, and PQclientEncoding() returns -1, that value can be passed to a site that expects a valid encoding. If the call to PQclientEncoding() from processSQLNamePattern() (plus probably from other places) gets an encoding of -1, (called when we "\df+ somefunc" after the server is gone - you may have to do it twice), that can be passed down to PQmblen(), which will in turn pass that value to pg_encoding_mblen(), which doesn't expect it. Here is a backtrace from GDB: #0 0x00007f0d4a3ba037 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x00007f0d4a3bd698 in __GI_abort () at abort.c:90 #2 0x00007f0d4a3b2e03 in __assert_fail_base (fmt=0x7f0d4a50a158 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x7f0d4ac17de8 "((encoding) >= 0 && (encoding) < _PG_LAST_ENCODING_)", file=file@entry=0x7f0d4ac17de0 "wchar.c", line=line@entry=1781, function=function@entry=0x7f0d4ac17e80 <__PRETTY_FUNCTION__.5143> "pg_encoding_mblen") at assert.c:92 #3 0x00007f0d4a3b2eb2 in __GI___assert_fail (assertion=0x7f0d4ac17de8 "((encoding) >= 0 && (encoding) < _PG_LAST_ENCODING_)", file=0x7f0d4ac17de0 "wchar.c", line=1781, function=0x7f0d4ac17e80 <__PRETTY_FUNCTION__.5143> "pg_encoding_mblen") at assert.c:101 #4 0x00007f0d4ac13b77 in pg_encoding_mblen (encoding=-1, mbstr=0xd05d00 "pg_stat_statements") at wchar.c:1781 #5 0x00007f0d4ac01f48 in PQmblen (s=0xd05d00 "pg_stat_statements", encoding=-1) at fe-misc.c:1143 #6 0x0000000000433ef3 in processSQLNamePattern (conn=0x0, buf=0x7ffff15dd560, pattern=0xd05d00 "pg_stat_statements", have_where=0 '\000', force_escape=0 '\000', schemavar=0x44cec1 "n.nspname", namevar=0x44cef9 "p.proname", altnamevar=0x0, visibilityrule=0x44ced0 "pg_catalog.pg_function_is_visible(p.oid)") at dumputils.c:1098 #7 0x000000000041e139 in describeFunctions (functypes=0xd036d2 "+", pattern=0xd05d00 "pg_stat_statements", verbose=1 '\001', showSystem=0 '\000') at describe.c:441 #8 0x0000000000404830 in exec_command (cmd=0xd036d0 "df+", scan_state=0xcf5550, query_buf=0xcf56c0) at command.c:389 #9 0x0000000000403f7a in HandleSlashCmds (scan_state=0xcf5550, query_buf=0xcf56c0) at command.c:111 #10 0x000000000040ec66 in MainLoop (source=0x7f0d4a746360 <_IO_2_1_stdin_>) at mainloop.c:301 #11 0x0000000000414b86 in main (argc=1, argv=0x7ffff15ddaf8) at startup.c:329 It's not immediately obvious what the best fix here is - I have some ideas, but they all seem pretty invasive. I think it's a bug that processSQLNamePattern() trusts PQclientEncoding() to return a sane encodingid. Numerous points in dumputils similarly expect this. The assertion failure isn't spurious, because the encodingid will subscript an array in pg_encoding_mblen(), which is undefined here. -- Peter Geoghegan
В списке pgsql-bugs по дате отправления: