On Thu, Jan 16, 2025 at 8:47 AM Nathan Bossart <nathandboss...@gmail.com> wrote: > On Thu, Jan 16, 2025 at 08:21:08AM +1300, Thomas Munro wrote: > > Could be due to calling native signal() with a signal number other > > than the 6 values required to work by the C standard? > > Looking closer, that probably makes more sense than my SIG_ERR redefinition > theory. If that assertion is getting hit, that means signal() _is_ > returning SIG_ERR (either the system one or our redefined version), and it > looks like it's pretty common to use -1 for SIG_ERR. That'd only affect > Windows frontend programs, but it still sounds scary. I'll try getting > more details about the error with some custom cfbot runs.
Windows barely has signals, so I don't think it's too scary... SIGINT works but surprisingly runs the handler in another thread when you press ^C, SIGABRT, SIGFPE, SIGSEGV presumably have the obvious synchronous/exception-trapping implementations but we aren't even trying to catch those*, and SIGTERM, SIGILL are pro forma, never generated by the system. We've basically just invented more pro forma ones that will also never be generated except in the backend's entirely separate fake signal system that I hope to remove. +1 for your idea of not defining them at all outside the backend, it's just confusing noise. The second surprising thing, unless you're an armchair Unix archeologist, is that all but SIGFPE revert to SIG_DFL when they fire, like POSIX's SA_RESETHAND mode. I don't know if it also has SA_NODEFER behaviour (a combination of behaviours seen in some old Unixen of yestermillennium: your handler had to keep reinstalling itself, cf initdb.c:trapsig, but for a brief window the default process-terminating-core-dumping-nasal-daemon behaviour was installed and there was nothing you could do about that race; the BSD crew fixed that mistake a long time ago, everyone does it that way now, and POSIX sigaction() made those policies explicit and is the recommended replacement, but to this day the C standard has just signal() with undefined semantics and no requirement that any of it even work). *Even in the backend we don't catch Windows' native SIGFPE AFAICS, so I guess those must exit instead of being converted to an ERROR by FloatExceptionHandler. I wonder if there is a way to reach that condition from a SQL query.
