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: [email protected]
Subject: RE: 2.4.17-dev crash libapr-1.dll
-----Original Message-----
From: Steffen [mailto:[email protected]]
Sent: Mittwoch, 23. September 2015 14:28
To: [email protected]
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: [email protected]
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 <[email protected]> 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
>
>
