Re: [HACKERS] ERRORDATA_STACK_SIZE exceeded (server crash)
Alvaro Herrera <[EMAIL PROTECTED]> writes: > Tom Lane escribió: >> It might be better to modify elog.c so that errmsg_internal really >> doesn't call gettext. This would require kluging up EVALUATE_MESSAGE() >> a bit, so I'm not quite sure which is cleaner. Thoughts? > I think we document somewhere that a translator can add errmsg_internal to the > list of gettext triggers in nls.mk, so I agree that we should making sure it > doesn't call gettext at all, just to be sure some overly zealous translator > gets past the barrier. Yeah, I agree --- will do it that way. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ERRORDATA_STACK_SIZE exceeded (server crash)
Tom Lane escribió: > It might be better to modify elog.c so that errmsg_internal really > doesn't call gettext. This would require kluging up EVALUATE_MESSAGE() > a bit, so I'm not quite sure which is cleaner. Thoughts? I think we document somewhere that a translator can add errmsg_internal to the list of gettext triggers in nls.mk, so I agree that we should making sure it doesn't call gettext at all, just to be sure some overly zealous translator gets past the barrier. (Also, actually adding errmsg_internal is pretty pointless, because the translated messages would be lost when the catalog is passed through our new translation status web system). -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ERRORDATA_STACK_SIZE exceeded (server crash)
I wrote: > This is still not very nice because what the user would get is > a complaint about ERRORDATA_STACK_SIZE exceeded with no hint that > he's got an encoding problem. It'd be better if we could get the > disable-gettext-and-FATAL-out behavior to apply to the "character > has no equivalent" error message, but I'm not sure how we do that > without bollixing up less-critical occurrences of that message. After poking around a bit I decided that this could be done in a not horrendously ugly way if we are willing to make a couple more places know about escaping from error recursion situations. Attached is a proposed patch that prevents the crash shown previously. BTW, a better stress test for this is to set LANG = tr_TR.utf8, client_encoding = latin1, and then try "select E'\305\237';". That's because the "character has no equivalent" message isn't itself translated in the present ko translation, but it is in the tr translation. My first-cut patch worked for the ko case and not the tr case :-( One thing that is still a bit ugly about this patch is the hack in wchar.c to ensure that the "character has no equivalent" message doesn't get translated: * ... Note that we have to * spell the message slightly differently, which we do by sticking a * space on the end --- using errmsg_internal() doesn't actually keep * elog.c from calling gettext, it only prevents the string from being * entered into the translation lists. It might be better to modify elog.c so that errmsg_internal really doesn't call gettext. This would require kluging up EVALUATE_MESSAGE() a bit, so I'm not quite sure which is cleaner. Thoughts? regards, tom lane Index: src/backend/utils/error/elog.c === RCS file: /cvsroot/pgsql/src/backend/utils/error/elog.c,v retrieving revision 1.208 diff -c -r1.208 elog.c *** src/backend/utils/error/elog.c 17 Oct 2008 22:56:16 - 1.208 --- src/backend/utils/error/elog.c 27 Oct 2008 16:16:28 - *** *** 149,154 --- 149,169 static void setup_formatted_log_time(void); static void setup_formatted_start_time(void); + + /* + * in_error_recursion_trouble --- are we at risk of infinite error recursion? + * + * This function exists to provide common control of various fallback steps + * that we take if we think we are facing infinite error recursion. See the + * callers for details. + */ + bool + in_error_recursion_trouble(void) + { + /* Pull the plug if recurse more than once */ + return (recursion_depth > 2); + } + /* * errstart --- begin an error-reporting cycle * *** *** 261,272 MemoryContextReset(ErrorContext); /* !* If we recurse more than once, the problem might be something broken * in a context traceback routine. Abandon them too. We also abandon * attempting to print the error statement (which, if long, could * itself be the source of the recursive failure). */ ! if (recursion_depth > 2) { error_context_stack = NULL; debug_query_string = NULL; --- 276,287 MemoryContextReset(ErrorContext); /* !* Infinite error recursion might be due to something broken * in a context traceback routine. Abandon them too. We also abandon * attempting to print the error statement (which, if long, could * itself be the source of the recursive failure). */ ! if (in_error_recursion_trouble()) { error_context_stack = NULL; debug_query_string = NULL; *** *** 2408,2413 --- 2423,2432 /* * error_severity --- get localized string representing elevel + * + * Note: in an error recursion situation, we stop localizing the tags + * for ERROR and above. This is necessary because the problem might be + * failure to convert one of these strings to the client encoding. */ static const char * error_severity(int elevel) *** *** 2437,2449 prefix = _("WARNING"); break; case ERROR: ! prefix = _("ERROR"); break; case FATAL: ! prefix = _("FATAL"); break; case PANIC: ! prefix = _("PANIC"); break; default: prefix = "???"; --- 2456,2477 prefix = _("WARNING"); break; case ERROR: ! if (in_error_recursion_trouble()) !
Re: [HACKERS] ERRORDATA_STACK_SIZE exceeded (server crash)
"Ibrar Ahmed" <[EMAIL PROTECTED]> writes: > 1 - export LANG=ko_KR.UTF-8 Hmph ... I can reproduce that on Fedora 9. It seems the problem is that that translation is full of characters that don't exist in EUC-JP; in particular the translations of both "ERROR" and "PANIC" contain untranslatable characters. This means that every time we go to send a message to the client, we get a recursive error trap. The "ERRORDATA_STACK_SIZE exceeded" message is intentionally not exposed to gettext translation, in hopes of stopping this problem, but that doesn't help much when the PANIC message is exposed :-(. So one thing we might try to do about it is to intentionally not allow translation of PANIC (at line 2446 of elog.c). However, that only gets us down from a stack-overflow crash to a PANIC, which is just about as bad from a reliability standpoint. I think the only permanent solution to this class of problem is going to be something like this: * When we hit the stack depth overflow PANIC situation in elog.c, disable gettext so that the error will always be reported in ASCII. * Reduce the PANIC to a FATAL so that misconfiguration of this sort just kills the one session and doesn't cause a database crash. This is still not very nice because what the user would get is a complaint about ERRORDATA_STACK_SIZE exceeded with no hint that he's got an encoding problem. It'd be better if we could get the disable-gettext-and-FATAL-out behavior to apply to the "character has no equivalent" error message, but I'm not sure how we do that without bollixing up less-critical occurrences of that message. Thoughts? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ERRORDATA_STACK_SIZE exceeded (server crash)
Sure! CODE -- /configure --enable-nls --enable-depend --enable-debug make make install SERVER SIDE - 1 - export LANG=ko_KR.UTF-8 2 - ./initdb -E UTF8 -D ../data 3 - ./postmaster -D ../data CLIENT SIDE --- 1 - export LANG=ko_KR.UTF-8 2 - psql postgres postgres=# show server_encoding; server_encoding - UTF8 (1건 있음) postgres=# show client_encoding; client_encoding - UTF8 (1건 있음) postgres=# set client_encoding ='euc-jp';--[<<<--Negative test scenario] SET postgres=# x; On Mon, Oct 27, 2008 at 6:42 PM, Tom Lane <[EMAIL PROTECTED]> wrote: > "Ibrar Ahmed" <[EMAIL PROTECTED]> writes: >> I have encountered a server crash while working with different locale >> settings. > > Are you going to give us a hint what settings those would be? > >regards, tom lane > -- Ibrar Ahmed EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ERRORDATA_STACK_SIZE exceeded (server crash)
"Ibrar Ahmed" <[EMAIL PROTECTED]> writes: > I have encountered a server crash while working with different locale > settings. Are you going to give us a hint what settings those would be? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ERRORDATA_STACK_SIZE exceeded (server crash)
Ibrar Ahmed wrote: > I have encountered a server crash while working with different locale > settings. After searching on the internet I have seen a similar issue > with 8.3.1 release and Tom has fixed that issue. That bug was only in > Windows but I am getting same server crash on Linux, although I am > using a later release with the patch applied. > > Here is the link of previous bug > > http://archives.postgresql.org/pgsql-committers/2008-05/msg00349.php > > OS = ubuntu > PG Version = psql (8.4devel) > > > postgres=# show server_encoding; > server_encoding > - > UTF8 > (1건 있음) > > postgres=# show client_encoding; > client_encoding > - > UTF8 > (1건 있음) > > postgres=# set client_encoding ='euc-jp'; > SET > postgres=# x; > 서버가 갑자기 연결을 닫았음 > 이런 처리는 클라이언트의 요구를 처리하는 동안이나 > 처리하기 전에 서버가 갑자기 종료되었음을 의미함 > 서버로부터 연결이 끊어졌습니다. 다시 연결을 시도합니다: 실패. > !> Do you have core dump, stack trace or any other details? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers