Re: [bug fix] Produce a crash dump before main() on Windows

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: [bug fix] Produce a crash dump before main() on Windows
Дата
Msg-id CABUevEygrBekXds=ngZDaGvL4OTkqNZVrCqOQ882A+qPbtkuAQ@mail.gmail.com
обсуждение исходный текст
Ответ на [bug fix] Produce a crash dump before main() on Windows  ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>)
Ответы Re: [bug fix] Produce a crash dump before main() on Windows
Список pgsql-hackers


On Fri, Feb 16, 2018 at 8:28 AM, Tsunakawa, Takayuki <tsunakawa.takay@jp.fujitsu.com> wrote:
Hello,

postgres.exe on Windows doesn't output a crash dump when it crashes before main() is called.  The attached patch fixes this.  I'd like this to be back-patched.  I'll add this to the next CF.

The original problem happened on our customer's production system.  Their application sometimes failed to connect to the database.  That was because postgres.exe crashed due to access violation (exception code C0000005).  But there was no crash dump, so we had difficulty in finding the cause.  The frequency was low -- about ten times during half a year.

What caused the access violation was Symantec's antivirus software.  It seems that sysfer.dll of the software intercepts registry access, during C runtime library initialization,  before main() is called.  So, the direct cause of this problem is not PostgreSQL.

On the other hand, it's PostgreSQL's problem that we can't get the crash dump, which makes the investigation difficult.  The cause is that postmaster calls SetErrorMode() to disable the outputing of crash dumps by WER (Windows Error Reporting).  This error mode is inherited from postmaster to its children.  If a crash happens before the child sets up the exception handler, no crash dump is produced.

The original call to SetErrorMode() was put in there to make sure we didn't show a popup message which would then make everything freeze (see very old commit 27bff7502f04ee01237ed3f5a997748ae43d3a81). Doesn't this turn that back on, so that if you are not actually there to monitor something you can end up with stuck processes and exactly the issues we had before that one?

It might still be useful in debugging, but in that case we might need to make it a configurable switch?

--

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: Contention preventing locking
Следующее
От: Peter Eisentraut
Дата:
Сообщение: committing inside cursor loop