Bug 24483 - mod_usertrack dumps core...on apache 2.0.48
Summary: mod_usertrack dumps core...on apache 2.0.48
Status: RESOLVED FIXED
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: All (show other bugs)
Version: 2.0.49
Hardware: PC Linux
: P1 critical (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords:
: 24384 26203 28000 (view as bug list)
Depends on:
Blocks:
 
Reported: 2003-11-07 00:49 UTC by Yutan
Modified: 2007-01-09 05:12 UTC (History)
7 users (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Yutan 2003-11-07 00:49:05 UTC
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
Comment 1 Yutan 2003-11-07 06:46:33 UTC
This problem is mod_usertrack.
Enable this option is dump core!!

CookieTracking on
Comment 2 Cliff Woolley 2003-11-07 07:18:19 UTC
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
Comment 3 Yutan 2003-11-07 15:37:16 UTC
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.

Comment 4 Yutan 2003-11-07 15:52:33 UTC
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.

Comment 5 Yutan 2003-11-07 16:08:20 UTC
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...
Comment 6 Manni Wood 2003-11-07 16:55:18 UTC
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
Comment 7 Yutan 2003-11-07 19:27:38 UTC
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;
}
Comment 8 Yutan 2003-11-08 15:12:34 UTC
Since it was thought that abnormalities occurred in all OS's as long as the 
source code was seen, Plathome was changed into All.
Comment 9 Manni Wood 2003-11-09 04:09:51 UTC
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;
 }
  
Comment 10 Bojan Smojver 2003-11-10 04:56:44 UTC
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...
Comment 11 Manni Wood 2003-11-11 05:27:28 UTC
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.";
     }
Comment 12 Steve Revilak 2003-11-11 20:49:29 UTC
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" 

Comment 13 Manni Wood 2003-11-11 23:04:22 UTC
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 
Comment 14 Erik Abele 2003-11-12 02:54:52 UTC
*** Bug 24384 has been marked as a duplicate of this bug. ***
Comment 15 Cliff Woolley 2003-11-24 06:30:04 UTC
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.
Comment 16 William A. Rowe Jr. 2003-11-26 22:08:57 UTC
  Please tag such reports with the FAQ keyword as well :)
Comment 17 Yutan 2003-12-29 03:31:26 UTC
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.
Comment 18 Jim Jagielski 2004-01-12 14:18:32 UTC
Patch backported for 1.3, passes tests and posted to list.
Comment 19 Erik Abele 2004-01-19 20:38:20 UTC
*** Bug 26203 has been marked as a duplicate of this bug. ***
Comment 21 Cliff Woolley 2004-01-19 22:47:20 UTC
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.
Comment 22 Erik Abele 2004-01-19 22:54:40 UTC
Oh yeah, thanks Cliff, you're right. I was blindly looking at the places where the problem was 
introduced :( 
Comment 23 Manni Wood 2004-01-20 14:54:57 UTC
Thanks, guys, for helping patch this. --Manni
Comment 24 André Malo 2004-03-25 08:14:00 UTC
Fixed in 2.0.49. Please upgrade.
Comment 25 André Malo 2004-03-28 00:48:46 UTC
*** Bug 28000 has been marked as a duplicate of this bug. ***
Comment 26 André Malo 2004-04-15 21:37:41 UTC
Changes on a closed fixed bug are not that clever. Please give more details if
you want to reopen it. Thanks.
Comment 27 Richard W.M. Jones 2006-03-25 12:30:08 UTC
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.
Comment 28 Richard W.M. Jones 2006-03-25 12:49:42 UTC
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 */
Comment 29 Richard W.M. Jones 2006-03-25 12:52:52 UTC
(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}
Comment 30 Joe Orton 2007-01-09 05:12:03 UTC
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.