Skip Menu |

This queue is for tickets about the POE CPAN distribution.

Report information
The Basics
Id: 4524
Status: resolved
Priority: 0/
Queue: POE

People
Owner: SUNGO [...] cpan.org
Requestors: apocalypse [...] 0ne.us
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Date: Sat, 29 Nov 2003 04:38:25 -0500
From: Apocalypse <apocalypse [...] 0ne.us>
To: bug-POE [...] rt.cpan.org
Subject: POE::Wheel::ReadLine not working perfectly
The program will simply wait until I pressed two keys, then somehow lock up doing select()'s all over the map... Using POE's TRACE_DEFAULT method, I was unable to pinpoint the error, other than seeing the select's scroll up the screen after pressing a second key... I've reduced the problem to this minimal program: # Standard stuff to catch errors use strict qw(subs vars refs); # Make sure we can't mess up use warnings FATAL => 'all'; # Enable warnings to catch errors # Turn on extensive debugging sub POE::Kernel::ASSERT_DEFAULT () { 1 } sub POE::Session::ASSERT_STATES () { 1 } sub POE::Kernel::TRACE_DEFAULT () { 1 } # Use POE! use POE; use POE::Wheel::ReadLine; # Create the session POE::Session->create( 'inline_states' => { '_start' => \&SetupWheel, '_stop' => sub {}, 'Got_Input' => \&GotInput, }, ); POE::Kernel->run; # Setup the wheel sub SetupWheel { my $heap = $_[ HEAP ]; # Create the wheel. $heap->{wheel} = POE::Wheel::ReadLine->new( InputEvent => 'Got_Input' ); # Trigger the wheel to read a line of input. $heap->{wheel}->get( 'Prompt: ' ); } # Input handler. If $input is defined, then it contains a line of # input. Otherwise $exception contains a word describing some kind # of user exception. Currently these are 'interrupt' and 'cancel'. sub GotInput { my ($heap, $input, $exception) = @_[HEAP, ARG0, ARG1]; if (defined $input) { $heap->{wheel}->put("\tGot: $input"); $heap->{wheel}->get('Prompt: '); # get another line } else { $heap->{wheel}->put("\tException: $exception"); } } -- Apocalypse Homepage: http://JiNxEdStAr.0ne.us IRC: Apocalypse@irc.perl.org IRC: Apocal@EFnet CPAN ID: APOCAL
I posted a non-POE test case to the mailing list a couple weeks ago. I received a good amount of feedback: So far I have six (6) failure reports: Terminal settings are probably not at fault. The "stty -a" reports (in and out of canonical mode) are consistent with a BSD system where the test case works. An interesting coincidence comes up in the "perl -V" output. Four (4) systems are running identical versions of Perl, built on identical versions of Red Hat Linux: gccversion='3.2.2 20030222 (Red Hat Linux 3.2.2-5)' osvers=2.4.21-1.1931.2.382.entsmp perl5 (revision 5.0 version 8 subversion 0) An historical failure report in POE's RT queue include: gccversion='3.2.3 20030422 (Gentoo Linux 1.4 3.2.3-r1, propolice)' osvers=2.4.20-gentoo-r5 perl5 (revision 5.0 version 8 subversion 0) Another, without perl -V output This is perl, v5.8.0 built for i386-linux-thread-multi (with 1 registered patch, see perl -V for more detail) Linux 2.4.20-18.9smp And a couple reports of working versions: gccversion='3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6)' osvers=2.4.26-gentoo-r9 perl5 (revision 5 version 8 subversion 4) gccversion='3.3.3 (Debian 20040314)' osvers=2.4.25-ti1211 perl5 (revision 5.0 version 8 subversion 3) So, what could it be? - It's usually (but not always) attributed to Red Hat Linux. Gentoo also fails. - It may be localized to Linux kernels 2.4.20 - 2.4.21. - It may be localized to Perl 5.8.0, but I couldn't reproduce the problem on FreeBSD with 5.8.0 (with or without iThreads). - It may be localized to gcc 3.2.2 - 3.2.3. - Dear gods, I hope it's not a combination of factors! Things to try: - Try a different version of Perl on the affected systems. - Gather good data points to rule out kernel, perl, and gcc versions.