tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henri Gomez" <henri.go...@gmail.com>
Subject Re: FYI: jk 1.2.20 core on iSeries v5R3
Date Wed, 31 Jan 2007 22:09:32 GMT
2007/1/31, Rainer Jung <rainer.jung@kippdata.de>:
> 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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message