On Thu, May 14, 2020 at 02:38:09PM -0400, Wietse Venema wrote: > Viktor Dukhovni: > > Alternatively, we could siglongjmp() out of a segfault handler, enabled > > around PCRE lookups, leaking whatever heap space libpcre may have > > allocated along the way, and log a more informative message, and thereby > > perhaps even avoid occasional service throttling in master that may happen > > if the service is killed by a signal. Just a thought... > > After SIGSEGV the only sensible thing a process can do is to > terminate, because the state of memory is undefined.
Yes, that's generally the case. > Are you assuming that you can know exactly why SIGSEGV is received? > I don't think so. We have to assume the worst, namely, that a process > has corrupted it memory. I am that it might not be too crazy to enable unwinding on SIGSEGV just around pcre match calls, on the assumption that libpcre only segfauls on stack exhaustion. But then, in any case, we could only log something about overly complex patterns and _exit(0). However, "log something" is not async-signal-safe. So if the stack exhaustion happened not in libpcre itself, but rather in an internal call in malloc() or similar, then we may not be able to perform any memory allocation, so the logging before exit would require considerable care to use static buffers and just async-signal-safe system calls. This would be quite a pain. Therefore, my preference would be to attempt to configure resource bounds for libpcre that should keep it out of trouble, perhaps at the cost of failing on some patterns for which enough stack would in fact have been available. -- Viktor.