|Summary:||2.4.12 segmentation fault when accessing host on Listen port that doesn't have defined virtual host block|
|Product:||Apache httpd-2||Reporter:||Kurt Newman <kurt.newman>|
|Component:||All||Assignee:||Apache HTTPD Bugs Mailing List <bugs>|
GDB stack trace
Description Kurt Newman 2015-02-03 21:17:58 UTC
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.
Comment 3 Brian Behlendorf 2015-03-04 19:00:40 UTC
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...
Comment 4 Brian Behlendorf 2015-03-04 22:00:40 UTC
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
Comment 5 Kurt Newman 2015-03-04 22:09:07 UTC
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.
Comment 6 Eric Covener 2015-03-04 22:55:54 UTC
Sorry, this is a recent regression that will be fixed shortly in trunk
Comment 7 Jan Ludewig 2015-03-05 01:08:41 UTC
(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.
Comment 8 Eric Covener 2015-03-05 02:36:39 UTC
fixed in trunk and proposed for backport, sorry for the delay. http://svn.apache.org/r1664205
Comment 9 Kurt Newman 2015-03-05 18:16:29 UTC
Awesome. Thank you Eric!