Re: [fpc-pascal] How to handle External:SIGPIPE on linux

[Dennis Poon]

Ewald,

Please kindly share your sample codes for both approaches.
Thanks a lot.

Dennis

Ewald wrote:


On 31 May 2013, at 13:31, Dennis wrote:


Is there something I can do to trap this external SIGPIPE?


You might try catching the signal using fpSignal 
(http://www.freepascal.org/docs-html/rtl/baseunix/fpsignal.html and 
http://unixhelp.ed.ac.uk/CGI/man-cgi?signal+2 
http://www.freepascal.org/docs-html/rtl/baseunix/fpsignal.html%20and%20http://unixhelp.ed.ac.uk/CGI/man-cgi?signal+2) 
. I can send some example code if you want.


Or you could perhaps block this signal using pthread_sigmask 
(http://man7.org/linux/man-pages/man3/pthread_sigmask.3.html). I 
believe I have some example code of this too.


--
Ewald


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


No virus found in this message.
Checked by AVG - www.avg.com http://www.avg.com
Version: 2013.0.3343 / Virus Database: 3184/6370 - Release Date: 05/30/13

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] How to handle External:SIGPIPE on linux

[Ewald]

On 01 Jun 2013, at 08:51, Dennis Poon wrote:

 Ewald,
 
 Please kindly share your sample codes for both approaches.
 Thanks a lot

Right, here you go:

*** fpSignal() ***
First you declare a function which is going to handle the signal (SignalHandler 
in my example), then you just call 
fpSignal(SIGPIPE, @SignalHandler);
 
An example program:

===code begin===
Program SignalTest;

Uses sysutils, baseunix;

Procedure SignalHandler(SigNo: cint); cdecl;
Begin
If SigNo = SIGPIPE Then WriteLn('Received SIGPIPE.');
End;

Begin
fpSignal(SIGPIPE, @SignalHandler);

while true do sleep(5000);
End.
===code end===

Compile using `fpc SignalTest.pas`. Whilst running it, try sending SIGPIPE to 
it (`killall -PIPE SignalTest`) and it should write something to stdout.


***pthread_sigmask()***

It basically comes down to:
- Emtying a signal set
- Adding the signals you wish to block
- Calling pthread_sigmask with this set and SIG_BLOCK as arguments.

And example program:

===code begin===
Program SigmaskTest;

Uses sysutils, baseunix, pthreads;

Var
ToBeBlocked: sigset_t;
Begin
fpSigEmptySet(ToBeBlocked);
fpsigaddset(ToBeBlocked, SIGPIPE);
pthread_sigmask(SIG_BLOCK, @ToBeBlocked, nil);

while true do sleep(5000);
End.
===code end===

Compile using `fpc SigmaskTest.pas`. Whilst running it, try sending SIGPIPE to 
it (`killall -PIPE SigmaskTest `) and it should continue running.

NOTE: this function will need to be called by each thread that wishes to block 
this signal, except in the case where the parent thread already has this signal 
blocked, as newly created threads inherit their parents sigmask (according to 
http://linux.die.net/man/3/pthread_sigmask)

Hope it helps! 

--
Ewald

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] How to handle External:SIGPIPE on linux

[waldo kitty]

On 5/31/2013 07:31, Dennis wrote:

I am using LNet 's SSL sockets on ubuntu.
When I use a self signed certificate and the browser gets a warning, it seems
the browser immediately send a close-notify or shutdown ssl signal to the server
and then without waiting close the connection.


sadly, this is common practice... in a firewall product i work with, we called 
the traffic afterward a spurious firewall hit because the firewall logged the 
traffic which came after the connection was already terminated... most of the 
time, this traffic was termination acknowledgment...


this problem can originate in the other direction as well... the server may 
close the connection without waiting on the client to acknowledge... both cases 
can be problematic (eg: spurious firewall hit)



On my server side (written with Lnet  SSL), it did not know the connection was
closed already and still thinking of handling the close-notify + shutdown tries
to shutdown the SSL on its side and then encounter the serious PIPE error (which
I guess it tries to send acknowledge of the close-notify/shutdown back to the
browser) when the pip is already closed.  I guess Lnet SSL implementation is not
aware that the other side can close the connection without waiting for its
acknowledgement.


sounds like it...


This external SIGPIPE immediately crash the program even though the original
Lnet codes has a try except block.

Is there something I can do to trap this external SIGPIPE?

(I tried emaillng the author but no response for weeks).


i have no idea... i only wanted to provide confirmation of the practice as 
mentioned above...


--
NOTE: No off-list assistance is given without prior approval.
  Please keep mailing list traffic on the list unless
  private contact is specifically requested and granted.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal