Re: [Fastcgipp-users] SIGPIPE causes SEGFAULT

[Volker Schreiner]

I checked the databaseExample and experienced the same behaviour. If i
use apache benchmark and cause nginx to generate a SIGPIPE signal the
example database application
also causes an segmentation fault:

#0  0x00541087 in ?? () from /usr/lib/libfastcgipp.so.2
#1  0x00528fce in Fastcgipp::Transceiver::Buffer::freeRead
(this=0xb3c117f8, size=16) at transceiver.cpp:177
#2  0x0052954f in Fastcgipp::Transceiver::transmit (this=0xbfbadac4) at
transceiver.cpp:43
#3  0x00524d7d in Fastcgipp::Request<wchar_t>::complete() () from
/usr/lib/libfastcgipp.so.2
#4  0x0052566f in Fastcgipp::Request<wchar_t>::handler() () from
/usr/lib/libfastcgipp.so.2
#5  0x0813aa49 in Fastcgipp::Manager<Database>::handler
(this=0xbfbadac4) at /usr/local/include/fastcgi++/manager.hpp:345
#6  0x08137d61 in main () at ../src/main.cpp:281

So it seems that this is a problem of the blocked SIGPIPE signal and not
a problem of my
thread per request design.

Am 09.11.2010 02:31, schrieb 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?
>