Re: [Fastcgipp-users] SIGPIPE causes SEGFAULT

[Eddie Carle]

On Tue, 2010-11-09 at 01:16 +0100, Volker Schreiner wrote:
> I developed an Webapplication and implemented a thread per Request
> concept. This means one Request is handled in one thread. If i use
> nginx as a webserver and create up to 50 concurrent Requests for
> 1000 Requests it seems that this pushes my test system to its
> envelope. This means the nginx Webserver is unable to handle the
> connections and the client creates a SIGPIPE Unix Signal that gets
> forwarded to the webapplication by the nginx Webserver. This SIGPIPE
> Signal seems to cause a Segmentations Fault in the
> Fastcgipp::Transceiver::Buffer::freeRead () method.
> The core dump of gdb looks like following:
> 
> (gdb) where
> #0  0x00388006 in ?? () from /usr/lib/libfastcgipp.so.2
> #1  0x0036ffce in Fastcgipp::Transceiver::Buffer::freeRead (
>     this=0xa93794e0, size=16) at transceiver.cpp:177
> #2  0x0037054f in Fastcgipp::Transceiver::transmit (this=0xbf868e64)
>     at transceiver.cpp:43
> #3  0x0036be5d in Fastcgipp::Request<char>::complete() ()
> ---Type <return> to continue, or q <return> to quit---
>    from /usr/lib/libfastcgipp.so.2
> #4  0x0036c0cf in Fastcgipp::Request<char>::handler() ()
>    from /usr/lib/libfastcgipp.so.2
> #5  0x081373be in Fastcgipp::Manager<controller::HttpRequest>::handler
> (
>     this=0xbf868e64) at /usr/include/fastcgi++/manager.hpp:345
> #6  0x081355cc in main () at ../src/main.cpp:80
> 
> I am not sure it this error is caused by the implementation of nginx
> or fastcgi++ or my webapplication so i would be happy if someone could
> guide me the right way to avoid this segmentation fault that hangs up
> the whole webapplication and result in a 502 Bad Gateway error by
> nginx. I use version 0.7.65 of nginx that is distributed with Ubuntu
> and the fastcgi++-2.0beta-3dab986e version of fastcgi++. If there are
> some questions that needs to be answered i am pleased to answer it.

I haven't actually tested an app when the pipe is closed, but I do know
that the signal is blocked. I'm curious if this has something to do with
your thread per request design. Fastcgi++ is really not made for thread
per request designs. In fact one of the reasons it was made was to avoid
that design. I'm not sure how stable it would be. It would certainly be
much much slower. I think most data exchange between the Manager and the
Requests is thread safe, but I don't know. Also keep in mind that
signals are very thread unsafe. Could be related. I will get around to
testing a pipe shutdown some day, but it isn't that easy to do.

Has anyone else tried a pipe close and seen how the app reacted?
-- 
        Eddie Carle