headers
Zev Toledano | 5 Apr 2011 17:54

Possible serious bug in mod_fastcgi-2.4.6-AP22.dll

Greetings,

I need to report a possible serious bug but can't find any way to do 
this except via this mailing list. Apologies if I am doing this wrong:

I have developed my own Windows FastCGI app that uses its own FastCGI 
protocol implementation, and it depends on 
Apache2+mod_fastcgi-2.4.6-AP22.dll to run it.

I recently noticed that httpd.exe sometimes stops responding and takes 
100% cpu until it is killed.

After MUCH debugging, I found the cause:

Sending an FCGIEndRequest(3) packet header in pieces. Specifically, If I 
send the first two bytes of the packet separately, and then the rest, it 
causes the 100% cpu issue. This happens because I send the complete 
response in batches of 4096 and sometimes the packet headers become split.

Can anyone confirm this or tell me where to report bugs and what to do next?
Permalink | Reply | 9 comments |
headers
Rick Mansfield | 6 Apr 2011 15:08
Picon

FCGIDotNet: a simple fcgi client in C#

Greetings all,

Recently I was working on a C# project which needed to serve web pages
from the .net application, and I wanted to use fastcgi. Since I
couldn't find a good way to do this, I created a quick implementation
myself. I have made it available here:

https://sourceforge.net/projects/fcgidotnet/

It's not super fancy or anything, and it only supports TCP, but it
works fine for connecting a .net application to Apache.

The project is under the AGPL.
Permalink | Reply | 0 comments |
headers
steve arroyo | 7 Apr 2011 22:22
Picon

How to build mod_fastcgi.so on RHEL Server 5.6

/usr/sbin/apxs -o mod_fastcgi.so -c *.c

Doesn't generate a mod_fastcgi.so file

It generates these files:
mod_fastcgi.la
mod_fastcgi.lo
mod_fastcgi.o
mod_fastcgi.slo

Using instructions for shared object here:  http://www.fastcgi.com/mod_fastcgi/INSTALL

OS = RHEL 5.6  64-bit
Intel(R) Xeon(R) CPU           E5410  <at> 2.33GHz stepping 06
gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-50)
Server version: Apache/2.2.3
PHP 5.2.17

_______________________________________________
FastCGI-developers mailing list
FastCGI-developers@...
http://mailman.pins.net/mailman/listinfo.cgi/fastcgi-developers
Permalink | Reply | 0 comments |
headers
Zev Toledano | 12 Apr 2011 10:47

Re: Possible serious bug in mod_fastcgi-2.4.6-AP22.dll

OK I did my part. I guess this project isn't as alive as I thought....

On 05/04/2011 18:54, Zev Toledano wrote:

> Greetings,
>
> I need to report a possible serious bug but can't find any way to do 
> this except via this mailing list. Apologies if I am doing this wrong:
>
> I have developed my own Windows FastCGI app that uses its own FastCGI 
> protocol implementation, and it depends on 
> Apache2+mod_fastcgi-2.4.6-AP22.dll to run it.
>
> I recently noticed that httpd.exe sometimes stops responding and takes 
> 100% cpu until it is killed.
>
> After MUCH debugging, I found the cause:
>
> Sending an FCGIEndRequest(3) packet header in pieces. Specifically, If 
> I send the first two bytes of the packet separately, and then the 
> rest, it causes the 100% cpu issue. This happens because I send the 
> complete response in batches of 4096 and sometimes the packet headers 
> become split.
>
> Can anyone confirm this or tell me where to report bugs and what to do 
> next?
>
Permalink | Reply | 8 comments |
headers
Mrjk | 12 Apr 2011 11:33
Picon
Gravatar

Re: Possible serious bug in mod_fastcgi-2.4.6-AP22.dll

Hi, I think you should report this bug on the official Apache mailing list ...

Best regards,
--
MrJK

2011/4/12 Zev Toledano <fcgi@...>:
> OK I did my part. I guess this project isn't as alive as I thought....
>
>
>
> On 05/04/2011 18:54, Zev Toledano wrote:
>
>> Greetings,
>>
>> I need to report a possible serious bug but can't find any way to do this
>> except via this mailing list. Apologies if I am doing this wrong:
>>
>> I have developed my own Windows FastCGI app that uses its own FastCGI
>> protocol implementation, and it depends on
>> Apache2+mod_fastcgi-2.4.6-AP22.dll to run it.
>>
>> I recently noticed that httpd.exe sometimes stops responding and takes
>> 100% cpu until it is killed.
>>
>> After MUCH debugging, I found the cause:
>>
>> Sending an FCGIEndRequest(3) packet header in pieces. Specifically, If I
>> send the first two bytes of the packet separately, and then the rest, it
>> causes the 100% cpu issue. This happens because I send the complete response
>> in batches of 4096 and sometimes the packet headers become split.
>>
>> Can anyone confirm this or tell me where to report bugs and what to do
>> next?
>>
> _______________________________________________
> FastCGI-developers mailing list
> FastCGI-developers@...
> http://mailman.pins.net/mailman/listinfo.cgi/fastcgi-developers
>
Permalink | Reply | 1 comment |
headers
Darren Garvey | 12 Apr 2011 11:49
Picon

Re: Possible serious bug in mod_fastcgi-2.4.6-AP22.dll

Hi Zev,

On 12 April 2011 09:47, Zev Toledano <fcgi-guzWcuRpM7DB93p7Qn8acw@public.gmane.org> wrote:
OK I did my part. I guess this project isn't as alive as I thought....

AFAICT, mod_fastcgi hasn't had anyone maintaining it for quite some time. However, mod_fcgid is now part of Apache so you may consider "upgrading" to that module if you prefer to use maintained code. 

Be aware though that mod_fcgid doesn't support external servers and possibly a couple of other features of mod_fastcgi.

Regards,
Darren
_______________________________________________
FastCGI-developers mailing list
FastCGI-developers@...
http://mailman.pins.net/mailman/listinfo.cgi/fastcgi-developers
Permalink | Reply | 5 comments |
headers
Richard Mansfield | 12 Apr 2011 11:59
Picon

Re: Possible serious bug in mod_fastcgi-2.4.6-AP22.dll

The lack of support for external servers, in practice, seems to be a
huge hole in the feature set. A large benefit of FCGI is in being able
to easily connect custom non-web applications to a webserver for eg.
providing data for existing web applications.

Zev, have you been able to trace through the server code and figure
out what is happening? I looked through fcgi_protocol_dequeue at
http://www.fastcgi.com/cvs/mod_fastcgi/fcgi_protocol.c and it looks
correct to me. Perhaps with more information a fix could still be
applied?

On Tue, Apr 12, 2011 at 5:49 AM, Darren Garvey
<lists.drrngrvy@...> wrote:
> Hi Zev,
>
> On 12 April 2011 09:47, Zev Toledano <fcgi@...> wrote:
>>
>> OK I did my part. I guess this project isn't as alive as I thought....
>
> AFAICT, mod_fastcgi hasn't had anyone maintaining it for quite some time.
> However, mod_fcgid is now part of Apache so you may consider "upgrading" to
> that module if you prefer to use maintained code.
> Be aware though that mod_fcgid doesn't support external servers and possibly
> a couple of other features of mod_fastcgi.
> Regards,
> Darren
> _______________________________________________
> FastCGI-developers mailing list
> FastCGI-developers@...
> http://mailman.pins.net/mailman/listinfo.cgi/fastcgi-developers
>
>

--

-- 
Thanks,
Rick
Permalink | Reply | 3 comments |
headers
Zev Toledano | 12 Apr 2011 12:03

Re: Possible serious bug in mod_fastcgi-2.4.6-AP22.dll

As far as I understand, mod_fastcgi has nothing to do with Apache?

On 12/04/2011 12:33, Mrjk wrote:

> Hi, I think you should report this bug on the official Apache mailing list ...
>
> Best regards,
> --
> MrJK
>
>
>
> 2011/4/12 Zev Toledano<fcgi@...>:
>> OK I did my part. I guess this project isn't as alive as I thought....
Permalink | Reply | 0 comments |
headers
Zev Toledano | 12 Apr 2011 12:12

Re: Possible serious bug in mod_fastcgi-2.4.6-AP22.dll

I already made my code work for mod_fcgid as well as IIS. But I found mod_fastcgi to be faster than mod_fcgid when it comes to concurrency and request queueing. Of course my tests were not very scientific, but this is my current impression. Add to this also the lack of support for TCP/IP.


I also found it more difficult to work directly with mod_fcgid - it has odd and very impatient behaviour concerning named pipes with queued requests. I made it work in the end, but overall and without going into more details, my impression was that mod_fcgid isn't as mature/well-written for developers like me writing their own implementation.


So it's a pity mod_fastcgi isn't being maintained.



On 12/04/2011 12:49, Darren Garvey wrote:

Hi Zev,

On 12 April 2011 09:47, Zev Toledano <fcgi-guzWcuRpM7DB93p7Qn8acw@public.gmane.org> wrote:
OK I did my part. I guess this project isn't as alive as I thought....

AFAICT, mod_fastcgi hasn't had anyone maintaining it for quite some time. However, mod_fcgid is now part of Apache so you may consider "upgrading" to that module if you prefer to use maintained code. 

Be aware though that mod_fcgid doesn't support external servers and possibly a couple of other features of mod_fastcgi.

Regards,
Darren
_______________________________________________
FastCGI-developers mailing list
FastCGI-developers@...
http://mailman.pins.net/mailman/listinfo.cgi/fastcgi-developers
Permalink | Reply | 0 comments |
headers
Zev Toledano | 12 Apr 2011 12:20

Re: Possible serious bug in mod_fastcgi-2.4.6-AP22.dll


On 12/04/2011 12:59, Richard Mansfield wrote:

> The lack of support for external servers, in practice, seems to be a
> huge hole in the feature set. A large benefit of FCGI is in being able
> to easily connect custom non-web applications to a webserver for eg.
> providing data for existing web applications.
Exactly, which is what I am doing. I converted my client-server app into 
a web app using fastcgi and it required that I make my own fastcgi 
protocol implementation but at least I don't have to rewrite everything 
else.

This means that support for external servers/TCPIP is pretty important 
like you say.

> Zev, have you been able to trace through the server code and figure
> out what is happening? I looked through fcgi_protocol_dequeue at
> http://www.fastcgi.com/cvs/mod_fastcgi/fcgi_protocol.c and it looks
> correct to me. Perhaps with more information a fix could still be
> applied?

Frankly, it took me 3-4 days of painful debugging just to find the cause 
and then 10 minutes to program a workaround and I didn't feel like 
starting to debug mod_fastcgi code after that. As i said, my workaround 
was to ensure that end packets were never split - everything else worked 
fine. WIthout it, I get an unequivocal 100% cpu freeze on httpd.exe 
every single time.
Permalink | Reply | 0 comments |

Gmane