ERRORDATA_STACK_SIZE panic crashes on Windows

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: ERRORDATA_STACK_SIZE panic crashes on Windows
Date: 2008-05-18 20:32:37
Message-ID: 8077.1211142757@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Have any Windows-using hackers tried to look into the reports of
$SUBJECT on 8.3? We have two fresh reports:
http://archives.postgresql.org/pgsql-bugs/2008-05/msg00106.php
http://archives.postgresql.org/pgsql-bugs/2008-05/msg00109.php
and this isn't the first time we've heard of it.

I spent some time chasing the theory that the conversion from
UTF8 to the client encoding was failing; but if that's the case
it should be reproducible on non-Windows machines, and I didn't
have any luck with that.

What I'm currently thinking is that maybe gettext() isn't on the
same page as us concerning what encoding it's supposed to produce
its output in. This is reinforced by the mention of changing
lc_messages in the first report above. We had had some discussions
of trying to adjust the LC_XXX values to ensure that they all
represent the same encoding choice, but I don't believe that got done.
It might also be significant that both complainants are using UTF8
database encoding; IIRC that has some weird status in the Windows
locale world.

I am also toying with the idea of disabling gettext usage once we
get past two or so levels of error nesting, in order to prevent the
recursion panic in this type of scenario --- but it would be real
nice to know for certain what is happening before we try to fix it.

regards, tom lane

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Lor 2008-05-18 20:41:14 Re: New DTrace probes proposal
Previous Message Andrew Dunstan 2008-05-18 20:09:40 Re: notification information functions