You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by Achal Kumar <ku...@gmail.com> on 2011/03/11 21:15:20 UTC
Re: [users@httpd] core dumps in 2.2.15 and above (found the culprit)
Hi,
We reverted the changes made in apache r827514 (
http://svn.apache.org/viewvc?view=revision&revision=827514).
This was leading to segfaults on unexpeted origin server shutdown when all
threads were busy in worker MPM.
/****
* Return APR_EOF if request body is shorter than the length announced by the
client.
PR: 33098
Submitted by: Stefan Fritsch <sf sfritsch.de>
****/
Achal
2011/3/9 Achal Kumar <ku...@gmail.com>
> Actually, I take it back. We were able to reproduce the crash with 2.2.15
> without the changes in rev 916627 but the frequency has gone down a little
> bit. Now if I stop the upstream content server it crashes 20% of the time. I
> am looking at the code changes between 2.2.14 and 2.2.15 but any help will
> be appreciated.
>
> I am running it on red hat linux.
>
> Achal
>
> 2011/3/9 Achal Kumar <ku...@gmail.com>
>
> yes, I reverted the changes in rev 916627. I just changed all the calls
>> from cleanup to destroy and I didn't see the issue any more. We are still
>> validating this. The setup is very simple:
>>
>> 1. We are running a load of 1000 sessions with a loader using wgets.
>> 2. Apache is configured using worker MPM and mod_proxy and we have two
>> content servers each handling roughly 500 requests.
>> 3. We shut down one content server and we see a core dump.
>>
>> gdb) bt full
>> #0 0x0000003ac00306f7 in kill () from /lib64/libc.so.6
>> No symbol table info available.
>> #1 <signal handler called>
>> No symbol table info available.
>> #2 0x00002aaca7a2db89 in apr_brigade_cleanup (data=<value optimized out>) at
>> buckets/apr_brigade.c:44
>> b = (apr_bucket_brigade *) 0x0
>> #3 0x00002aaca7c5b09d in run_cleanups (cref=0x1a99c068) at
>> memory/unix/apr_pools.c:2308
>> c = (cleanup_t *) 0x0
>> #4 0x00002aaca7c5bb0e in apr_pool_destroy (pool=0x1a99c048) at
>> memory/unix/apr_pools.c:779
>> active = <value optimized out>
>> allocator = <value optimized out>
>> #5 0x000000000046d09d in ap_process_http_connection (c=0x1a980208) at
>> http_core.c:199
>> r = (request_rec *) 0x1a99c0c0
>> csd = (apr_socket_t *) 0x0
>> #6 0x000000000043fb22 in ap_run_process_connection (c=0x1a980208) at
>> connection.c:43
>> n = 0
>> rv = 0
>> #7 0x000000000048b094 in worker_thread (thd=0x1a7066f0, dummy=<value optimized
>> out>) at worker.c:544
>> process_slot = 8
>> thread_slot = 1
>> csd = (apr_socket_t *) 0x1a97fff0
>> bucket_alloc = (apr_bucket_alloc_t *) 0x1a981f78
>> last_ptrans = <value optimized out>
>> ptrans = (apr_pool_t *) 0x1a97ff68
>> rv = <value optimized out>
>> is_idle = <value optimized out>
>> #8 0x0000003ac08064a7 in start_thread () from /lib64/libpthread.so.0
>> No symbol table info available.
>> #9 0x0000003ac00d3c2d in clone () from /lib64/libc.so.6
>> No symbol table info available.
>>
>>
>>
>> 2011/3/9 Igor Galić <i....@brainsware.org>
>>
>>
>>>
>>> ----- Original Message -----
>>> > Hi,
>>>
>>> I achal,
>>>
>>> > I have created a bug 50834. I am load testing apache 2.2.15 with
>>> > mod_proxy and two upstream content servers. If I shut down a content
>>> > server then apache core dumps. I think the issue is related to the
>>> > changes made in rev 916627 (cleanup changes)
>>>
>>> Thanks you for the report.
>>>
>>> > Anyone else facing this issue?
>>>
>>> Nope.. haven't heard of such behaviour yet.
>>> Have you tried reverting the changes in r916627 and see if this issue
>>> goes away?
>>>
>>>
>>> > Achal
>>>
>>> i
>>>
>>> --
>>> Igor Galić
>>>
>>> Tel: +43 (0) 664 886 22 883
>>> Mail: i.galic@brainsware.org
>>> URL: http://brainsware.org/
>>>
>>
>>
>>
>> --
>> Achal Kumar
>>
>> For blogging on cricket:-
>> http://funcricket.blogspot.com/
>>
>
>
>
> --
> Achal Kumar
>
> For blogging on cricket:-
> http://funcricket.blogspot.com/
>
--
Achal Kumar
For blogging on cricket:-
http://funcricket.blogspot.com/