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

"Ibrar Ahmed" <ibrar.ahmad@gmail.com> 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

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 <tgl@sss.pgh.pa.us> wrote:

"Ibrar Ahmed" <ibrar.ahmad@gmail.com> 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

"Ibrar Ahmed" <ibrar.ahmad@gmail.com> 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

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

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 Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Alvaro Herrera <alvherre@commandprompt.com> 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