Hi Henri,
there have been two bug fixes concerning string formatting, which have
core dump potential. Both only occur with log level info or above. I
think they are *not* the reason (see below). The code is in
common/jk_ajp_common.c:
1) Wrong order of arguments; should only be relevant, if new feature
"fail_on_status" is being used.
@@ -1850,10 +1864,10 @@
else if (err == JK_STATUS_ERROR) {
jk_log(l, JK_LOG_INFO,
"(%s) request failed, "
"because of response status %d, "
"recoverable operation attempt=%d",
- p->worker->http_status_fail,
- p->worker->name, i);
+ p->worker->name,
+ p->worker->http_status_fail, i);
2) Missing "s" in "%s". Should not produce a core dump.
@@ -1108,7 +1122,7 @@
if ((len = ajp_read_fully_from_server(r, l, read_buf, len)) < 0) {
jk_log(l, JK_LOG_INFO,
- "(%) receiving data from client failed. "
+ "(%s) receiving data from client failed. "
"Connection aborted or network problems",
ae->worker->name);
JK_TRACE_EXIT(l);
We don't have any other core dump reports for 1.2.20 at the moment. From
your core analysis I expect another reason. Between 1.2.19 and 1.2.20
there was the big virtual host cleanup. That included per virtual host
loggers. The method ws_write has not been changed, but some of the
config parsing, overloading and initialization.
Could you check, if there are any startup errors in your apache or
mod_jk logs? Use JkLogLevel debug and LogLevel at least info. Please try
first with a basic config with no vhosts. Does it crash during startup,
or when running requests?
Some changes:
1) If no log file is configured, it tries to use logs/mod_jk.log.
2) Log definitions get inherited from the global server to virtual
servers, but are overwritten by explicit virtual server configs.
3) The mod_jk time stamp formats and its own request logging are also
per virtual server
Do we have a chace to find out the line numbers in ws_write, where we
called the jk_log? There are tw possibilities:
399 if (!p->response_started) {
400 if (main_log)
401 jk_log(main_log, JK_LOG_INFO,
402 "Write without start, starting with
defaults");
403 if (!s->start_response(s, 200, NULL, NULL,
NULL, 0)) {
404 return JK_FALSE;
405 }
406 }
and one debug message:
435 if (JK_IS_DEBUG_LEVEL(main_log))
436 jk_log(main_log, JK_LOG_DEBUG,
437 "written %d out of %d", r, ll);
438
Does the crash go away, if JkLogLevel is info?
I'm afraid we have to debug this iteratively. I had no problems on *nix
platforms and up to now also no user reports.
Henri Gomez wrote:
Thanks.
Did the 1.2.21 is expected soon or should I use the trunk ?
I think 1.2.21 is still a couple of weeks ago, but I expect trunk to
produce the same problem, because I don't see anything we changed, that
might have fixed it.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
