Re: [HACKERS] [bug fix] postgres.exe crashes with access violation onWindows while starting up
От
Michael Paquier
Тема
Re: [HACKERS] [bug fix] postgres.exe crashes with access violation onWindows while starting up
Дата
Msg-id
CAB7nPqTvKj_jj_zEJtRXhA2M3LLpzR29X0EU81R_EiW25zu2LQ@mail.gmail.com
Ответ на
[HACKERS] [bug fix] postgres.exe crashes with access violation on Windowswhile starting up (Tsunakawa, Takayuki)
Список
Дерево обсуждения
[HACKERS] [bug fix] postgres.exe crashes with access violation on Windowswhile starting up "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>
[HACKERS] Re: [bug fix] postgres.exe crashes with access violation on Windowswhile starting up "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>
Re: [HACKERS] [bug fix] postgres.exe crashes with access violation onWindows while starting up Michael Paquier <michael.paquier@gmail.com>
Re: [HACKERS] [bug fix] postgres.exe crashes with access violationon Windows while starting up "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>
Re: [HACKERS] [bug fix] postgres.exe crashes with access violation onWindows while starting up Michael Paquier <michael.paquier@gmail.com>
Re: [HACKERS] [bug fix] postgres.exe crashes with access violationon Windows while starting up "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>
Re: [HACKERS] [bug fix] postgres.exe crashes with access violation onWindows while starting up Michael Paquier <michael.paquier@gmail.com>
Re: [HACKERS] [bug fix] postgres.exe crashes with access violationon Windows while starting up Noah Misch <noah@leadboat.com>
Re: [HACKERS] [bug fix] postgres.exe crashes with access violation onWindows while starting up Michael Paquier <michael.paquier@gmail.com>
On Thu, Oct 26, 2017 at 7:10 PM, Tsunakawa, Takayuki
wrote:
> FIX
> ==============================
>
> Add the check "CurrentMemoryContext != NULL" in write_eventlog() as in write_console().
* Also verify that we are not on our way into error recursion
trouble due * to error messages thrown deep inside pgwin32_message_to_UTF16(). */ if (!in_error_recursion_trouble() &&
+ CurrentMemoryContext != NULL && GetMessageEncoding() != GetACPEncoding()) {
So you are basically ready to lose any message that could be pushed
here if there is no memory context? That does not sound like a good
trade-off to me. A static buffer does not look like the best idea
either to not truncate message, so couldn't we envisage to just use
malloc? pgwin32_message_to_UTF16() is called in two places in elog.c,
and there is a full control on the error code paths.
> NOTE
> ==============================
>
> The reason is for not outputing the crash dump is a) the crash occurred before installing the Windows exception handler (pgwin32_install_crashdump_handler() call) and b) the effect of the following call in postmaster is inherited in the child process.
>
> /* In case of general protection fault, don't show GUI popup box */
> SetErrorMode(SEM_FAILCRITICALERRORS | SEM_NOGPFAULTERRORBOX);
>
> But I'm not sure in what order we should do pgwin32_install_crashdump_handler(), startup_hacks() and steps therein, MemoryContextInit(). I think that's another patch.
Perhaps. I don't have a final opinion on this matter.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
В списке pgsql-hackers по дате отправления
От: Alexander Korotkov
Дата: