Skip Menu |

This queue is for tickets about the Net-Pcap CPAN distribution.

Report information
The Basics
Id: 43308
Status: resolved
Priority: 0/
Queue: Net-Pcap

People
Owner: Nobody in particular
Requestors: franck.mail [...] dthconnex.com
Cc:
AdminCc:

Bug Information
Severity: Critical
Broken in: 0.16
Fixed in: 0.17



Subject: pcap_loop crashes when interrupted by a signal
Hello Sébastien, This makes fwknop raise a segmentation fault on i386 architectures as mentionned in: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=508432 Martin Ferrari has submitted the following patch and a test script that allows a way to easily reproduce the problem through the test.pl script. Is there any reason to allow the call of the pcap_loop to be interrupted? If the behavior has to be changed as done by the patch, I will either patch the Debian package currently in Debian Sid or import the new release if you intend to do so. Regards, --- Franck Joncourt
Subject: test.pl
#!/usr/bin/perl -w use Net::Pcap; my $err = ''; my $pcap = Net::Pcap::open_live('lo', 1024, 1, 0, \$err); Net::Pcap::loop($pcap, 10, \&process_packet, "just for the demo"); Net::Pcap::close($pcap); sub process_packet { my($user_data, $header, $packet) = @_; local $SIG{CHLD} = \&sigchld; system("echo foo"); } sub sigchld { print "SIGCHLD\n"; }
Subject: signal_handler.diff
From: Franck Joncourt <franck.mail@dthconnex.com> Subject: [PATCH] fixes/signal_handler We do not allow pcap_loop function to be interrupted by a signal. This makes fwknop raise a segmentation fault on i386 as mentionned in: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=508432 Martin Ferrari has submitted the following patch and a test script that allows a way to easily reproduce the problem. Signed-off-by: Franck Joncourt <franck.mail@dthconnex.com> --- Pcap.xs | 3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/Pcap.xs b/Pcap.xs index a49138c..ca3ad16 100644 --- a/Pcap.xs +++ b/Pcap.xs @@ -410,10 +410,7 @@ pcap_loop(p, cnt, callback, user) callback_fn = newSVsv(callback); user = newSVsv(user); - SAVE_signals = PL_signals; /* Allow the call to be interrupted by signals */ - PL_signals |= PERL_SIGNALS_UNSAFE_FLAG; RETVAL = pcap_loop(p, cnt, callback_wrapper, (u_char *)user); - PL_signals = SAVE_signals; SvREFCNT_dec(user); SvREFCNT_dec(callback_fn); -- tg: (22e6285..) fixes/signal_handler (depends on: master)
Subject: Re: [rt.cpan.org #43308] pcap_loop crashes when interrupted by a signal
Date: Mon, 16 Feb 2009 01:48:30 +0100
To: bug-Net-Pcap [...] rt.cpan.org
From: Sébastien Aperghis-Tramoni <saper [...] cpan.org>
Franck Joncourt wrote via RT: Show quoted text
> Hello Sébastien,
Hello Franck, Show quoted text
> This makes fwknop raise a segmentation fault on i386 architectures as > mentionned in: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=508432 > > Martin Ferrari has submitted the following patch and a test script > that allows a way to easily reproduce the problem through the test.pl > script. > > Is there any reason to allow the call of the pcap_loop to be > interrupted?
So that one can use alarm() and interrupt pcap_loop() with it. See CPAN-RT#6320: » http://rt.cpan.org/Public/Bug/Display.html?id=6320 Show quoted text
> If the behavior has to be changed as done by the patch, I will either > patch the Debian package currently in Debian Sid or import the new > release if you intend to do so. > > Regards, > > --- > Franck Joncourt<test.pl>From: Franck Joncourt > <franck.mail@dthconnex.com> > Subject: [PATCH] fixes/signal_handler > > We do not allow pcap_loop function to be interrupted by a signal. > > This makes fwknop raise a segmentation fault on i386 as mentionned in: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=508432 > > Martin Ferrari has submitted the following patch and a test script > that allows > a way to easily reproduce the problem.
As I already wrote in the Debian ticket, I can't reproduce the problem on Debian etch x86 using the test case Martin submitted. As I just wrote, allowing pcap_loop() to be interrupted by any signal was added on purpose. Now, something I didn't do back then was to provide a way to control whether signals are allowed to interrupt pcap_loop() and similar functions. Would that be enough for you? -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
From: martin.ferrari [...] gmail.com
On Sun Feb 15 19:48:53 2009, SAPER wrote: Show quoted text
> > Is there any reason to allow the call of the pcap_loop to be > > interrupted?
> > So that one can use alarm() and interrupt pcap_loop() with it. See > CPAN-RT#6320: > » http://rt.cpan.org/Public/Bug/Display.html?id=6320
The problem is that by setting signals to be unsafe, well.. you get crashes in perl :) Maybe an alternative would be to modify the XS code to call pcap_breakloop when a deferred signal is received, but I don't know how to do that. If you want to maintain this behaviour, I think you should put a big fat note about it in the documentation so other programmers don't assume they can do fancy things in signal handlers as they do usually with safe signals. And we then can ask the fwknop people to use my workaround. In this particular case, nothing too fancy is being done in the signal handler, but it's too complex to understand really what's going on (the actual crash seems to be a double free while exiting the scope of the signal handler) Show quoted text
> > Martin Ferrari has submitted the following patch and a test script > > that allows > > a way to easily reproduce the problem.
> > As I already wrote in the Debian ticket, I can't reproduce the > problem on Debian etch x86 using the test case Martin submitted.
Please see my other mail. Show quoted text
> As I just wrote, allowing pcap_loop() to be interrupted by any signal > was added on purpose. Now, something I didn't do back then was to > provide a way to control whether signals are allowed to interrupt > pcap_loop() and similar functions. > > Would that be enough for you?
Aside from my previous suggestion, which is for signal handlers that are invoked at any time, you could disable unsafe signals during the execution of the callback code, there's no need to have them while executing perl code.
Hi Sébastien, On Sun Feb 15 19:48:53 2009, SAPER wrote: Show quoted text
> Franck Joncourt wrote via RT:
[...] Show quoted text
> As I already wrote in the Debian ticket, I can't reproduce the > problem on Debian etch x86 using the test case Martin submitted.
If you need an access to a Debian Sid i386, I can help you :) (From Etch to Sid on amd64/i386) If you want me to do some tests and give you a feedback, let me know. Show quoted text
> As I just wrote, allowing pcap_loop() to be interrupted by any
signal Show quoted text
> was added on purpose. Now, something I didn't do back then was to > provide a way to control whether signals are allowed to interrupt > pcap_loop() and similar functions. > > Would that be enough for you?
I have sent an email to fwknop upstream to know what he thinks about all that. - update Fwknop according to the current behavior - allow a way to enable/disable interruption ... On that subject I cannot judge what is better for all of us. So at the moment, I will wait for a reply of M Rash. Regards, --- Franck Joncourt,
Subject: Re: [rt.cpan.org #43308] pcap_loop crashes when interrupted by a signal
Date: Thu, 5 Mar 2009 01:27:54 +0100
To: bug-Net-Pcap [...] rt.cpan.org
From: Sébastien Aperghis-Tramoni <saper [...] cpan.org>
Hello, Martín Ferrari wrote: Show quoted text
> The problem is that by setting signals to be unsafe, well.. you get > crashes in perl :) Maybe an alternative would be to modify the XS code > to call pcap_breakloop when a deferred signal is received, but I don't > know how to do that. > > If you want to maintain this behaviour, I think you should put a > big fat > note about it in the documentation so other programmers don't assume > they can do fancy things in signal handlers as they do usually with > safe > signals. And we then can ask the fwknop people to use my workaround.
I'd say many Perl users don't know how signals are actually handled. In fact, more than a few are surprised that signals are not immediately delivered. IIRC, I added this code to Net::Pcap because I had a couple of requests (by private mail, not on CPAN-RT) to modify Net::Pcap so it behaves this way. I also remember explaining this to a couple of colleagues, and how to enable "unsafe" signals. Also, remember that Perl5 porters have very high standards in terms of portability, safeness, correctness, etc. Right, immediate signals delivery is labelled "unsafe", but that doesn't mean that it makes Perl *that* less stable. See threads, which are still not considered production-ready by some porters, even though many people are happily using it. Finally, note that after I discussed with Rafaël Garcia-Suarez (current bleadperl pumpking) about safe/unsafe signals, he wrote Perl::Unsafe::Signals to allow an author to locally disable safe signals delivery. » http://search.cpan.org/dist/Perl-Unsafe-Signals/ Show quoted text
>> As I already wrote in the Debian ticket, I can't reproduce the >> problem on Debian etch x86 using the test case Martin submitted.
> > > Please see my other mail.
I saw. I tried on the Debian sid I installed on my PS3 (that's a PowerPC) but still can't reproduce the problem. I also tried on my machine at work, an x86-64, with no more luck. Seems to be really tied to the x86-32 architecture, or to a recent version of libpcap. -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.