Created attachment 32428 [details] GDB stack trace Basic setup instructions: Set up shtml ErrorDocument definitions (and corresponding Handler), setup Listen directive for multiple ports, and create a virtual host block. Background: 2.4.10 would handle this correctly, but now causes children (when in prefork mode) for 2.4.12 to segfaults. Testing setup: 2.4.10 without patches 2.4.12 without patches I've attached two basic configuration files that duplicate this succinctly, as well as a stack trace.
Created attachment 32429 [details] httpd.conf
Created attachment 32430 [details] errordocument.conf
I am hitting this too, oddly also with the same specific error, 400 Bad Gateway, with the default config file thus pulling in HTTP_BAD_GATEWAY.html.var. I wonder if it's related to this snippet from: https://httpd.apache.org/docs/2.4/upgrading.html#misc "Multi-language error documents from 2.2.x may not work unless they are adjusted to the new syntax of mod_include's #if expr= element or the directive SSILegacyExprParser is enabled for the directory containing the error documents." Is your "400.html" the same file as the stock HTTP_BAD_GATEWAY.html.var? I tried to see if there was any particular error in HTTP_BAD_GATEWAY.html.var relating to the #if expr= syntax and didn't find anything obvious. Nor could I reproduce the error with my hand-cobbled HTTP requests designed to trigger 400 responses, but I do get them in production, so realistic traffic can trigger it. However, when I change my config to eliminate ONLY the following line from my extra/httpd-multilang-errordoc.conf: #ErrorDocument 400 /error/HTTP_BAD_REQUEST.html.var that stopped all my core dumps, so it strongly suggests either a bug in that error message's server-parsed HTML (which still shouldn't trigger a core dump!!) or an error while processing a bad HTTP request that makes setting up the CGI environment variables fail spectacularly. Hoping this can get some attention from folks who'd know...
More details: A friend (jl) noted: > A quick glance at the code suggested that the request method is > not set up in the request object and in the function mentioned in the > stacktrace this leads to strcmp(NULL, "INCLUDED") -> segfault. So I went about looking for odd-looking requests that might have no method set, and found (IP address anonymized): x.x.x.x - - [04/Mar/2015:13:36:01 -0800] "\x16\x03\x03" 400 326 "-" "-" Posts online suggested this was an SSL client attempting to talk SSL to port 80. And in fact, I could reproduce this by trying to go to https://host:80/ to the point where I could even generate a core, which I couldn't do before. Anyways, looks like before that strcmp is called the request method should be tested for, or set. Brian
The way that I was able to re-produce this, was by Listening on 2 ports (80 and 443), accessing port 443, but for a virtual host that isn't defined on that port.
Sorry, this is a recent regression that will be fixed shortly in trunk
(In reply to Eric Covener from comment #6) > Sorry, this is a recent regression that will be fixed shortly in trunk Looks like you already found the problem? still, minor correction: the "request method" I mentioned to brian (see comment #4) was actually "r->protocol in ap_add_cgi_vars, in server/util_script.c. My bad, I had written from memory, not checked the actual source again. Also, I'm looking at revision 1661207, not the released version.
fixed in trunk and proposed for backport, sorry for the delay. http://svn.apache.org/r1664205
Awesome. Thank you Eric!
Backported to 2.4.13 in r1668879.
And to 2.2.30 in r1680927.