Hi, On 2021-10-02 12:59:09 -0700, Andres Freund wrote: > On 2021-10-02 11:05:20 -0400, Tom Lane wrote: > > I don't know enough about Windows to evaluate 0001, but I'm a little > > worried about it because it looks like it's changing our *production* > > error handling on that platform. > > Yea. It's clearly not ready as-is - it's the piece that I was planning to > write a separate email about.
> > It's hard to understand what *precisely* SEM_NOGPFAULTERRORBOX etc do. > > What I do know is that without the _set_abort_behavior() stuff abort() doesn't > trigger windows' "crash" paths in at least debugging builds, and that the > SetErrorMode() and _CrtSetReportMode() changes are necessary to get segfaults > to reach the crash paths. > > The in-tree behaviour turns out to make debugging on windows a major pain, at > least when compiling with msvc. Crashes never trigger core dumps or "just in > time" debugging (their term for invoking a debugger upon crash), so one has to > attach to processes before they crash, to have any chance of debugging. > > As far as I can tell this also means that at least for debugging builds, > pgwin32_install_crashdump_handler() is pretty much dead weight - > crashDumpHandler() never gets invoked. I think it may get invoked for abort()s > in production builds, but probably not for segfaults. > > And despite SEM_NOGPFAULTERRORBOX we display those annoying "popup" boxes > telling us about the crash and giving the option to retry, ignore, something > something. It's all a bit baffling. FWIW, the latest version of this patch (including an explanation why SEM_NOGPFAULTERRORBOX isn't useful for our purposes [anymore]) is at (and above) https://postgr.es/m/20220110005704.es4el6i2nxlxzwof%40alap3.anarazel.de Greetings, Andres Freund
