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

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [bug fix] Produce a crash dump before main() on Windows
Date: 2018-02-20 13:47:25
Message-ID: CABUevEygrBekXds=ngZDaGvL4OTkqNZVrCqOQ882A+qPbtkuAQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Feb 16, 2018 at 8:28 AM, Tsunakawa, Takayuki <
tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)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?

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2018-02-20 14:11:50 committing inside cursor loop
Previous Message Simon Riggs 2018-02-20 13:42:31 Re: Contention preventing locking