Re: svn commit: r1612653 - /httpd/httpd/trunk/server/util_pcre.c
Hi Rainer, On 22.07.2014 23:01, Rainer Jung wrote: documenting the requirement PCRE >= 6.7 and dropping the check (and error message) for PCRE_DUPNAMES from server/util_pcre.c. -1. Please think of non-configure builds; it doesnt hurt if the code errors out when the requirements do not met. Gün.
Re: svn commit: r1612653 - /httpd/httpd/trunk/server/util_pcre.c
+1 Le 22/07/2014 23:01, Rainer Jung a écrit : On 22.07.2014 22:20, Christophe JAILLET wrote: Hi, shouldn't the #error just a few lines below be updated as well, to be more explicit than "too old" ? You are right. But what about instead changing the configure pcre version test: Index: configure.in === --- configure.in(revision 1611600) +++ configure.in(working copy) @@ -236,7 +236,9 @@ fi case `$PCRE_CONFIG --version` in [[1-5].*]) -AC_MSG_ERROR([Need at least pcre version 6.0]) +AC_MSG_ERROR([Need at least pcre version 6.7]) + [6.[0-6]*]) +AC_MSG_ERROR([Need at least pcre version 6.7]) ;; esac AC_MSG_NOTICE([Using external PCRE library from $PCRE_CONFIG]) documenting the requirement PCRE >= 6.7 and dropping the check (and error message) for PCRE_DUPNAMES from server/util_pcre.c. I got the version number from looking and the old PCRE tags. Regards, Rainer Le 22/07/2014 21:29, rj...@apache.org a écrit : Author: rjung Date: Tue Jul 22 19:29:08 2014 New Revision: 1612653 URL: http://svn.apache.org/r1612653 Log: Clarify comment. Modified: httpd/httpd/trunk/server/util_pcre.c Modified: httpd/httpd/trunk/server/util_pcre.c URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/server/util_pcre.c?rev=1612653&r1=1612652&r2=1612653&view=diff == --- httpd/httpd/trunk/server/util_pcre.c (original) +++ httpd/httpd/trunk/server/util_pcre.c Tue Jul 22 19:29:08 2014 @@ -125,7 +125,7 @@ AP_DECLARE(int) ap_regcomp(ap_regex_t * const char *errorptr; int erroffset; int errcode = 0; -/* PCRE_DUPNAMES is only present in more recent versions of PCRE */ +/* PCRE_DUPNAMES is only present since version 6.7 of PCRE */ #ifdef PCRE_DUPNAMES int options = PCRE_DUPNAMES; #else
Re: svn commit: r1612653 - /httpd/httpd/trunk/server/util_pcre.c
On 22.07.2014 22:20, Christophe JAILLET wrote: Hi, shouldn't the #error just a few lines below be updated as well, to be more explicit than "too old" ? You are right. But what about instead changing the configure pcre version test: Index: configure.in === --- configure.in(revision 1611600) +++ configure.in(working copy) @@ -236,7 +236,9 @@ fi case `$PCRE_CONFIG --version` in [[1-5].*]) -AC_MSG_ERROR([Need at least pcre version 6.0]) +AC_MSG_ERROR([Need at least pcre version 6.7]) + [6.[0-6]*]) +AC_MSG_ERROR([Need at least pcre version 6.7]) ;; esac AC_MSG_NOTICE([Using external PCRE library from $PCRE_CONFIG]) documenting the requirement PCRE >= 6.7 and dropping the check (and error message) for PCRE_DUPNAMES from server/util_pcre.c. I got the version number from looking and the old PCRE tags. Regards, Rainer Le 22/07/2014 21:29, rj...@apache.org a écrit : Author: rjung Date: Tue Jul 22 19:29:08 2014 New Revision: 1612653 URL: http://svn.apache.org/r1612653 Log: Clarify comment. Modified: httpd/httpd/trunk/server/util_pcre.c Modified: httpd/httpd/trunk/server/util_pcre.c URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/server/util_pcre.c?rev=1612653&r1=1612652&r2=1612653&view=diff == --- httpd/httpd/trunk/server/util_pcre.c (original) +++ httpd/httpd/trunk/server/util_pcre.c Tue Jul 22 19:29:08 2014 @@ -125,7 +125,7 @@ AP_DECLARE(int) ap_regcomp(ap_regex_t * const char *errorptr; int erroffset; int errcode = 0; -/* PCRE_DUPNAMES is only present in more recent versions of PCRE */ +/* PCRE_DUPNAMES is only present since version 6.7 of PCRE */ #ifdef PCRE_DUPNAMES int options = PCRE_DUPNAMES; #else
Re: svn commit: r1612653 - /httpd/httpd/trunk/server/util_pcre.c
Hi, shouldn't the #error just a few lines below be updated as well, to be more explicit than "too old" ? CJ Le 22/07/2014 21:29, rj...@apache.org a écrit : Author: rjung Date: Tue Jul 22 19:29:08 2014 New Revision: 1612653 URL: http://svn.apache.org/r1612653 Log: Clarify comment. Modified: httpd/httpd/trunk/server/util_pcre.c Modified: httpd/httpd/trunk/server/util_pcre.c URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/server/util_pcre.c?rev=1612653&r1=1612652&r2=1612653&view=diff == --- httpd/httpd/trunk/server/util_pcre.c (original) +++ httpd/httpd/trunk/server/util_pcre.c Tue Jul 22 19:29:08 2014 @@ -125,7 +125,7 @@ AP_DECLARE(int) ap_regcomp(ap_regex_t * const char *errorptr; int erroffset; int errcode = 0; -/* PCRE_DUPNAMES is only present in more recent versions of PCRE */ +/* PCRE_DUPNAMES is only present since version 6.7 of PCRE */ #ifdef PCRE_DUPNAMES int options = PCRE_DUPNAMES; #else
Re: Question about async mod_proxy_wstunnel and threads
I got it to break with these python scripts, as well as with my own test
client and server (browser javascript and node.js). Strange though, I can't
reproduce it with only 2 clients on either of those programs; I have to get
3 clients connected at once. Past that, I see exactly the behavior you
describe.
I agree that it seems to be some sort of timing issue - I've been trying to
put trace statements into the HTTPD to see what information I can get, but
once I do that it starts behaving as expected. Still investigating...
On Tue, Jul 22, 2014 at 10:40 AM, Steve Zweep
wrote:
> Another tidbit of information ...
>
> I attempted to see what was going on by running httpd in the foreground
> with strace. When I did that, the tests worked perfectly. I guess this
> suggests it is some sort of timing issue. Running httpd in the foreground
> without trace exhibited the problem.
>
> Here's the output of strace during the test. I sent the string "hhh"
> from client 1 and it was echoed back by the server to both clients, as
> expected.
>
> [pid 15451] <... futex resumed> ) = 0
> [pid 15451] futex(0x891ec54, FUTEX_WAKE_PRIVATE, 1) = 0
> [pid 15451] epoll_wait(13, {{EPOLLIN, {u32=144017752, u64=144017752}}}, 2,
> 0) = 1
> [pid 15451] read(12, "\201\10", 8000) = 10
> [pid 15451] mprotect(0xb6a3a000, 8192, PROT_READ|PROT_WRITE) = 0
> [pid 15451] read(12, 0xb6a39aa8, 8000) = -1 EAGAIN (Resource temporarily
> unavailable)
> [pid 15451] writev(11, [{"\201\10", 10}], 1) = 10
> [pid 15451] read(12, 0xa96084b0, 8000) = -1 EAGAIN (Resource temporarily
> unavailable)
> [pid 15451] epoll_wait(13, {}, 2, 0)= 0
> [pid 15451] epoll_ctl(7, EPOLL_CTL_ADD, 11, {EPOLLIN, {u32=144044472,
> u64=144044472}}) = 0
> [pid 15451] epoll_ctl(7, EPOLL_CTL_ADD, 12, {EPOLLIN, {u32=144044496,
> u64=144044496}}) = 0
> [pid 15451] gettimeofday({1406038173, 745644}, NULL) = 0
> [pid 15451] epoll_wait(10, {{EPOLLIN, {u32=2843761856, u64=2843761856}}},
> 2, 0) = 1
> [pid 15451] read(9, "\201\10", 8000) = 10
> [pid 15451] read(9, 0xb6a39aa8, 8000) = -1 EAGAIN (Resource temporarily
> unavailable)
> [pid 15451] writev(8, [{"\201\10", 10}], 1) = 10
> [pid 15451] read(9, 0xa96084b0, 8000) = -1 EAGAIN (Resource temporarily
> unavailable)
> [pid 15451] epoll_wait(10, {}, 2, 0)= 0
> [pid 15451] epoll_ctl(7, EPOLL_CTL_ADD, 8, {EPOLLIN, {u32=2843796920,
> u64=2843796920}}) = 0
> [pid 15451] epoll_ctl(7, EPOLL_CTL_ADD, 9, {EPOLLIN, {u32=2843796944,
> u64=2843796944}}) = 0
> [pid 15451] gettimeofday({1406038173, 745832}, NULL) = 0
> [pid 15451] futex(0x891ec88, FUTEX_WAIT_PRIVATE, 38, NULL
>
>
> - Steve
>
> -Original Message-
> From: Steve Zweep
> Sent: Monday, July 21, 2014 11:56 AM
> To: 'dev@httpd.apache.org'
> Subject: RE: Question about async mod_proxy_wstunnel and threads
>
> My client and server are based on sample code included with the ws4py
> package (http://ws4py.readthedocs.org/en/latest/). We use CherryPy and
> the ws4py package contains a CherryPy-based server (attached).
>
> The client is a variation of the echo_client.py sample code also included
> in the ws4py package.
>
> In terms of failure rate, I'd say it is about 90%. Often I start 2 clients
> and initially it works OK, but then stops after a message or two. Once it
> has failed, I can send any number of messages from the one client and
> continue to see the server echo them back, but no message is received by
> the second. When I then send a message from the second client I see a flood
> of messages from the server that had been queued.
>
> - Steve
>
>
> -Original Message-
> From: Eric Covener [mailto:cove...@gmail.com]
> Sent: Saturday, July 19, 2014 8:16 AM
> To: Apache HTTP Server Development List
> Subject: Re: Question about async mod_proxy_wstunnel and threads
>
> I guess it is kind of telling that we could still respond to the write
> from client 2, there are probably more potential errors that make us lose
> track of both sides simultaneously.
>
> Can you share your ws client and server if they're easy to use? My little
> sample doesn't spray that way.
>
> I'm also curious approximately how often it fails this way.
>
> On Fri, Jul 18, 2014 at 5:50 PM, Yann Ylavic wrote:
> > Probably a false trail, trunk at r1611741 is up to date, I think 1.5.x
> > won't help.
> >
> > On Fri, Jul 18, 2014 at 11:35 PM, Steve Zweep
> > wrote:
> >> Hi Yann,
> >>
> >> The test I ran today was built with APR from trunk (r1611741). I see
> that r1605769 modifies apr_skiplist.c and there has been a lot of activity
> in the trunk version of that code lately. I can try with the 1.5.x branch
> code to see if it makes a difference. Probably won't get to this before
> Monday though.
> >>
> >> - Steve
> >>
> >> -Original Message-
> >> From: Yann Ylavic [mailto:ylavic@gmail.com]
> >> Sent: Friday, July 18, 2014 4:51 PM
> >> To: httpd
> >> Subject: Re: Question about async mod_proxy_wstunnel and threads
> >>
> >> Hi Steve,
> >>
>
RE: Question about async mod_proxy_wstunnel and threads
Another tidbit of information ...
I attempted to see what was going on by running httpd in the foreground with
strace. When I did that, the tests worked perfectly. I guess this suggests it
is some sort of timing issue. Running httpd in the foreground without trace
exhibited the problem.
Here's the output of strace during the test. I sent the string "hhh" from
client 1 and it was echoed back by the server to both clients, as expected.
[pid 15451] <... futex resumed> ) = 0
[pid 15451] futex(0x891ec54, FUTEX_WAKE_PRIVATE, 1) = 0
[pid 15451] epoll_wait(13, {{EPOLLIN, {u32=144017752, u64=144017752}}}, 2, 0) =
1
[pid 15451] read(12, "\201\10", 8000) = 10
[pid 15451] mprotect(0xb6a3a000, 8192, PROT_READ|PROT_WRITE) = 0
[pid 15451] read(12, 0xb6a39aa8, 8000) = -1 EAGAIN (Resource temporarily
unavailable)
[pid 15451] writev(11, [{"\201\10", 10}], 1) = 10
[pid 15451] read(12, 0xa96084b0, 8000) = -1 EAGAIN (Resource temporarily
unavailable)
[pid 15451] epoll_wait(13, {}, 2, 0)= 0
[pid 15451] epoll_ctl(7, EPOLL_CTL_ADD, 11, {EPOLLIN, {u32=144044472,
u64=144044472}}) = 0
[pid 15451] epoll_ctl(7, EPOLL_CTL_ADD, 12, {EPOLLIN, {u32=144044496,
u64=144044496}}) = 0
[pid 15451] gettimeofday({1406038173, 745644}, NULL) = 0
[pid 15451] epoll_wait(10, {{EPOLLIN, {u32=2843761856, u64=2843761856}}}, 2, 0)
= 1
[pid 15451] read(9, "\201\10", 8000) = 10
[pid 15451] read(9, 0xb6a39aa8, 8000) = -1 EAGAIN (Resource temporarily
unavailable)
[pid 15451] writev(8, [{"\201\10", 10}], 1) = 10
[pid 15451] read(9, 0xa96084b0, 8000) = -1 EAGAIN (Resource temporarily
unavailable)
[pid 15451] epoll_wait(10, {}, 2, 0)= 0
[pid 15451] epoll_ctl(7, EPOLL_CTL_ADD, 8, {EPOLLIN, {u32=2843796920,
u64=2843796920}}) = 0
[pid 15451] epoll_ctl(7, EPOLL_CTL_ADD, 9, {EPOLLIN, {u32=2843796944,
u64=2843796944}}) = 0
[pid 15451] gettimeofday({1406038173, 745832}, NULL) = 0
[pid 15451] futex(0x891ec88, FUTEX_WAIT_PRIVATE, 38, NULL
- Steve
-Original Message-
From: Steve Zweep
Sent: Monday, July 21, 2014 11:56 AM
To: 'dev@httpd.apache.org'
Subject: RE: Question about async mod_proxy_wstunnel and threads
My client and server are based on sample code included with the ws4py package
(http://ws4py.readthedocs.org/en/latest/). We use CherryPy and the ws4py
package contains a CherryPy-based server (attached).
The client is a variation of the echo_client.py sample code also included in
the ws4py package.
In terms of failure rate, I'd say it is about 90%. Often I start 2 clients and
initially it works OK, but then stops after a message or two. Once it has
failed, I can send any number of messages from the one client and continue to
see the server echo them back, but no message is received by the second. When I
then send a message from the second client I see a flood of messages from the
server that had been queued.
- Steve
-Original Message-
From: Eric Covener [mailto:cove...@gmail.com]
Sent: Saturday, July 19, 2014 8:16 AM
To: Apache HTTP Server Development List
Subject: Re: Question about async mod_proxy_wstunnel and threads
I guess it is kind of telling that we could still respond to the write from
client 2, there are probably more potential errors that make us lose track of
both sides simultaneously.
Can you share your ws client and server if they're easy to use? My little
sample doesn't spray that way.
I'm also curious approximately how often it fails this way.
On Fri, Jul 18, 2014 at 5:50 PM, Yann Ylavic wrote:
> Probably a false trail, trunk at r1611741 is up to date, I think 1.5.x
> won't help.
>
> On Fri, Jul 18, 2014 at 11:35 PM, Steve Zweep
> wrote:
>> Hi Yann,
>>
>> The test I ran today was built with APR from trunk (r1611741). I see that
>> r1605769 modifies apr_skiplist.c and there has been a lot of activity in the
>> trunk version of that code lately. I can try with the 1.5.x branch code to
>> see if it makes a difference. Probably won't get to this before Monday
>> though.
>>
>> - Steve
>>
>> -Original Message-
>> From: Yann Ylavic [mailto:ylavic@gmail.com]
>> Sent: Friday, July 18, 2014 4:51 PM
>> To: httpd
>> Subject: Re: Question about async mod_proxy_wstunnel and threads
>>
>> Hi Steve,
>>
>> can you still reproduce with the latest APR 1.5.x, notably containing this
>> fix: http://svn.apache.org/r1605769.
>> I don't think there is a released version with this patch...
>>
>> Regards,
>> Yann.
>>
>> On Fri, Jul 18, 2014 at 9:38 PM, Steve Zweep
>> wrote:
>>> I've attached annotated logs that show the issues I described. Both
>>> scenarios have ProxyWebsocketAsync turned on. The first does not use the
>>> AsyncDelay and shows how server messages stall and are not delivered until
>>> the client polls. The second has ProxyWebsocketAsyncDelay set to 100. In
>>> that case, message processing works properly, but threads are held open and
>>> there is no sign of async processing.
>>>
>>> Since my build and execution envi
Re: Question about APLOGNO
On Saturday 19 July 2014 20:04:09, Christophe JAILLET wrote: > Using the following regex: > ap_log_.?error.*(_ERR|_EMERG|_CRIT)[^A]*$ > many places with "missing" APLOGNO can be found. > > There are some false positives because the [^A]* at the end of the > regex is here to check, in a more or less good way, the absence of > APLOGNO. Most common mistakes are when APLOGNO is on the following > line. There is also the coccinelle script docs/log-message-tags/find- messages.cocci which is smarter than what can be done with regexes. However, it is quite possible that it needs updating to newer coccinelle versions and/or current development in httpd. docs/log- message-tags/README has a paragraph about its usage.
Re: Apache2 crashes with segmentation fault
Hello,
Sorry for the delay,
Here is the version of apache and mod_wsgi:
Apache/2.2.14 (Ubuntu)
mod_wsgi/2.8
Other packages installed : mod_fastcgi/2.4.6 mod_jk/1.2.28
PHP/5.3.2-1ubuntu4.24 with Suhosin-Patch mod_ssl/2.2.14 OpenSSL/0.9.8k
Python/2.6.5
Otherwise , I'll create a new case in mod_wsgi mailing list.
Regards
2014-07-17 13:32 GMT+00:00 Graham Dumpleton :
> Since you don't say what version of mod_wsgi you are using, or what
> version of Apache, then the only other thing I can suggest right now is to
> ensure that you are using the latest mod_wsgi version.
>
> The latest version of mod_wsgi is version 4.2.6. Pretty well all Linux
> distributions are still shipping version 3.3.
>
> Older versions may exhibit segmentation faults with Apache 2.4 in some
> situations, although this is generally only on process shutdown and I have
> never heard of mod_wsgi itself to cause a hang when using Apache 2.4,
> although lxml is very much known to in some cases.
>
> Either way, please take this discussion now to the mod_wsgi mailing list
> as described in the mod_wsgi documentation.
>
>
> http://code.google.com/p/modwsgi/wiki/WhereToGetHelp?tm=6#Asking_Your_Questions
>
> When you post to the mod_wsgi mailing list, please provide proper Apache
> and mod_wsgi version details as described in:
>
>
> http://code.google.com/p/modwsgi/wiki/CheckingYourInstallation#Apache_Build_Information
>
> http://code.google.com/p/modwsgi/wiki/CheckingYourInstallation#Apache_Modules_Loaded
>
> As well as results of verifying Python installation in use:
>
>
> http://code.google.com/p/modwsgi/wiki/CheckingYourInstallation#Python_Shared_Library
>
> http://code.google.com/p/modwsgi/wiki/CheckingYourInstallation#Python_Installation_In_Use
>
> and confirmation that your application is indeed running in the main
> interpreter and daemon mode.
>
>
> http://code.google.com/p/modwsgi/wiki/CheckingYourInstallation#Embedded_Or_Daemon_Mode
>
> http://code.google.com/p/modwsgi/wiki/CheckingYourInstallation#Sub_Interpreter_Being_Used
>
> See you in the mod_wsgi mailing list.
>
> Graham
>
>
> On 17 July 2014 01:32, Elhadi Falah wrote:
>
>> Hello,
>>
>> I use mod_wsgi to run processes and not mod_python.
>>
>> WSGIDaemonProcess p1 threads=25
>> python-path=/opt/appengine/google_appengine:/opt/appengine/google_appengine/lib/django:/opt/appengine/google_appengine/lib/webob:/opt/appengine/google_appengine/lib/yaml/lib
>> WSGIProcessGroup p1
>>
>> WSGIScriptAlias / /var/www/application/rep/handler.wsgi
>>
>> I already used the directive WSGIApplicationGroup %{GLOBAL} to run un
>> the main interpreter context but the issue persists after executing apache
>> graceful or reload.
>>
>> Regards
>>
>>
>>
>> 2014-07-16 13:44 GMT+00:00 Graham Dumpleton :
>>
>> It is well known that the lxml package doesn't work properly in a Python
>>> sub interpreter context. Force it to run in the main interpreter context.
>>>
>>> See:
>>>
>>>
>>> http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Python_Simplified_GIL_State_API
>>>
>>> In other words look at using:
>>>
>>> WSGIApplicationGroup %{GLOBAL}
>>>
>>> as documented.
>>>
>>> Graham
>>>
>>>
>>> On 16 July 2014 03:11, Elhadi Falah wrote:
>>>
Hello,
We are using lxml in several of our applications with Python 2.6 and
from time to time, the application stops responding after a segmentation
fault error ( [notice] child pid 10544 exit signal Segmentation fault
(11)), and this kind of backtrace:
Jul 1 15:24:48 server1 httpd: *** glibc detected *** /usr/sbin/apache2:
munmap_chunk(): invalid pointer: 0x7f6468bf2c00 ***
Jul 1 15:24:48 server1 httpd: === Backtrace: =
Jul 1 15:24:48 server1 httpd: /lib/libc.so.6(+0x78bf6)[0x7f64767ecbf6]
Jul 1 15:24:48 server1 httpd:
/usr/lib/libxml2.so.2(xmlCopyError+0xd1)[0x7f6473311801]
Jul 1 15:24:48 server1 httpd:
/usr/lib/libxml2.so.2(__xmlRaiseError+0x30b)[0x7f6473312ecb]
Jul 1 15:24:48 server1 httpd:
/usr/lib/libxml2.so.2(+0x393e5)[0x7f64733173e5]
Jul 1 15:24:48 server1 httpd:
/usr/lib/libxml2.so.2(xmlParseDocument+0x2dc)[0x7f647332e5cc]
Jul 1 15:24:48 server1 httpd:
/usr/lib/libxml2.so.2(+0x50895)[0x7f647332e895]
Jul 1 15:24:48 server1 httpd:
/usr/lib/python2.6/dist-packages/lxml/etree.so(+0x8cbc2)[0x7f645691cbc2]
Jul 1 15:24:48 server1 httpd:
/usr/lib/python2.6/dist-packages/lxml/etree.so(+0x2c7cf)[0x7f64568bc7cf]
After trying several versions of lxml we are still facing the
issue.I've checked for the system memory consumption but everything looks
fine to me, plenty of memory available, I don't see any process consuming
abnormally.
The issue is reproducible everytime when we execute the commande apache
(apache2 reload or apache2 graceful). As workaround for this issue we
execute apache2 restart.
We've followed recommendations define
