> On 1 Feb 2018, at 12:36, Yann Ylavic <[email protected]> wrote: > > Hi Mark, > > On Thu, Feb 1, 2018 at 10:29 AM, Mark Blackman <[email protected]> wrote:> >> >> >> Just to confirm, you expect that patch to handle SHM clean-up even in >> the “nasty error” case? > > Not really, no patch can avoid a crash for a crashing code :/ > The "stop_signals-PR61558.patch" patch avoids a known httpd crash in > some circumstances, but...
Well, I just mean, if sig_coredump gets called, will the patch result in the normal SHM clean-up routines getting called, where they would have not been called before? SHM clean-up is the key here and any patch that doesn’t contribute to that has no immediate value for me. > >> I suspect that nasty error is triggered by >> the Weblogic plugin based on the adjacency in the logs, but the >> tracing doesn’t reveal any details, so an strace will probably be >> required to get more detail. Tracing has confirmed this really is a segmentation fault despite the lack of host-level messages and that reading a 3rd party module (but not Weblogic) is the last thing that happens before the segmentation fault and that pattern is fairly consistent. Now we need to ensure coredumps are generated. Finally, there are no orphaned child httpd processes with a PPID of 1. Just thousands and thousands of SHM segments with no processes attached to them. Regards, Mark
