tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 46352] Apache 1.3 crashes inside mod_jk.so with selfsigned SSL cert
Date Fri, 05 Dec 2008 17:39:37 GMT
https://issues.apache.org/bugzilla/show_bug.cgi?id=46352





--- Comment #4 from Rainer Jung <rainer.jung@kippdata.de>  2008-12-05 09:39:35 PST ---
(In reply to comment #3)
> so we have all the magic tested and working as per
> http://developer.apple.com/technotes/tn2004/tn2123.html for enabling core
> dumps, and even a CoreDumpDirectory directive in /etc/httpd/httpd.conf , but we
> get no core dumps.

I didn't read the document, but what could help: if you start as root (e.g.
when using low ports) and switch user via User/Group in httpd.conf, use a high
port instead and run directly as a normal user. Most OSes are reluctant to dump
core for processes which were switching user. Another thing (maybe in the
quoted doc?) is that limit/ulimit can prevent the writing of core dumps.

Concerning gdb: httpd -X starts only one httpd process, so you always know
which you should attach to :) Of course that's not for production, because it
can only handle one response at a time, but that's fine for testing.

> One thing I have noticed is that httpd seems to take several seconds to crash;
> as if steadily iterating until it blows the stack up, which might explain why
> the the dead address looks like a bit of ASCII string.

Possible, see below for the ap_table_get code, which indeed does an iteration.

> I have also noted that my JkMount directives aren't working as expected.  Using
> older mod_jk versions, they worked with everything in the main httpd.conf ;
> with newer versions, some weren't working at all with HTTPS, so I moved most of
> the mod_jk configuration into the virtual host containers; and it's still not
> right.  Depending on the URL, some requests get 404 errors from the webserver,
> and some cause crashes.

That should be an independent thing. In fact in 1.2.26 we cleaned up the vhost
handling and as a result there was exactly one incompatible change, namely the
relation between JkMount and vhosts. For testing, you can rule out that effect
by e.g. putting them all globalyy and adding to the global server "JkMountCopy
All". If you put them into the VHosts, you might need to add them to several
VHosts (e.g. one for http, one for https).


Concerning your previous comment:

> which wrote this for three requests: two over HTTP, the last over HTTPS.
> mod_jk.c:663 r: 0x01856238 r->subprocess_env: 0x01856548
> mod_jk.c:666 r->subprocess_env: SCRIPT_URL=/services/MyServlet
> mod_jk.c:663 r: 0x01856238 r->subprocess_env: 0x01856548
> mod_jk.c:666 r->subprocess_env: SCRIPT_URL=/services/MyServlet
> mod_jk.c:663 r: 0x01856238 r->subprocess_env: 0x01856548
> mod_jk.c:666 r->subprocess_env: SCRIPT_URL=/services/Style.css

OK, so it's not NULL, and after the last output it crashes (because it's an
HTTP request), right?

Unfortunately I can't see any use of memcpy in httpd's ap_table_get:

API_EXPORT(const char *) ap_table_get(const table *t, const char *key)
{
    table_entry *elts = (table_entry *) t->a.elts;
    int i;

    if (key == NULL)
        return NULL;

    for (i = 0; i < t->a.nelts; ++i)
        if (!strcasecmp(elts[i].key, key))
            return elts[i].val;

    return NULL;
}

Maybe the strcasecmp doesn't terminate, because one of the two strings is not
correctly 0-terminated?

Unfortunately I don't have access to MacOS X, so that will be hard to debug for
me. You could:

1) delete line 659 and see, whether it runs stable then

2) replace the call to ap_table_get in line 659 by a call to my_table_get and
copy the above ap_table_get under the name my_table_get into mod_jk.c. This
code can then be instrumented with more output statements like you already did,
to get an idea what's wrong and where exactly it crashes.


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message