httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dale Ghent <da...@elemental.org>
Subject Re: Two apache/2.0.29-dev problems
Date Sun, 11 Nov 2001 15:53:54 GMT
On Sat, 10 Nov 2001, Brian Pane wrote:

| And if that doesn't work, /usr/proc/bin/pstack {pid} will show
| stack traces for all the LWPs

ah, good point. I keep forgetting about those nifty /usr/proc/bin
programs.

Anyway, a truss on the run-away process showed this:

/7:     read(82, 0xFC803968, 1)                         = 0
/7:     read(82, 0xFC803968, 1)                         = 0
/7:     read(82, 0xFC803968, 1)                         = 0
/7:     read(82, 0xFC803968, 1)                         = 0
/7:     read(82, 0xFC803968, 1)                         = 0
/7:     read(82, 0xFC803968, 1)                         = 0
/7:     read(82, 0xFC803968, 1)                         = 0
/7:     read(82, 0xFC803968, 1)                         = 0
/7:     read(82, 0xFC803968, 1)                         = 0
/7:     read(82, 0xFC803968, 1)                         = 0
/7:     read(82, 0xFC803968, 1)                         = 0
/7:     read(82, 0xFC803968, 1)                         = 0
/7:     read(82, 0xFC803968, 1)                         = 0
/7:     read(82, 0xFC803968, 1)                         = 0
/7:     read(82, 0xFC803968, 1)                         = 0
/7:     read(82, 0xFC803968, 1)                         = 0
/7:     read(82, 0xFC803968, 1)                         = 0
/7:     read(82, 0xFC803968, 1)                         = 0
....
....
and so on.

A pstack showed that LWP 7 (thread 22) was doing this:

-----------------  lwp# 7 / thread# 22  --------------------
 ff11a814 _read    (466b40, fc803968, fc80186c, 0, 0, 0) + c
 ff33ea48 apr_file_gets (1, fc805967, 466b40, 466b40, 64206865, 61646572)
+ 38
 0006e478 cgid_handler (0, 0, 0, ffffbc00, 0, 3df838) + 4c8
 00084b28 ap_run_handler (3db280, 0, 3df8c0, 3df838, 1e, 3dbaa8) + 3c
 00084ff4 ap_invoke_handler (3db280, 143400, 0, fefe0d24, 3dba5c,
fefe0d37) + 1c
 0005a8fc ap_process_request (3db280, c8, 4, 3db280, fffffff8, 467e38) +
68
 00056918 ap_process_http_connection (467c68, 567f4, 177a50, 167994,
183500, 140
9e0) + 124
 0008e9a8 ap_run_process_connection (467c68, 467c68, 467b98, 10, 0,
140de8) + 3c
 000823ec process_socket (467b68, 467b98, 10, 10, 0, 0) + 90
 00082930 worker_thread (176c00, 0, 82888, 0, 0, 0) + a8
 ff343040 dummy_worker (18dcf8, ff155d18, 0, 5, 1, fe401000) + c
 ff05bad0 _thread_start (18dcf8, 0, 0, 0, 0, 0) + 40

Other threads were still functioning, handling requests and so forth,
albeit a bit slowly.

Eventually, the httpd process died with a SIGSEGV and left a core file,
the stack of which is here:

------------------------------------------------------------------
#0  0xff348ee0 in apr_pool_clear (a=0x2ab778) at apr_pools.c:957
957         free_blocks(a->first->h.next);
(gdb) where
#0  0xff348ee0 in apr_pool_clear (a=0x2ab778) at apr_pools.c:957
#1  0x97160 in core_output_filter (f=0x21bf20, b=0x0) at core.c:3217
#2  0x90108 in ap_pass_brigade (next=0x21bf20, bb=0x2892e0)
    at util_filter.c:276
#3  0x8ea64 in ap_lingering_close (dummy=0x21bca8) at connection.c:175
#4  0xff348d44 in run_cleanups (c=0x21bee8) at apr_pools.c:833
#5  0xff348ec8 in apr_pool_clear (a=0x21bba8) at apr_pools.c:949
#6  0xff348f24 in apr_pool_destroy (a=0x21bba8) at apr_pools.c:995
#7  0x8294c in worker_thread (thd=0x18db78, dummy=0x21bba8) at
worker.c:723
#8  0xff343048 in dummy_worker (opaque=0x18db78) at thread.c:122
(gdb) info thread
  4 LWP    2          0xff11ad54 in _signotifywait () from
/usr/lib/libc.so.1
  3 LWP    1          0xff119590 in _poll () from /usr/lib/libc.so.1
  2 LWP    4          0xff11b394 in ___lwp_cond_wait () from
/usr/lib/libc.so.1
* 1 LWP    3          0xff348ee0 in apr_pool_clear (a=0x2ab778)
    at apr_pools.c:957


HTH, /dale


Mime
View raw message