https://issues.apache.org/bugzilla/show_bug.cgi?id=46352
--- Comment #4 from Rainer Jung <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
