Re: [BUG] Re-entering malloc problem when use --enable-nls buildpostgresql - Mailing list pgsql-bugs

From 158306855
Subject Re: [BUG] Re-entering malloc problem when use --enable-nls buildpostgresql
Date
Msg-id tencent_2AAD47AF23BFB3C7136D4D7A7EA751BDBB05@qq.com
Whole thread Raw
In response to Re: [BUG] Re-entering malloc problem when use --enable-nls buildpostgresql  (Andres Freund <andres@anarazel.de>)
Responses Re: [BUG] Re-entering malloc problem when use --enable-nlsbuildpostgresql
List pgsql-bugs
It'd be fairly unproblematic to write an untranslated message out. There
we can make sure to either only use plain syscalls or use memory from
the preallocated context.  I think it'd be ok to not to translate in
that situation.

I wrote a patch to improve this problem.



zeng wenjing

------------------ Original ------------------
From:  "Andres Freund"<andres@anarazel.de>;
Date:  Tue, May 8, 2018 01:57 PM
To:  "Tom Lane"<tgl@sss.pgh.pa.us>;
Cc:  "158306855"<anderson2013@qq.com>; "pgsql-bugs"<pgsql-bugs@lists.postgresql.org>;
Subject:  Re: [BUG] Re-entering malloc problem when use --enable-nls buildpostgresql

On 2018-05-08 01:32:33 -0400, Tom Lane wrote:
> "158306855" <anderson2013@qq.com> writes:
> > I found that compiling postgresql with enable-nls may be introduce a problem
>
> > 1. When build postgresql with enable-nls (Native Language Support), postgresql use dgettext function to translate Language.
> > 2. The quickdie use dgettext translate message ; dgettext use malloc (in __dcigettext  function)
> > 3. When use pg_ctl -m fast to shutdown postgresql, pg backend process use function quickdie to shutdown database.
> > 4. Before receive quickdie signal, if backend process in malloc function and already have lock that will lead to process deadlock.

I don't think it's realistic to treat this is something we'll
necessarily backpatch. Any fix is going to be too complicated.


> I can't get excited about this.  quickdie's attempt to report that it's
> killing the process is necessarily a "best effort" undertaking, because
> we cannot be sure that the process is in a good state.  In this situation,
> it isn't.  --enable-nls might make the odds of that a bit worse, but we
> could get such a failure regardless.

As previously, I disagree with this. There's plenty ways to reach
quickdie, several where we are quite sure about the state. -m immediate
is a thing, and there's plenty situations where it's an entirely
reasonable choice.


> There are not any better alternatives.  We can't just set a flag in the
> signal handler and hope that control will someday reach a place that
> notices the flag.  We could exit without attempting to report anything,
> but nobody would find that user-friendly.  So we try to report, in the
> full understanding that sometimes it won't work.

It'd be fairly unproblematic to write an untranslated message out. There
we can make sure to either only use plain syscalls or use memory from
the preallocated context.  I think it'd be ok to not to translate in
that situation.

We should also use _exit or the like when exiting quickly, calling exit
handlers from a signal handlers is a bad bad idea.

Greetings,

Andres Freund
Attachment

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #15080: ecpg on windows doesn't define HAVE_LONG_LONG_INT
Next
From: Euler Taveira
Date:
Subject: crash while decoding INSERT ON CONFLICT