apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sander Striker" <stri...@apache.org>
Subject HEAD dumps core with APR_POOL_DEBUG WAS: RE: cvs commit: httpd-2.0 STATUS
Date Mon, 14 Jan 2002 08:41:19 GMT
> From: trawick@rdu163-40-092.nc.rr.com
> [mailto:trawick@rdu163-40-092.nc.rr.com]On Behalf Of Jeff Trawick
> Subject: Re: cvs commit: httpd-2.0 STATUS
> 
> "Sander Striker" <striker@apache.org> writes:
> 
>>> From: trawick@apache.org [mailto:trawick@apache.org]
>>> Subject: cvs commit: httpd-2.0 STATUS
>>> 
>>> trawick     02/01/13 07:56:29
>>> 
>>>   Modified:    .        STATUS
>>>   Log:
>>>   Brian's fix looks good!
>>>   
>>>   with Brian's fixed applied and running the same tests:
>>>   
>>>     I don't hit any segfaults with yesterday's HEAD and APR_POOL_DEBUG defined
>>>   
>>>     I don't hit any segfaults with current HEAD and APR_POOL_DEBUG *not defined*
>>>   
>>>     I do hit segfaults down in apr_pool debug code with current HEAD and
>>>     APR_POOL_DEBUG *defined*
>> 
>> Do you have a backtrace?  Are you using electric fence or not?
> 
> as mentioned previously, no electric fence...

Ok, just checking.
 
> I hit it pretty soon with one worker server process and lots of
> threads serving connections.  The only patch applied was uncommenting
> APR_POOL_DEBUG in apr_pools.h.  I'm running HEAD from approx. half an
> hour ago.
> 
> Here is one backtrace (I wasn't seeing this assertion failure until I
> updated about half an hour ago and picked up the latest apr_pools.c):
> 
> #0  0xff10c2f0 in _cleanup () from /usr/lib/libc.so.1
> (gdb) where
> #0  0xff10c2f0 in _cleanup () from /usr/lib/libc.so.1
> #1  0xff0b5110 in abort () from /usr/lib/libc.so.1
> #2  0xff34c82c in check_integrity (pool=0x172f68) at apr_pools.c:926
> #3  0xff34c84c in apr_palloc (pool=0x172f68, size=12) at
> apr_pools.c:939
> #4  0xff3862ac in apr_brigade_create (p=0x172f68) at apr_brigade.c:104
> #5  0xcdd10 in core_output_filter (f=0x18f9d0, b=0x22c898) at
> core.c:3408
> #6  0xbe5f0 in ap_pass_brigade (next=0x18f9d0, bb=0x1eae78) at
> util_filter.c:388
> #7  0x4ebe8 in ap_http_header_filter (f=0x1a9950, b=0x1eae78) at
> http_protocol.c:1303
> #8  0xbe5f0 in ap_pass_brigade (next=0x1a9950, bb=0x1eae78) at
> util_filter.c:388
> #9  0xc31cc in ap_content_length_filter (f=0x1a29e0, b=0x1eae78) at
> protocol.c:1010
> #10 0xbe5f0 in ap_pass_brigade (next=0x1a29e0, bb=0x1eae78) at
> util_filter.c:388
> #11 0x51dc4 in ap_byterange_filter (f=0x2abd70, bb=0x1eae78) at
> http_protocol.c:2460
> #12 0xbe5f0 in ap_pass_brigade (next=0x2abd70, bb=0x1eae78) at
> util_filter.c:388
> #13 0xcc388 in default_handler (r=0x2663b0) at core.c:2973
> #14 0xa6250 in ap_run_handler (r=0x2663b0) at config.c:185
> #15 0xa6ec8 in ap_invoke_handler (r=0x2663b0) at config.c:359
> #16 0x53b24 in ap_internal_redirect (new_uri=0x2ef4f8
> "/index.html.en", r=0x190ed0) at http_request.c:454
> #17 0x8bfa0 in handle_map_file (r=0x190ed0) at mod_negotiation.c:2838
> #18 0xa6250 in ap_run_handler (r=0x190ed0) at config.c:185
> #19 0xa6ec8 in ap_invoke_handler (r=0x190ed0) at config.c:359
> #20 0x533c0 in ap_process_request (r=0x190ed0) at http_request.c:292
> #21 0x4b1c0 in ap_process_http_connection (c=0x1909d8) at
> http_core.c:280
> #22 0xbab14 in ap_run_process_connection (c=0x1909d8) at
> connection.c:84
> #23 0xbb0cc in ap_process_connection (c=0x1909d8) at connection.c:230
> #24 0xa0b70 in process_socket (p=0x172f68, sock=0x172fb0,
> my_child_num=0, my_thread_num=20) at worker.c:562
> #25 0xa14b8 in worker_thread (thd=0x15a9f0, dummy=0x15ad78) at
> worker.c:777
> #26 0xff340c48 in dummy_worker (opaque=0x15a9f0) at thread.c:122

This backtrace shows that check_integrity is aborting on us.
That could mean that the pool passed to apr_palloc was destroyed
previously.

/me slaps himself...
Or it could mean that I was to stupid to lock the child list
before traversing it.  I'll patch that up.  Could you try again
after that?

> Here is another flavor:
> 
> Cannot access memory at address 0xff3e08f4
> #0  0xff34c708 in ?? ()
> (gdb) where
> #0  0xff34c708 in ?? ()
> #1  0xff34c74c in ?? ()
> #2  0xff34c74c in ?? ()
> #3  0xff34c818 in ?? ()
> #4  0xff34c84c in ?? ()
> #5  0xff34d9d0 in ?? ()
> #6  0xff336844 in ?? ()
> #7  0xcc0f4 in default_handler (r=0x147138) at core.c:2928
> #8  0xa6250 in ap_run_handler (r=0x147138) at config.c:185
> #9  0xa6ec8 in ap_invoke_handler (r=0x147138) at config.c:359
> #10 0xd3dd0 in ap_run_sub_req (r=0x147138) at request.c:1746
> #11 0x37208 in handle_include (ctx=0x1ab500, bb=0xf35016d8,
> r=0x2f9ce8, f=0x2c45e0, head_ptr=0x13c180,
>     inserted_head=0xf35015d4) at mod_include.c:1237
> #12 0x3cc00 in send_parsed_content (bb=0xf35016d8, r=0x2f9ce8,
> f=0x2c45e0) at mod_include.c:2996
> #13 0x3db98 in includes_filter (f=0x2c45e0, b=0x161b20) at
> mod_include.c:3270
> #14 0xbe5f0 in ap_pass_brigade (next=0x2c45e0, bb=0x15b590) at
> util_filter.c:388
> #15 0x8bec4 in handle_map_file (r=0x2f9ce8) at mod_negotiation.c:2824
> #16 0xa6250 in ap_run_handler (r=0x2f9ce8) at config.c:185
> #17 0xa6ec8 in ap_invoke_handler (r=0x2f9ce8) at config.c:359
> #18 0x53b24 in ap_internal_redirect (new_uri=0x1386c0
> "/error/HTTP_FORBIDDEN.html.var", r=0x1fb480)
>     at http_request.c:454
> #19 0x531e4 in ap_die (type=403, r=0x1fb480) at http_request.c:218
> #20 0x53414 in ap_process_request (r=0x1fb480) at http_request.c:304
> #21 0x4b1c0 in ap_process_http_connection (c=0x1fa780) at
> http_core.c:280
> #22 0xbab14 in ap_run_process_connection (c=0x1fa780) at
> connection.c:84
> #23 0xbb0cc in ap_process_connection (c=0x1fa780) at connection.c:230
> #24 0xa0b70 in process_socket (p=0x1a5d68, sock=0x1a5db0,
> my_child_num=0, my_thread_num=150) at worker.c:562
> #25 0xa14b8 in worker_thread (thd=0x155bd0, dummy=0x156748) at
> worker.c:777
> #26 0xff340c48 in ?? ()

This is badness.  Where did that memory address come from?

> Here is another flavor:
> 
> #0  0xff117acc in _poll () from /usr/lib/libc.so.1
> (gdb) where
> #0  0xff117acc in _poll () from /usr/lib/libc.so.1
> #1  0xff0cb2e8 in select () from /usr/lib/libc.so.1
> #2  0xff05b5b0 in select () from /usr/lib/libthread.so.1
> #3  0xff33aab0 in apr_recv (sock=0x1edf60, buf=0x1d0630 "",
> len=0xfb30d6e8) at sendrecv.c:142
> #4  0xff385814 in socket_read (a=0x1c9148, str=0xfb30d6ec,
> len=0xfb30d6e8, block=APR_BLOCK_READ)
>     at apr_buckets_socket.c:75
> #5  0xcd10c in core_input_filter (f=0x1c8088, b=0x189688,
> mode=AP_MODE_BLOCKING, readbytes=0xfb30d8d4) at core.c:3156
> #6  0xbe520 in ap_get_brigade (next=0x1c8088, bb=0x189688,
> mode=AP_MODE_BLOCKING, readbytes=0xfb30d8d4)
>     at util_filter.c:362
> #7  0xcc690 in net_time_filter (f=0x1cc128, b=0x189688,
> mode=AP_MODE_BLOCKING, readbytes=0xfb30d8d4) at core.c:3002
> #8  0xbe520 in ap_get_brigade (next=0x1cc128, bb=0x189688,
> mode=AP_MODE_BLOCKING, readbytes=0xfb30d8d4)
>     at util_filter.c:362
> #9  0xc0bf8 in ap_rgetline (s=0x193618, n=8192, r=0x193600, fold=0) at
> protocol.c:225
> #10 0xc14e0 in read_request_line (r=0x193600) at protocol.c:429
> #11 0xc1dc4 in ap_read_request (conn=0x18f230) at protocol.c:608
> #12 0x4b154 in ap_process_http_connection (c=0x18f230) at
> http_core.c:273
> #13 0xbab14 in ap_run_process_connection (c=0x18f230) at
> connection.c:84
> #14 0xbb0cc in ap_process_connection (c=0x18f230) at connection.c:230
> #15 0xa0b70 in process_socket (p=0x1edf18, sock=0x1edf60,
> my_child_num=0, my_thread_num=309) at worker.c:562
> #16 0xa14b8 in worker_thread (thd=0x162600, dummy=0x1573b0) at
> worker.c:777
> #17 0xff340c48 in dummy_worker (opaque=0x162600) at thread.c:122

Haven't got a clue about this one.

> Here finally is the one I mentioned previously:
> 
> Loaded symbols for /usr/lib/libthread.so.1
> #0  0xff34c708 in pool_is_child_of (pool=0x168f30, parent=0x2537b0) at
> apr_pools.c:898
> 898         child = parent->child;
> (gdb) where
> #0  0xff34c708 in pool_is_child_of (pool=0x168f30, parent=0x2537b0) at
> apr_pools.c:898
> #1  0xff34c74c in pool_is_child_of (pool=0x168f30, parent=0x235470) at
> apr_pools.c:901
> #2  0xff34c74c in pool_is_child_of (pool=0x168f30, parent=0x117a60) at
> apr_pools.c:901
> #3  0xff34c818 in check_integrity (pool=0x168f30) at apr_pools.c:915
> #4  0xff34d9b0 in apr_pool_cleanup_register (p=0x168f30,
> data=0x171a38,
>     plain_cleanup_fn=0xff336358 <apr_unix_file_cleanup>,
> child_cleanup_fn=0xff336358 <apr_unix_file_cleanup>)
>     at apr_pools.c:1524
> #5  0xff336844 in apr_file_open (new=0xf7508cf4,
>     fname=0x2cb390
> "/export/home/trawick/apacheinst/error/include/bottom.html", flag=33,
> perm=0, cont=0x168f30)
>     at open.c:175
> #6  0xcc0f4 in default_handler (r=0x156288) at core.c:2928
> #7  0xa6250 in ap_run_handler (r=0x156288) at config.c:185
> #8  0xa6ec8 in ap_invoke_handler (r=0x156288) at config.c:359
> #9  0xd3dd0 in ap_run_sub_req (r=0x156288) at request.c:1746
> #10 0x37208 in handle_include (ctx=0x19e4d0, bb=0xf75094c0,
> r=0x19f708, f=0x19dc90, head_ptr=0x176700,
>     inserted_head=0xf75093bc) at mod_include.c:1237
> #11 0x3cc00 in send_parsed_content (bb=0xf75094c0, r=0x19f708,
> f=0x19dc90) at mod_include.c:2996
> #12 0x3db98 in includes_filter (f=0x19dc90, b=0x1b1d18) at
> mod_include.c:3270
> #13 0xbe5f0 in ap_pass_brigade (next=0x19dc90, bb=0x2cb2b8) at
> util_filter.c:388
> #14 0x8bec4 in handle_map_file (r=0x19f708) at mod_negotiation.c:2824
> #15 0xa6250 in ap_run_handler (r=0x19f708) at config.c:185
> #16 0xa6ec8 in ap_invoke_handler (r=0x19f708) at config.c:359
> #17 0x53b24 in ap_internal_redirect (new_uri=0x1386c0
> "/error/HTTP_FORBIDDEN.html.var", r=0x19e340)
>     at http_request.c:454
> #18 0x531e4 in ap_die (type=403, r=0x19e340) at http_request.c:218
> #19 0x53b48 in ap_internal_redirect (new_uri=0x2abdb8
> "/index.html.en", r=0x1a7610) at http_request.c:455
> #20 0x8bfa0 in handle_map_file (r=0x1a7610) at mod_negotiation.c:2838
> #21 0xa6250 in ap_run_handler (r=0x1a7610) at config.c:185
> #22 0xa6ec8 in ap_invoke_handler (r=0x1a7610) at config.c:359
> #23 0x533c0 in ap_process_request (r=0x1a7610) at http_request.c:292
> #24 0x4b1c0 in ap_process_http_connection (c=0x1a7050) at
> http_core.c:280
> #25 0xbab14 in ap_run_process_connection (c=0x1a7050) at
> connection.c:84
> #26 0xbb0cc in ap_process_connection (c=0x1a7050) at connection.c:230
> #27 0xa0b70 in process_socket (p=0x192c60, sock=0x192ca8,
> my_child_num=0, my_thread_num=360) at worker.c:562
> #28 0xa14b8 in worker_thread (thd=0x1607c8, dummy=0x151630) at
> worker.c:777
> #29 0xff340c48 in dummy_worker (opaque=0x1607c8) at thread.c:122

This sounds like the same lack of locking as the first bt.

> I get the feeling that I can create as many different backtraces as I
> feel like cutting and pasting.  Generally, about a second after I
> start pounding on the server it dumps core.

Well, thanks for supplying them. :)
I'll go and fix one of the problems.  Could you try again later?

> Jeff Trawick | trawick@attglobal.net | PGP public key at web site:

Sander

Mime
View raw message