httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 21222] New: - apr_thread_mutex_lock SEGV when parsing page for SSI
Date Tue, 01 Jul 2003 12:50:23 GMT
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


Mime
View raw message