Core will be vomited if the Web page to which Apache2.0.48 is working is perused by IE or Netscape. However, if it is performed as follows, a Web page can be seen for the time being. $ telnet server 80 Trying 123.456.789.012 Connected to server. Escape character is '^]'. GET / <!doctype html public "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd"> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=ISO-2022-JP"> <title>Apache install-ji no test page</title> ^^ in japanese title ...more The test page of Apache also vomits core. In a httpd-2.0.47, it did not this problem. [Fri Nov 07 09:34:19 2003] [notice] Apache/2.0.48 (Unix) configured -- resuming normal operations [Fri Nov 07 09:34:19 2003] [info] Server built: Nov 7 2003 09:13:42 [Fri Nov 07 09:34:19 2003] [debug] prefork.c(1037): AcceptMutex: flock (default: flock) [Fri Nov 07 09:34:30 2003] [notice] child pid 13178 exit signal Segmentation fau lt (11) [Fri Nov 07 09:34:30 2003] [notice] child pid 13177 exit signal Segmentation fau lt (11) The environment here is as follows. The kernel and library of FreeBSD 4.9-RELEASE are using custom-made. (Compile option : -O3 -mcpu=k6 -march=k6 -malign-functions=4 -malign-jumps=4 - malign-loops=4) httpd.conf is adjusted so that Japanese may be indicated by priority. The virtual host of IP base and the virtual host of a NOIP base are intermingled. The build script of Apache is as follows. #!/bin/sh OPTIM="-D_REENTRANT -D_THREAD_SAFE -O9 -mcpu=k6 -march=k6 -malign-loops=4 -malig n-jumps=4 -malign-functions=4" COPTFLAGS="$OPTIM" \ CFLAGS="$OPTIM" \ CC="cc $CFLAGS" \ ./configure --with-port=80 \ --enable-mods-shared=info --enable-info \ --enable-mods-shared=status --enable-status \ --enable-mods-shared=imap --enable-imap \ --enable-so \ --enable-rewrite \ --enable-deflate \ --enable-expires \ --enable-headers \ --enable-usertrack CC="cc" \ OPTIM="$OPTIM" \ CFLAGS="$CFLAGS" \ COPTFLAGS="$COPTFLAGS" \ make #make install
This problem is mod_usertrack. Enable this option is dump core!! CookieTracking on
Well, we did change mod_usertrack in this version... but in all our testing it worked for us. Can you please give us a backtrace so that we can try to figure out what's going on? See http://httpd.apache.org/dev/debugging.html . Thanks, Cliff
backtrace report on spot_cookie(mod_usertrack.c) Breakpoint 3, spot_cookie (r=0x8188050) at mod_usertrack.c:204 204 cookie_dir_rec *dcfg = ap_get_module_config(r->per_dir_config, (gdb) n 210 if (!dcfg->enabled || r->main) { (gdb) 214 if ((cookie_header = apr_table_get(r->headers_in, (gdb) 218 if (!ap_regexec(dcfg->regexp, cookie_header, NUM_SUBS, regm, 0)) { (gdb) Program received signal SIGSEGV, Segmentation fault. 0x080a495b in regexec (preg=0x0, string=0x8189040 "Apache=hostname.or.jp.1067634189379628; sheet=%u901A% u5E38%u30D5%u30A9%u30F3%u30C8; abcdefgh.html=11", nmatch=3, pmatch=0xbfbff940, eflags=0) at pcreposix.c:269 269 rc = pcre_exec(preg->re_pcre, NULL, string, (int)strlen(string), 0, options, ------- Breakpoint 3, spot_cookie (r=0x8188050) at mod_usertrack.c:204 204 cookie_dir_rec *dcfg = ap_get_module_config(r->per_dir_config, (gdb) s 210 if (!dcfg->enabled || r->main) { (gdb) s 214 if ((cookie_header = apr_table_get(r->headers_in, (gdb) s apr_table_get (t=0x8188218, key=0x80d051c "Cookie") at apr_tables.c:481 481 if (key == NULL) { (gdb) s 485 hash = TABLE_HASH(key); (gdb) s 486 if (!TABLE_INDEX_IS_INITIALIZED(t, hash)) { (gdb) s 489 COMPUTE_KEY_CHECKSUM(key, checksum); (gdb) s 490 next_elt = ((apr_table_entry_t *) t->a.elts) + t->index_first[hash]; ; (gdb) s 491 end_elt = ((apr_table_entry_t *) t->a.elts) + t->index_last[hash]; (gdb) s 493 for (; next_elt <= end_elt; next_elt++) { (gdb) s 494 if ((checksum == next_elt->key_checksum) && (gdb) s 493 for (; next_elt <= end_elt; next_elt++) { (gdb) s 494 if ((checksum == next_elt->key_checksum) && (gdb) s 496 return next_elt->val; (gdb) s 501 } (gdb) s spot_cookie (r=0x8188050) at mod_usertrack.c:218 218 if (!ap_regexec(dcfg->regexp, cookie_header, NUM_SUBS, regm, 0)) { (gdb) s ap_regexec (preg=0x0, string=0x8189040 "Apache=hostname.or.jp.1067634189379628; sheet=% u901A%u5E38%u30D5%u30A9%u30F3%u30C8; abcdefgh.html=11", nmatch=3, pmatch=0xbfbff940, eflags=0) at util.c:398 398 return regexec(preg, string, nmatch, pmatch, eflags); (gdb) s regexec (preg=0x0, string=0x8189040 "Apache=hostname.or.jp.1067634189379628; sheet=% u901A%u5E38%u30D5%u30A9%u30F3%u30C8; abcdefgh.html=11", nmatch=3, pmatch=0xbfbff940, eflags=0) at pcreposix.c:233 233 int options = 0; (gdb) s 242 int *ovector = NULL; (gdb) s 243 int allocated_ovector = 0; (gdb) s 245 if ((eflags & REG_NOTBOL) != 0) options |= PCRE_NOTBOL; (gdb) s 246 if ((eflags & REG_NOTEOL) != 0) options |= PCRE_NOTEOL; (gdb) s 255 if (nmatch > 0) (gdb) s 257 if (nmatch <= SMALL_NMATCH) (gdb) s 259 ovector = &(small_ovector[0]); (gdb) s 269 rc = pcre_exec(preg->re_pcre, NULL, string, (int)strlen(string), 0, opti ons, (gdb) s Program received signal SIGSEGV, Segmentation fault. 0x080a495b in regexec (preg=0x0, string=0x8189040 "Apache=hostname.or.jp.1067634189379628; sheet=% u901A%u5E38%u30D5%u30A9%u30F3%u30C8; abcdefgh.html=11", nmatch=3, pmatch=0xbfbff940, eflags=0) at pcreposix.c:269 269 rc = pcre_exec(preg->re_pcre, NULL, string, (int)strlen(string), 0, opti ons, (gdb) s Program terminated with signal SIGSEGV, Segmentation fault. The program no longer exists.
value of called to pcre_exec (from spot_cookie) 269 rc = pcre_exec(preg->re_pcre, NULL, string, (int)strlen(string), 0, options, (gdb) printf "%d\n",preg 0 (gdb) printf "%d\n", preg->re_pcre Error accessing memory address 0x0: Bad address. (gdb) printf "%s\n", string Apache=hostname.or.jp.1067634189379628; sheet=%u901A%u5E38%u30D5%u30A9%u30F3% u30C8; abcdefgh.html=11 (gdb) printf "%d\n", strlen(string) 113 (gdb) printf "%s\n",options Error accessing memory address 0x0: Bad address.
On httpd-2.0.47 will running... Breakpoint 1, spot_cookie (r=0x8186050) at mod_usertrack.c:198 198 cookie_dir_rec *dcfg = ap_get_module_config(r->per_dir_config, (gdb) s 204 if (!dcfg->enabled || r->main) { (gdb) 208 if ((cookie = apr_table_get(r->headers_in, (gdb) apr_table_get (t=0x8186218, key=0x80cf7dc "Cookie") at apr_tables.c:481 481 if (key == NULL) { (gdb) 485 hash = TABLE_HASH(key); (gdb) 486 if (!TABLE_INDEX_IS_INITIALIZED(t, hash)) { (gdb) 489 COMPUTE_KEY_CHECKSUM(key, checksum); (gdb) 490 next_elt = ((apr_table_entry_t *) t->a.elts) + t->index_first[hash]; ; (gdb) 491 end_elt = ((apr_table_entry_t *) t->a.elts) + t->index_last[hash]; (gdb) 493 for (; next_elt <= end_elt; next_elt++) { (gdb) 494 if ((checksum == next_elt->key_checksum) && (gdb) 493 for (; next_elt <= end_elt; next_elt++) { (gdb) 494 if ((checksum == next_elt->key_checksum) && (gdb) 496 return next_elt->val; (gdb) 501 } (gdb) spot_cookie (r=0x8186050) at mod_usertrack.c:212 212 if ((value = ap_strstr_c(cookie, dcfg->cookie_name))) { (gdb) 215 value += strlen(dcfg->cookie_name) + 1; /* Skip over the '= ' */ (gdb) 216 cookiebuf = apr_pstrdup(r->pool, value); (gdb) apr_pstrdup (a=0x8186018, s=0x81873b7 "hostname.or.jp.1067634189379628; sheet=%u901A%u5E38% u30D5%u30A9%u30F3%u30C8; abcdefgh.html=11") at apr_strings.c:111 111 if (s == NULL) { (gdb) 114 len = strlen(s) + 1; (gdb) 115 res = apr_palloc(a, len); (gdb) apr_palloc (pool=0x8186018, size=107) at apr_pools.c:620 620 size = APR_ALIGN_DEFAULT(size); (gdb) 621 active = pool->active; (gdb) 624 if (size < (apr_size_t)(active->endp - active->first_avail)) { (gdb) 625 mem = active->first_avail; (gdb) 626 active->first_avail += size; (gdb) 628 return mem; (gdb) 679 } (gdb) apr_pstrdup (a=0x8186018, s=0x81873b7 "hostname.or.jp.1067634189379628; sheet=%u901A%u5E38% u30D5%u30A9%u30F3%u30C8; line-index.html=11") at apr_strings.c:116 116 memcpy(res, s, len); (gdb) 117 return res; (gdb) 118 } (gdb) spot_cookie (r=0x8186050) at mod_usertrack.c:217 217 cookieend = strchr(cookiebuf, ';'); (gdb) 218 if (cookieend) (gdb) 219 *cookieend = '\0'; /* Ignore anything after a ; */ (gdb) 222 apr_table_setn(r->notes, "cookie", cookiebuf); (gdb) apr_table_setn (t=0x81869a8, key=0x80cf7cd "cookie", val=0x8187980 "hostname.or.jp.1067634189379628") at apr_tables.c:584 584 COMPUTE_KEY_CHECKSUM(key, checksum); (gdb) 585 hash = TABLE_HASH(key); (gdb) 586 if (!TABLE_INDEX_IS_INITIALIZED(t, hash)) { (gdb) 587 t->index_first[hash] = t->a.nelts; (gdb) 588 TABLE_SET_INDEX_INITIALIZED(t, hash); (gdb) 589 goto add_new_elt; (gdb) 640 t->index_last[hash] = t->a.nelts; (gdb) 641 next_elt = (apr_table_entry_t *) table_push(t); (gdb) apr_array_push_noclear (arr=0x81869a8) at apr_tables.c:158 158 if (arr->nelts == arr->nalloc) { (gdb) 169 ++arr->nelts; (gdb) 170 return arr->elts + (arr->elt_size * (arr->nelts - 1)); (gdb) 171 } (gdb) apr_table_setn (t=0x81869a8, key=0x80cf7cd "cookie", val=0x8187980 "hostname.or.jp.1067634189379628") at apr_tables.c:642 642 next_elt->key = (char *)key; (gdb) 643 next_elt->val = (char *)val; (gdb) 644 next_elt->key_checksum = checksum; (gdb) 645 } (gdb) spot_cookie (r=0x8186050) at mod_usertrack.c:224 224 return DECLINED; /* There's already a cookie, no new one */ (gdb) 228 } (gdb) 0x0809f5f5 in ap_run_fixups (r=0x8186050) at request.c:114 114 (request_rec *r), (r), OK, DECLINED) (gdb) fix_encoding (r=0x8186050) at mod_negotiation.c:3077 3077 const char *enc = r->content_encoding; (gdb) 3078 char *x_enc = NULL; (gdb) 3083 if (!enc || !*enc) { (gdb) 3084 return DECLINED; (gdb) 3117 } ...etc...
Looks like there is a bug in the cookie finding part of mod_usertrack introduced by my changes to the most recent mod_usertrack: If "CookieTracking on" is in httpd.conf, "CookieName Apache" also has to be in there. (Or, you can have the value of CookieName be whatever you like; but CookieName *has* to be set to circumvent the bug I introduced.) I'll be working on a fix for this in the next few days, but for now the workaround should work. --Manni Wood
Is it a light initialization mistake? Dump core was avoidable. Thanks. ---- An easy patch... (not test...It moves for the time being.) mod_usertrack.c : line 254: static void *make_cookie_dir(apr_pool_t *p, char *d) { cookie_dir_rec *dcfg; dcfg = (cookie_dir_rec *) apr_pcalloc(p, sizeof(cookie_dir_rec)); dcfg->cookie_name = COOKIE_NAME; dcfg->cookie_domain = NULL; dcfg->style = CT_UNSET; dcfg->enabled = 0; + dcfg->regexp_string = (char *)apr_palloc(p, 25 + strlen(COOKIE_NAME) * 2); + apr_snprintf(dcfg->regexp_string, 25 + strlen(COOKIE_NAME) * 2 + , "^%s([^;]+)|;[ \t]+%s=([^;]+)", COOKIE_NAME, COOKIE_NAME); + dcfg->regexp=ap_pregcomp(p, dcfg->regexp_string, REG_EXTENDED); return dcfg; }
Since it was thought that abnormalities occurred in all OS's as long as the source code was seen, Plathome was changed into All.
The following is my first cut at a patch. It solves all of the problems, but it has not yet been assessed by anyone on the apache developer's list. Take the patch that follows, copy it to a file called mod_usertrack_2.0.48.patch, copy mod_usertrack_2.0.48.patch to httpd-2.0.48/modules/metadata, then run patch -p0 < mod_usertrack_2.0.48.patch and recompile. -Manni --- mod_usertrack-old.c 2003-11-08 01:42:11.000000000 -0500 +++ mod_usertrack.c 2003-11-08 23:02:28.000000000 -0500 @@ -104,7 +104,7 @@ #include "http_config.h" #include "http_core.h" #include "http_request.h" - +#include "http_log.h" module AP_MODULE_DECLARE_DATA usertrack_module; @@ -211,6 +211,14 @@ return DECLINED; } + /* Check to be sure there is a regexp available; it may not have + compiled, leaving dcfg->regexp null. */ + if (dcfg->regexp == NULL) { + ap_log_error(APLOG_MARK, APLOG_ERR, APR_SUCCESS, r->server, "The regular expression that will be used to find the usertrack cookie in the cookie header could not be compiled. Disabling mod_usertrack."); + dcfg->enabled = 0; + return DECLINED; + } + if ((cookie_header = apr_table_get(r->headers_in, (dcfg->style == CT_COOKIE2 ? "Cookie2" @@ -260,6 +268,21 @@ dcfg->cookie_domain = NULL; dcfg->style = CT_UNSET; dcfg->enabled = 0; + + /* The goal is to end up with this regexp, + * ^COOKIE_NAME=([^;]+)|;[ \t]+COOKIE_NAME=([^;]+) + * with COOKIE_NAME + * obviously substituted with the real cookie name defined + * by the COOKIE_NAME macro. This regexp will get replaced + * by the regexp in set_cookie_name() if the CookieName is + * used in httpd.conf. */ + dcfg->regexp_string = apr_pstrcat(p, "^", COOKIE_NAME, + "=([^;]+)|;[ \t]+", COOKIE_NAME, + "=([^;]+)", NULL); + + /* Remember that ap_pregcomp could return null, so + we will have to deal with this later in spot_cookie(). */ + dcfg->regexp = ap_pregcomp(p, dcfg->regexp_string, REG_EXTENDED); return dcfg; }
BTW, the segfault happens for me when Netscape and RFC2109 cookies are set. Setting CookieName to Apache gets rid of the problem. If RFC2965 cookies are set, the problem is not the segfault, but rather the fact that cookie simply isn't found. Therefore, every new connection generates yet another cookie (as visible in the log). libapreq2 also sees the cookie as a different one every time. Therefore, the session upkeeping cannot be done at all. In any event, setting CookieName to Apache does not work around the above problem for RFC2965 cookies. Not sure if the patch does...
Bojan Smojver, I recommend you use CookieStyle Netscape or CookieStyle Cookie (or the synonymous CookieStyle 2109) in httpd.conf, not CookieStyle Cookie2 (or the synonymous CookieStyle RFC2965). I watched HTTP network traffic through Ethereal, and noted that while Apache correctly sends "Cookie2:" headers, Mozilla does not accept them. This is why you see a new cookie each time in your logs: Apache is not finding the cookie because your browser is not accepting "Cookie2:" headers. The following is my second try at a patch. It's more elegant than my first patch. It solves all of the problems (I tested it with or without the CookieName directive, and with CookieStyle set to Apache, Cookie, and Cookie2 -- though Mozilla doesn't yet accept Cookie2 headers, so I couldn't test cookie detection). Like my previous patch, this patch has not yet been assessed by anyone on the Apache developer's list. Take the patch that follows, copy it to a file called mod_usertrack_2.0.48.patch, copy mod_usertrack_2.0.48.patch to httpd-2.0.48/modules/metadata, then run patch -p0 < mod_usertrack_2.0.48.patch and recompile. -Manni Bojan Smojver, I recommend you use CookieStyle Netscape or CookieStyle Cookie (or the synonymous CookieStyle 2109) in httpd.conf, not CookieStyle Cookie2 (or the synonymous CookieStyle RFC2965). I watched HTTP network traffic through Ethereal, and noted that while Apache correctly sends "Cookie2:" headers, Mozilla does not accept them. This is why you see a new cookie each time in your logs: Apache is not finding the cookie because your browser is not accepting "Cookie2:" headers. The following is my second try at a patch. It's more elegant than my first patch. It solves all of the problems (I tested it with or without the CookieName directive, and with CookieStyle set to Apache, Cookie, and Cookie2 -- though Mozilla doesn't yet accept Cookie2 headers, so I couldn't test cookie detection). Like my previous patch, this patch has not yet been assessed by anyone on the Apache developer's list. Take the patch that follows, copy it to a file called mod_usertrack_2.0.48.patch, copy mod_usertrack_2.0.48.patch to httpd-2.0.48/modules/metadata, then run patch -p0 < mod_usertrack_2.0.48.patch and recompile. -Manni --- mod_usertrack-old.c 2003-11-10 23:28:19.000000000 -0500 +++ mod_usertrack.c 2003-11-11 00:16:15.000000000 -0500 @@ -199,6 +199,20 @@ * which has three subexpressions, $0..$2 */ #define NUM_SUBS 3 +static void set_and_comp_regexp(cookie_dir_rec *dcfg, + apr_pool_t *p, + const char *cookie_name) +{ + /* The goal is to end up with this regexp, + * ^cookie_name=([^;]+)|;[\t]+cookie_name=([^;]+) + * with cookie_name obviously substituted either + * with the real cookie name set by the user in httpd.conf, or with the + * default COOKIE_NAME. */ + dcfg->regexp_string = apr_pstrcat(p, "^", cookie_name, "=([^;]+)|;[ \t]+", cookie_name, "=([^;]+)", NULL); + + dcfg->regexp = ap_pregcomp(p, dcfg->regexp_string, REG_EXTENDED); +} + static int spot_cookie(request_rec *r) { cookie_dir_rec *dcfg = ap_get_module_config(r->per_dir_config, @@ -260,6 +274,11 @@ dcfg->cookie_domain = NULL; dcfg->style = CT_UNSET; dcfg->enabled = 0; + + /* In case the user does not use the CookieName directive, + * we need to compile the regexp for the default cookie name. */ + set_and_comp_regexp(dcfg, p, COOKIE_NAME); + return dcfg; } @@ -345,18 +364,10 @@ { cookie_dir_rec *dcfg = (cookie_dir_rec *) mconfig; - /* The goal is to end up with this regexp, - * ^cookie_name=([^;]+)|;[ \t]+cookie_name=([^;]+) - * with cookie_name - * obviously substituted with the real cookie name set by the - * user in httpd.conf. */ - dcfg->regexp_string = apr_pstrcat(cmd->pool, "^", name, - "=([^;]+)|;[ \t]+", name, - "=([^;]+)", NULL); - dcfg->cookie_name = apr_pstrdup(cmd->pool, name); - dcfg->regexp = ap_pregcomp(cmd->pool, dcfg->regexp_string, REG_EXTENDED); + set_and_comp_regexp(dcfg, cmd->pool, name); + if (dcfg->regexp == NULL) { return "Regular expression could not be compiled."; }
Similar behavior exists in version 1.3.29 (Solaris 7); "CookieTracking On" with no "CookieName" results in a SIGSEGV. Explicitly setting CookieName as suggested in "Additional Comments From Manni Wood 2003-11-07 16:55" appears to be a successful workaround for 1.3.29 as well. # # Debugger trace of mod_usertrack segfault on apache 1.3.29, Solaris 7 # ("CookieTracking on", no CookieName set in httpd.conf # Breakpoint 1, spot_cookie (r=0xe7950) at mod_usertrack.c:295 295 cookie_dir_rec *dcfg = ap_get_module_config(r->per_dir_config, # # # show cookie_dir_rec # # (gdb) print *dcfg $8 = {enabled = 1, style = CT_NETSCAPE, format = CF_NORMAL, cookie_name = 0x1 <Address 0x1 out of bounds>, cookie_domain = 0x1 <Address 0x1 out of bounds>, prefix_string = 0x190 <Address 0x190 out of bounds>, regexp_string = 0x0, regexp = 0x0} # # # Step further ... # # (gdb) s 301 if (!dcfg->enabled) { (gdb) s 305 if ((cookie_header = ap_table_get(r->headers_in, (gdb) s 309 if (!ap_regexec(dcfg->regexp, cookie_header, NUM_SUBS, regm, 0)) { # # # Show parameters passed to ap_regexec. cookie_header appears # to hold data; dcfg->regexp is a null pointer # # (gdb) print cookie_header $9 = 0xe7360 "Apache=172.19.30.174.114851068582299525" (gdb) print dcfg->regexp $11 = (regex_t *) 0x0 # # # Stepping into ap_regexec ... # # (gdb) s Program received signal SIGSEGV, Segmentation fault. 0xff1e88e0 in __regexec_C () from /usr/lib/libc.so.1 # # # show backtrace # # # (gdb) bt #0 0xff1e88e0 in __regexec_C () from /usr/lib/libc.so.1 #1 0x4412c in ap_regexec () #2 0xfe591090 in spot_cookie (r=0xe7950) at mod_usertrack.c:309 #3 0x20130 in run_method () #4 0x20290 in ap_run_fixups () #5 0x409e4 in process_request_internal () #6 0x40f90 in ap_internal_redirect () #7 0x401e4 in ap_die () #8 0x402b8 in decl_die () #9 0x4069c in process_request_internal () #10 0x40aa0 in ap_process_request () #11 0x33380 in child_main () #12 0x3363c in make_child () #13 0x33858 in startup_children () #14 0x3431c in standalone_main () #15 0x34f90 in main () $ httpd -V $ /d/apache/bin/httpd -V Server version: Apache/1.3.29 (Unix) Server built: Nov 11 2003 10:26:38 Server's Module Magic Number: 19990320:15 Server compiled with.... -D EAPI -D EAPI_MM -D EAPI_MM_CORE_PATH="logs/httpd.mm" -D HAVE_MMAP -D USE_MMAP_SCOREBOARD -D USE_MMAP_FILES -D HAVE_FCNTL_SERIALIZED_ACCEPT -D HAVE_SYSVSEM_SERIALIZED_ACCEPT -D HAVE_PTHREAD_SERIALIZED_ACCEPT -D DYNAMIC_MODULE_LIMIT=64 -D HARD_SERVER_LIMIT=2048 -D HTTPD_ROOT="/d/apache-1.3.29-20031117" -D SUEXEC_BIN="/d/apache-1.3.29-20031117/bin/suexec" -D DEFAULT_PIDLOG="logs/httpd.pid" -D DEFAULT_SCOREBOARD="logs/httpd.scoreboard" -D DEFAULT_LOCKFILE="logs/httpd.lock" -D DEFAULT_ERRORLOG="logs/error_log" -D TYPES_CONFIG_FILE="conf/mime.types" -D SERVER_CONFIG_FILE="conf/httpd.conf" -D ACCESS_CONFIG_FILE="conf/access.conf" -D RESOURCE_CONFIG_FILE="conf/srm.conf"
That's right, Steve. When I introduced my mod_usertrack patch (and, sadly, bug) to mod_usertrack for the latest 2.0.x release, I also back-ported it to the latest 1.3.x release, so the bug will be the same for 1.3.x as for 2.0.x, and the workaround will be the same, as you have already discovered. I'm waiting for advice on the 2.0.x patch you see below from a developer who's closer to the ASF than I am. Once I get an all clear, I'll submit the fix to the Apache developer's mailing list as a 2.0.x patch as well as a back-ported 1.3.x patch. -Manni
*** Bug 24384 has been marked as a duplicate of this bug. ***
manni: latest patch is looking good so far. i'll give it a closer look tomorrow. sorry i couldn't get it taken care of at apachecon last week... my notebook's hard drive crashed! doh!! =) fyi, i put a notice on http://httpd.apache.org/ about this problem since lots of people seem to be hitting it.
Please tag such reports with the FAQ keyword as well :)
I'm somewhat busy, and did'nt see and become precocious. Checked with Mr. Manni Wood's patch. Since the same bug was checked also by the old Sun machine, Plathome was changed into All.
Patch backported for 1.3, passes tests and posted to list.
*** Bug 26203 has been marked as a duplicate of this bug. ***
Fix committed to 2.1, 2.0 and 1.3: http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/metadata/mod_usertrack.c#rev1.42 http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/metadata/mod_usertrack.c#rev1.39.2.3 http://cvs.apache.org/viewcvs.cgi/apache-1.3/src/modules/standard/mod_usertrack.c#rev1.60
Um, it looks like Jim committed the fix for this bug to 1.3, but it hasn't gotten committed yet to 2.0 or 2.1 (for no particular reason than I never got around to it). Reopening until that happens.
Oh yeah, thanks Cliff, you're right. I was blindly looking at the places where the problem was introduced :(
Thanks, guys, for helping patch this. --Manni
Fixed in 2.0.49. Please upgrade.
*** Bug 28000 has been marked as a duplicate of this bug. ***
Changes on a closed fixed bug are not that clever. Please give more details if you want to reopen it. Thanks.
mod_usertrack is segfaulting for me on Apache 1.3.33 (Debian package 1.3.33-6 on AMD64). CookieTracking on --> child processes segfault Setting CookieName makes no difference. The same Debian package recompiled for i386 works. It only fails on AMD64. strace is not very informative. The stack trace from the segfault is: #0 0x00000000004317da in regcomp () #1 0x000000000043133d in regcomp () #2 0x0000000000430954 in regcomp () #3 0x00000000004305f1 in regcomp () #4 0x00002aaaac522a70 in ?? () from /usr/lib/apache/1.3/mod_usertrack.so #5 0x000000000040ecc1 in ap_cleanup_method_ptrs () #6 0x00000000004203ca in ap_some_auth_required () #7 0x0000000000420555 in ap_process_request () #8 0x00000000004196ce in ap_child_terminate () #9 0x000000000041991d in ap_child_terminate () #10 0x0000000000419996 in ap_child_terminate () #11 0x000000000041a329 in ap_child_terminate () #12 0x000000000041a805 in main () (Sorry, no symbols in Debian packages - I will try to get those next). Rich.
This is the full stack trace. It's different from the one above ... I think because I've now got the cookie and it's trying to parse it. #0 0x00000000004317da in sstep (g=0x66b9b0, start=-2039141192980765773, stop=34, bef=8, ch=132, aft=8) at engine.c:909 #1 0x000000000043133d in sslow (m=0x7fffffbc6410, start=0xe3b383e38983e3b3 <Address 0xe3b383e38983e3b3 out of bounds>, stop=0x83edf0 "Apache=10.0.1.138.132001143290662991; __utma=170107067.1695268367.1143290799.1143290799.1143290799.1; __utmb=170107067; __utmc=170107067; __utmz=170107067.1143290799.1.1.utmccn=(direct)|utmcsr=(direct"..., startst=35, stopst=34) at engine.c:738 #2 0x0000000000430954 in sdissect (m=0x7fffffbc6410, start=0xe3b383e38983e3b3 <Address 0xe3b383e38983e3b3 out of bounds>, stop=0x83edf0 "Apache=10.0.1.138.132001143290662991; __utma=170107067.1695268367.1143290799.1143290799.1143290799.1; __utmb=170107067; __utmc=170107067; __utmz=170107067.1143290799.1.1.utmccn=(direct)|utmcsr=(direct"..., startst=120993912, stopst=34) at engine.c:371 #3 0x00000000004305f1 in smatcher (g=0x66b9b0, string=0x8 <Address 0x8 out of bounds>, nmatch=3, pmatch=0x7fffffbc64c0, eflags=0) at engine.c:157 #4 0x00002aaaac522a70 in spot_cookie (r=0x83a8d0) at mod_usertrack.c:310 #5 0x000000000040ecc1 in run_method (r=0x83a8d0, offset=-1987845197, run_all=1) at http_config.c:327 #6 0x00000000004203ca in process_request_internal (r=0x83a8d0) at http_request.c:1293 #7 0x0000000000420555 in ap_process_request (r=0x83a8d0) at http_request.c:1314 #8 0x00000000004196ce in child_main (child_num_arg=8628432) at http_main.c:4873 #9 0x000000000041991d in make_child (s=0x5540b0, slot=0, now=1143290662) at http_main.c:4997 #10 0x0000000000419996 in startup_children (number_to_start=5) at http_main.c:5079 #11 0x000000000041a329 in standalone_main (argc=8552640, argv=0xe3b383e38983e3b3) at http_main.c:5411 #12 0x000000000041a805 in main (argc=2, argv=0x7fffffbc67c8) at http_main.c:5768 mod_usertrack.c line 310 is the second line here (the one containing ap_regexec ...) if ((cookie_header = ap_table_get(r->headers_in, "Cookie"))) { if (!ap_regexec(dcfg->regexp, cookie_header, NUM_SUBS, regm, 0)) { char *cookieval = NULL; /* Our regexp, * ^cookie_name=([^;]+)|;[ \t]+cookie_name=([^;]+) * only allows for $1 or $2 to be available. ($0 is always * filled with the entire matched expression, not just * the part in parentheses.) So just check for either one * and assign to cookieval if present. */ if (regm[1].rm_so != -1) { cookieval = ap_pregsub(r->pool, "$1", cookie_header, NUM_SUBS, regm); } if (regm[2].rm_so != -1) { cookieval = ap_pregsub(r->pool, "$2", cookie_header, NUM_SUBS, regm); } /* Set the cookie in a note, for logging */ ap_table_setn(r->notes, "cookie", cookieval); return DECLINED; /* There's already a cookie, no new one */ } } make_cookie(r); return OK; /* We set our cookie */
(gdb) frame 4 #4 0x00002aaaac522a70 in spot_cookie (r=0x83a8d0) at mod_usertrack.c:310 310 if (!ap_regexec(dcfg->regexp, cookie_header, NUM_SUBS, regm, 0)) { (gdb) print cookie_header $1 = 0x83edd8 "Apache=10.0.1.138.132001143290662991; __utma=170107067.1695268367.1143290799.1143290799.1143290799.1; __utmb=170107067; __utmc=170107067; __utmz=170107067.1143290799.1.1.utmccn=(direct)|utmcsr=(direct"... (gdb) print regm $2 = {{rm_so = -1, rm_eo = 0}, {rm_so = 0, rm_eo = 0}, {rm_so = 0, rm_eo = 0}} (gdb) print NUM_SUBS $3 = 3 (gdb) print dcfg->regexp $4 = (regex_t *) 0x73bf20 (gdb) print *dcfg->regexp $5 = {re_magic = 62053, re_nsub = 2, re_endp = 0x0, re_g = 0x66b9b0}
The issue for which this bug was re-opened is AFAICT only the crash in regcomp() et al on x86_64 - which is a different bug, bug 31858. Marking CLOSED again.