You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bugs@httpd.apache.org by bu...@apache.org on 2003/07/01 14:50:23 UTC
DO NOT REPLY [Bug 21222] New: -
apr_thread_mutex_lock SEGV when parsing page for SSI
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21222>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21222
apr_thread_mutex_lock SEGV when parsing page for SSI
Summary: apr_thread_mutex_lock SEGV when parsing page for SSI
Product: Apache httpd-2.0
Version: 2.0.46
Platform: Sun
OS/Version: Other
Status: NEW
Severity: Major
Priority: Other
Component: mod_include
AssignedTo: bugs@httpd.apache.org
ReportedBy: glenn@apache.org
We have two Sun E450's, dual CPU, running Solaris 7 and Apache 2.0.46
with the worker MPM. Apache 2 is compiled with CC from Sun WorkShop 5.
The two servers combined serve about 1 - 1.5 million page views per month.
In the past three weeks since I have enabled core files. During that time
I have had about a dozen child processes die with the following backtrace:
terminated by signal SEGV (no mapping at the fault address)
current thread: t@14
=>[1] apr_thread_mutex_lock(mutex = 0x2), line 133 in "thread_mutex.c"
[2] apr_file_read(thefile = 0x33af58, buf = 0x2ac650, nbytes = 0xfd0071fc),
line 86 in "readwrite.c"
[3] pipe_bucket_read(a = 0x21fd70, str = 0xfd007200, len = 0xfd0071fc, block =
APR_BLOCK_READ), line 74 in "apr_buckets_pipe.c"
[4] apr_brigade_length(bb = 0x2f6ac8, read_all = 1, length = 0xfd0072a0), line
215 in "apr_brigade.c"
[5] ap_byterange_filter(f = 0x2f3818, bb = 0x2f6ac8), line 2931 in
"http_protocol.c"
[6] ap_pass_brigade(next = 0x2f3818, bb = 0x2f6ac8), line 550 in "util_filter.c"
[7] send_parsed_content(bb = 0xfd007890, r = 0x2f2bc0, f = 0x33a5b8), line
3213 in "mod_include.c"
[8] includes_filter(f = 0x33a5b8, b = 0x2f6ac8), line 3430 in "mod_include.c"
[9] ap_pass_brigade(next = 0x33a5b8, bb = 0x2f5c20), line 550 in "util_filter.c"
[10] default_handler(r = 0x2f2bc0), line 3419 in "core.c"
[11] ap_run_handler(0x2f2bc0, 0x3b, 0x2f2bc0, 0x2e8c58, 0x0, 0x0), at 0x7fab8
[12] ap_invoke_handler(r = 0x2f2bc0), line 401 in "config.c"
[13] ap_process_request(r = 0x2f2bc0), line 288 in "http_request.c"
[14] ap_process_http_connection(c = 0x2e8c58), line 293 in "http_core.c"
[15] ap_run_process_connection(0x2e8c58, 0x2e8b98, 0x2e8b98, 0x9, 0x2e8c50,
0x21fbc0), at 0x95b80
[16] ap_process_connection(c = 0x2e8c58, csd = 0x2e8b98), line 211 in
"connection.c"
[17] process_socket(p = 0x2e8b60, sock = 0x2e8b98, my_child_num = 0,
my_thread_num = 9, bucket_alloc = 0x21fbc0), line 632 in "worker.c"
[18] worker_thread(thd = 0x1aa530, dummy = 0x1e75b8), line 947 in "worker.c"
[19] dummy_worker(opaque = 0x1aa530), line 127 in "thread.c"
I have also seen the following backtrace several times, it may be related
to the one above.
terminated by signal SEGV (no mapping at the fault address)
current thread: t@6
=>[1] __align_cpy_1(0x5d3401, 0x629010, 0x1f38, 0x7, 0x0, 0x5d3401), at 0xfee70718
[2] apr_file_read(thefile = 0x5c3318, buf = 0x5d3400, nbytes = 0xfdc071f4),
line 122 in "readwrite.c"
[3] pipe_bucket_read(a = 0x4baa90, str = 0xfdc071f8, len = 0xfdc071f4, block =
APR_BLOCK_READ), line 74 in "apr_buckets_pipe.c"
[4] apr_brigade_length(bb = 0x596010, read_all = 1, length = 0xfdc07298), line
215 in "apr_brigade.c"
[5] ap_byterange_filter(f = 0x4f1bb8, bb = 0x596010), line 2931 in
"http_protocol.c"
[6] ap_pass_brigade(next = 0x4f1bb8, bb = 0x596010), line 550 in "util_filter.c"
[7] send_parsed_content(bb = 0xfdc07888, r = 0x4f0f60, f = 0x4ee778), line
3213 in "mod_include.c"
[8] includes_filter(f = 0x4ee778, b = 0x596010), line 3430 in "mod_include.c"
[9] ap_pass_brigade(next = 0x4ee778, bb = 0x595218), line 550 in "util_filter.c"
[10] default_handler(r = 0x4f0f60), line 3419 in "core.c"
[11] ap_run_handler(0x4f0f60, 0x3b, 0x4f0f60, 0x4eb008, 0x0, 0x0), at 0x7fab8
[12] ap_invoke_handler(r = 0x4f0f60), line 401 in "config.c"
[13] ap_process_request(r = 0x4f0f60), line 288 in "http_request.c"
[14] ap_process_http_connection(c = 0x4eb008), line 293 in "http_core.c"
[15] ap_run_process_connection(0x4eb008, 0x4eaf48, 0x4eaf48, 0x41, 0x4eb000,
0x4ba520), at 0x95b80
[16] ap_process_connection(c = 0x4eb008, csd = 0x4eaf48), line 211 in
"connection.c"
[17] process_socket(p = 0x4eaf10, sock = 0x4eaf48, my_child_num = 1,
my_thread_num = 1, bucket_alloc = 0x4ba520), line 632 in "worker.c"
[18] worker_thread(thd = 0x17a6c0, dummy = 0x135c28), line 947 in "worker.c"
[19] dummy_worker(opaque = 0x17a6c0), line 127 in "thread.c"
I have not been able to reproduce this on a test system yet.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org