2007/1/31, Rainer Jung <[EMAIL PROTECTED]>:
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.

Well may be since I see this kind of error with bad printf.

I'll patch this one

@@ -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?

If was allready at info :

JkWorkersFile /www/apachedft/conf/workers.properties
JkLogFile /www/apachedft/logs/jk.log
JkShmFile        /www/apachedft/logs/jk.shm
JkLogLevel 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.

I'll try to patch the 1.2.20 source and test with new config

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to