tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ashton, Bruce" <bruce.ash...@metoffice.com>
Subject RE: large requests crash mod_jk on HP-UX 11.0
Date Tue, 28 May 2002 15:49:06 GMT
Well not a whisper of interest in this bug, but I have found a workaround at
least.  HP distribute a package which includes Apache 2 and mod_jk evidently
with the bug fixed.  It does mean porting our site to Apache 2 but this is
less of an effort than tracking down this bug.

If anybody else has this problem you could at least point them to that as a
workaround.

I have abandoned my efforts to fix the bug in the code now, I can't justify
it at work anymore, and there doesn't seem to be much interest in it here
either.



Bruce Ashton
Java Developer
Internet Application Development
The Met Office   http://www.metoffice.com/
ext. 4560

> -----Original Message-----
> From:	Ashton, Bruce 
> Sent:	Monday, May 27, 2002 3:49 PM
> To:	'tomcat-dev@jakarta.apache.org'
> Subject:	large requests crash mod_jk on HP-UX 11.0
> 
> I am really a tomcat user, but I have ended up trolling through the mod_jk
> code looking for this bug, so I thought this was the appropriate place to
> post my discoveries;
> 
> 
> Background:
> Our Unix team have built Apache from the source for HP-UX 11.0 with the HP
> cc compiler, not gcc.
> cpp and ccom versions are A.11.01.00, ld version is B.11.25
> mod_jk has been built with the same compiler using apxs and the
> build-hpux-cc.sh script.
> Apache is version 1.3.22.
> The mod_jk source comes from the file
> jakarta-tomcat-connectors-4.0.2-01-src.zip from the Jakarta site.
> 
> 
> The problem:
> Mostly this build works except: certain URL's on our site fail with an
> "internal server error" message to the browser.  The request doesn't show
> up in Apache's access log.
> 
> The following shows up in Apache's error log:
> 
> [Mon May 27 14:07:01 2002] [notice] child pid 13574 exit signal
> Segmentation fault (11)
> [Mon May 27 14:07:01 2002] [notice] child pid 12572 exit signal
> Segmentation fault (11)
> 
> always two lines.
> 
> With JkLogLevel set to debug, the following shows up in the mod_jk log:
> 
> [Mon May 27 14:07:01 2002]  [jk_uri_worker_map.c (447)]: Into
> jk_uri_worker_map_t::map_uri_to_worker
> [Mon May 27 14:07:01 2002]  [jk_uri_worker_map.c (464)]: Attempting to map
> URI '/openroadTextFC.do'
> [Mon May 27 14:07:01 2002]  [jk_uri_worker_map.c (529)]:
> jk_uri_worker_map_t::map_uri_to_worker, Found a suffix match web -> *.do
> [Mon May 27 14:07:01 2002]  [jk_uri_worker_map.c (447)]: Into
> jk_uri_worker_map_t::map_uri_to_worker
> [Mon May 27 14:07:01 2002]  [jk_uri_worker_map.c (464)]: Attempting to map
> URI '/openroadTextFC.do'
> [Mon May 27 14:07:01 2002]  [jk_uri_worker_map.c (529)]:
> jk_uri_worker_map_t::map_uri_to_worker, Found a suffix match web -> *.do
> 
> 
> I add some extra debugging myself and ascertained that jk_translate runs
> through to completion, but no debugging code in jk_handler ever gets run.
> If jk_handler is entered at all it must fail at line 1075, "const char
> *worker_name = ap_table_get(r->notes, JK_WORKER_ID);"
> 
> I've kind of shied away from trying to debug through apache.  I didn't do
> the original build anyway.
> 
> For any given URL that fails, it is possible to make it work again by
> making the URL *SHORTER*.  This is possible if there is extraneous crap in
> the query string, which you can cut out.  I have discovered that for a
> particular page (any one bad page will fail consistently)  There will be a
> particular length of URL: An 86 character URL may work say, but an 87
> character URL will fail.  The useable length of URL will vary from page to
> page though, and I haven't seen any other pattern in it.
> My speculation is that it's the size of the request object or something,
> of which the URL is only a component.  A bit woolly I admit, but it's all
> I've got.
> 
> Part of my problem is that I don't really know in what order Apache calls
> methods from mod_jk, so I don't know if any other part of mod_jk is being
> run between jk_translate and jk_handler.
> I also don't know that it isn't Apache code that is falling over instead
> of mod_jk code.
> Also IANACP (I Am Not A C Programmer) - not really anyway.  Mostly Java,
> and I've just started dabbling in C in incidental ways such as this.
> And I'm new to HP-UX as well.
> 
> Can anyone maybe shed a little light on the Apache/mod_jk interface for
> me?  A bit of a rundown on the order in which the methods are called would
> be useful.  Also is there any Apache API or mod_jk API documentation
> online which I might not be aware of.  And if anyone tells me that I need
> to start hacking the Apache code, I'll be very depressed.
> 
> Thanks in advance,
> 
> 
> 
> Bruce Ashton
> Java Developer
> Internet Application Development
> The Met Office   http://www.metoffice.com/
> ext. 4560
> 

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


Mime
View raw message