Bug #3789 for POE-Exceptions: POE::Exceptions tests and sig

Mon Sep 15 10:31:38 2003 gbjk [...] thermeon.com - Ticket created

From:	"Gareth Kirwan" <gbjk [...] thermeoneurope.com>
To:	<eek+cpan [...] eekeek.org>, <bug-POE-Exceptions [...] rt.cpan.org>, <sungo [...] cpan.org>
Subject:	POE::Exceptions tests and sig_handled
Date:	Mon, 15 Sep 2003 15:33:33 +0100

When using POE::Exceptions I noticed that the DIE handler was acting as if it didn't return 1. After checking I noted that now I should be using $_[KERNEL]->sig_handler. I was directed to look at the tests, and at that point I realised what the problem seems to be. abdigation.t ( http://search.cpan.org/src/SUNGO/POE-Exceptions-0.02/t/abdigation.t ) doesn't test a signal handler returning that it handled the signal with sig_handled. It's just there to test that if a handler doesn't return handled then the eval picks it up. signal_handler.t ( http://search.cpan.org/src/SUNGO/POE-Exceptions-0.02/t/signal_handler.t ) doesn't check that the unhandled exception it's catching with the eval is the second die: die "this die will be handled, too"; and not the first one: die "this die should be handled"; I added a check at the bottom and $@ is reporting an unhandled exception for the first die, which should have been reported as handled by the sig_handled at the end of &death_handled. In other words: 1) On my system it seems that $_[KERNEL]->sig_handled() isn't stopping the programme from bailing after than handler has been run ( and it is run ). 2) The tests don't catch this eventuallity. System is: Linux 2.4.18-14 with Perl 5.8.0. POE works okay on it's own so far. I hope the information I've given is correct. Thanks for your time. Gareth Kirwan Programming & Development, Thermeon Europe Ltd, gbjk@thermeoneurope.com Tel: +44 (0) 1293 864 303 Thermeon Europe e-Card: gbjk

Mon Oct 06 21:46:20 2003 SUNGO [...] cpan.org - Taken

Mon Oct 06 21:55:09 2003 SUNGO [...] cpan.org - Correspondence added

[gbjk@thermeoneurope.com - Mon Sep 15 10:31:38 2003]: Show quoted text

> abdigation.t ( > http://search.cpan.org/src/SUNGO/POE-Exceptions-0.02/t/abdigation.t ) > doesn't test a signal handler returning that it handled the signal with > sig_handled. > It's just there to test that if a handler doesn't return handled then the > eval picks it up.

yes, that's what the name of the test file is supposed to indicate. this test file is not testing for what you want it to. it is testing whether abdigating its signal handling works. the proper place for this test is in signal_handler.t Show quoted text

> signal_handler.t ( > http://search.cpan.org/src/SUNGO/POE-Exceptions-0.02/t/signal_handler.t ) > doesn't check that the unhandled exception it's catching with the eval is

good catch. will be fixing this shortly. Show quoted text

> In other words: > 1) On my system it seems that $_[KERNEL]->sig_handled() isn't stopping the > programme from bailing after than handler has been run ( and it is run ). > 2) The tests don't catch this eventuallity.

well, i was operating on the assumption that poe's signal handling stuff works. i will write tests to see where the problem is but if sig_handled is failing, there's not a lot i'm going to be able to do to this module to fix it.

Tue Oct 07 00:16:11 2003 SUNGO [...] cpan.org - Status changed from 'new' to 'open'

Tue Oct 07 00:16:11 2003 SUNGO [...] cpan.org - Correspondence added

i've committed code to hopefully fix the problem and improve signal_handler.t to catch the problem if it crops up again. can i talk you into grabbing a cvs checkout and testing to see if it behaves as you expect? thanks.

Wed Oct 08 04:43:14 2003 Guest - Correspondence added

From:

gbjk

Show quoted text

> can i talk you into grabbing a cvs checkout and testing to see if it > behaves as you expect?

Not a problem... what CVS server ? I've checked the sourceforge one and couldn't see this module there. G

Wed Oct 08 05:40:44 2003 Guest - Correspondence added

Gotcha... sungo.sf.net. http://sourceforge.net/cvs/?group_id=82784 However the cvs server is neither responding to the web version or a normal cvs login. G

Wed Oct 08 09:26:25 2003 SUNGO [...] cpan.org - Correspondence added

[guest - Wed Oct 8 05:40:44 2003]: Show quoted text

> > However the cvs server is neither responding to the web version or a > normal cvs login.

sf.net cvs is known to be kinda twitchy about anonymous cvs. it'll work eventually tho

Thu Oct 09 12:10:55 2003 Guest - Correspondence added

New issue. When I press ctrl+c to kill a daemon running in the foreground I get: Use of uninitialized value in delete at /usr/local/lib/perl5/site_perl/5.8.0/POE/Resource/SIDs.pm li ne 76. The daemon does not then die. If I have POE::Exceptions loaded. If I don't I don't get an error. Example attached.

#!/usr/bin/perl -w use strict; use Socket qw(inet_ntoa); use constant PORT => 32800; use Inslink; use POE::Exceptions; use POE::Wheel::SocketFactory; use POE::Wheel::ReadWrite; use POE::Filter::Line; use POE::Driver::SysRW; use POE::Component::Client::HTTP; use POE; POE::Session->create( inline_states => { _start => \&server_start, _stop => \&server_stop }, ); $poe_kernel->run(); exit; sub server_start { $_[HEAP]->{listener} = POE::Wheel::SocketFactory->new( BindAddress => '127.0.0.1', BindPort => PORT, Reuse => 'yes', SuccessEvent => 'accept_new_client', FailureEvent => 'accept_failed' ); print "SERVER: Started listening on port ". PORT ."\n"; } sub server_stop { print "SERVER: Stopped.\n"; } sub accept_new_client { my ($socket, $peeraddr, $peerport) = @_[ARG0..ARG2]; $peeraddr = inet_ntoa($peeraddr); my $child = POE::Session->new( _start => \&child_start, _stop => \&child_stop, ); print "SERVER: Got connection from $peeraddr:$peerport.\n"; } sub accept_failed { my ($function, $error) = @_[ARG0, ARG2]; delete $_[HEAP]->{listener}; print "SERVER: call to $function() failed: $error.\n"; } sub child_start { } sub child_stop { }

Sat Apr 17 09:25:45 2004 SUNGO [...] cpan.org - Status changed from 'open' to 'resolved'

Bug #3789 for POE-Exceptions: POE::Exceptions tests and sig_handled