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.

Reply via email to