Re: 2.4.17-dev crash libapr-1.dll

[Steffen <in...@apachelounge.com>]

Below is written : We could now easily blame mod_security2 on this and 
case closed :-p

This regression from 2015 is now solved with r1826556, was not a 
third-party module.

Added it to the AL 2.4.32 builds.  Have reports that all is running now 
more stable.

Thanks!

On 23-9-2015 14:43, Steffen wrote:
> 2.4.17 is a Degradation
> Who knows what other third party modules given troubles, or even ASF 
> modules.
>
> I blame 2.4.17, breaks modules.
>
> So advise first look in the httpd changes, what can cause this, and 
> then contact mod_security.
>
>
> Steffen
>
> -----Original Message----- From: Plüm, Rüdiger, Vodafone Group
> Sent: Wednesday, September 23, 2015 2:33 PM
> To: dev@httpd.apache.org
> Subject: RE: 2.4.17-dev crash libapr-1.dll
>
>
>
>> -----Original Message-----
>> From: Steffen [mailto:info@apachelounge.com]
>> Sent: Mittwoch, 23. September 2015 14:28
>> To: dev@httpd.apache.org
>> Subject: Re: 2.4.17-dev crash libapr-1.dll
>>
>> >    mod_security2.so!00007ff9e6bb1d07()    Unknown
>
> We could now easily blame mod_security2 on this and case closed :-p.
> But maybe mod_security2 gets wrong data from httpd due to a change there
> that causes this crash. So it would be handy to know where in 
> mod_security
> this crashes and if this is related to data it just forwards from httpd.
>
> Regards
>
> Rüdiger
>
>>
>> -----Original Message-----
>> From: Yann Ylavic
>> Sent: Wednesday, September 23, 2015 1:37 PM
>> To: dev@httpd.apache.org
>> Subject: ****** Re: 2.4.17-dev crash libapr-1.dll
>>
>> Can you determine where this apr_pstrdup() calls come from in httpd?
>>
>> On Wed, Sep 23, 2015 at 1:09 PM, Steffen <in...@apachelounge.com> wrote:
>> >
>> > In an other thread I wrote:
>> >
>> >
>> > Once in a few hours I see crashes.
>> > With no-ssl and no_mod_h2 crash in libapr-1.dll
>> >
>> > Once in a few hours I see crashes.
>> >
>> > To restate Apache 2.4.16 is not crashing here. With 2.4.17-dev it is
>> > crashing (no-ssl, no mod_h2 , exact same config as 2.4.16) once in 
>> a few
>> > hours running it on AL.
>> >
>> > I have more info:
>> >
>> >
>> >
>> > Unhandled exception at 0x000000006DEEAE8D (libapr-1.dll) in 
>> memory.hdmp:
>> > 0xC0000005: Access violation writing location 0x0000000000000008.
>> >
>> > Call Stack Frame apr_palloc:
>> >
>> >>libapr-1.dll!apr_palloc(apr_pool_t * pool, unsigned __int64 in_size)
>> Line
>> >> 693
>> >
>> > libapr-1.dll!apr_pstrdup(apr_pool_t * a, const char * s) Line 78
>> >
>> > +active    0x00000011ce3291e0 {next=0x00000011ce3251c0
>> > {next=0x0000000000000000 <NULL> ref=0x00000011ce3211a0 {...} ...} ...}
>> > apr_memnode_t *
>> >
>> > +active->next    0x00000011ce3251c0 {next=0x0000000000000000 <NULL>
>> > ref=0x00000011ce3211a0 {0x0000000000000000 <NULL>} ...} 
>> apr_memnode_t *
>> >
>> > +node    0x00000011ce3251c0 {next=0x0000000000000000 <NULL>
>> > ref=0x00000011ce3211a0 {0x0000000000000000 <NULL>} ...} 
>> apr_memnode_t *
>> >        size    64    unsigned __int64
>> >
>> > Next statement that  will be executed:
>> >    node = active->next;
>> >    if (size <= node_free_space(node)) {
>> > ==>     list_remove(node);
>> >
>> >
>> > Call Stack Frame apr_pstrdup:
>> >
>> > libapr-1.dll!apr_palloc(apr_pool_t * pool, unsigned __int64 in_size)
>> Line
>> > 693
>> >
>> >>libapr-1.dll!apr_pstrdup(apr_pool_t * a, const char * s) Line 78C
>> >
>> > +s 0x000000006dfb6eb0 <Error reading characters of string.> const 
>> char *
>> >
>> > Next statement to execute when this thread returns from current 
>> fuction:
>> >    len = strlen(s) + 1;
>> > ==> res = apr_pmemdup(a, s, len);
>> >    return res;
>> >
>> >
>> >
>> > Steffen
>> >
>> > 
>