Bug #19386 for POE: Perl 5.8.0: POE becomes unresponsive with only signals and selects

Sun May 21 10:24:48 2006 Guest - Ticket created

Subject:

Perl 5.8.0: POE becomes unresponsive with only signals and selects

For some reason, I'm seeing POE go into an unresponsive state when it has signals live (INT and TERM in my case) and selects (in this case a Wheel::ReadWrite wrapping a serial port. If there are other things like timers (Most of the time I have some keepalive timers) around, the signals and such seem to be responsive, but POE goes into a dead state and becomes unresponsive if it's ONLY the signals and serial port. Would it be possible to write some form of test script which tests this case (the unresponsive to signals case). For now, POE on 5.8.0 passes tests, and if there IS a problem on 5.8.0, it would be very useful to be able to create a test that fails, so 5.8.0 can be ruled out as a bad platform. It's one thing to warn in IRC that "5.8.0 is no guarentees" but it would be better if we could test for the case.

Sun May 21 21:46:17 2006 RCAPUTO [...] cpan.org - Correspondence added

On Sun May 21 10:24:48 2006, guest wrote: Show quoted text

> For some reason, I'm seeing POE go into an unresponsive state when it > has signals live (INT and TERM in my case) and selects (in this case a > Wheel::ReadWrite wrapping a serial port. > > If there are other things like timers (Most of the time I have some > keepalive timers) around, the signals and such seem to be responsive, > but POE goes into a dead state and becomes unresponsive if it's ONLY the > signals and serial port. > > Would it be possible to write some form of test script which tests this > case (the unresponsive to signals case). > > For now, POE on 5.8.0 passes tests, and if there IS a problem on 5.8.0, > it would be very useful to be able to create a test that fails, so 5.8.0 > can be ruled out as a bad platform. > > It's one thing to warn in IRC that "5.8.0 is no guarentees" but it would > be better if we could test for the case.

You're the person most likely to tell us whether a test case is possible. You have the system that's failing, and the code that fails. I could take a stab at writing a test case, but I have no frame of reference from which to start, so it's probably just a waste of time. How we react to the test case depends on where the fault lies. If it's in Perl, we'll have something that demonstrates empirically that 5.8.0 is considered harmful. If it's in POE, we should try to work around the issue as best as possible. That may mean throwing runtime errors when certain features are used on 5.8.0.

Sun May 21 21:46:18 2006 The RT System itself - Status changed from 'new' to 'open'

Sun May 21 22:09:05 2006 adam [...] phase-n.com - Correspondence added

Subject:	Re: [rt.cpan.org #19386] Perl 5.8.0: POE becomes unresponsive with only signals and selects
Date:	Mon, 22 May 2006 12:12:54 +1000
To:	bug-POE [...] rt.cpan.org
From:	Adam Kennedy <adam [...] phase-n.com>

Indeed. But I'm wondering where to start... there's some basics I might be able to try, but it could take quite a lot of time to find it, so I'm wondering if you know to what level of depth things like signals or idleness, or whatever, are tested. It's hard to decode the test scripts, they mostly seem to test internals and don't actually test whether the various sigs work... I think... Adam K via RT wrote: Show quoted text

> <URL: http://rt.cpan.org/Ticket/Display.html?id=19386 > > > On Sun May 21 10:24:48 2006, guest wrote:

>> For some reason, I'm seeing POE go into an unresponsive state when it >> has signals live (INT and TERM in my case) and selects (in this case a >> Wheel::ReadWrite wrapping a serial port. >> >> If there are other things like timers (Most of the time I have some >> keepalive timers) around, the signals and such seem to be responsive, >> but POE goes into a dead state and becomes unresponsive if it's ONLY the >> signals and serial port. >> >> Would it be possible to write some form of test script which tests this >> case (the unresponsive to signals case). >> >> For now, POE on 5.8.0 passes tests, and if there IS a problem on 5.8.0, >> it would be very useful to be able to create a test that fails, so 5.8.0 >> can be ruled out as a bad platform. >> >> It's one thing to warn in IRC that "5.8.0 is no guarentees" but it would >> be better if we could test for the case.

> > You're the person most likely to tell us whether a test case is > possible. You have the system that's failing, and the code that fails. > I could take a stab at writing a test case, but I have no frame of > reference from which to start, so it's probably just a waste of time. > > How we react to the test case depends on where the fault lies. If it's > in Perl, we'll have something that demonstrates empirically that 5.8.0 > is considered harmful. > > If it's in POE, we should try to work around the issue as best as > possible. That may mean throwing runtime errors when certain features > are used on 5.8.0.

Tue Jun 13 10:28:18 2006 RCAPUTO [...] cpan.org - Correspondence added

Fair enough. A start would be to turn on TRACE_DEFAULT and redirect the copious amount of debugging information to a file. Stop the program after it has reached the unresponsive state, and then isolate the state change in the log. Attach maybe 50KB of log leading up to the point where the program became unresponsive, and a few iterations of the main loop afterwards. That might show the cause of the state change, and it'll let me know the execution pattern afterwards. I probably can't solve the issue directly from that, but I may be able to direct you to look at specific things. On Sun May 21 22:09:05 2006, adam@phase-n.com wrote: Show quoted text

> Indeed. > > But I'm wondering where to start... there's some basics I might be able > to try, but it could take quite a lot of time to find it, so I'm > wondering if you know to what level of depth things like signals or > idleness, or whatever, are tested. > > It's hard to decode the test scripts, they mostly seem to test internals > and don't actually test whether the various sigs work... I think...

Mon Sep 18 15:43:41 2006 APOCAL [...] cpan.org - Status changed from 'open' to 'stalled'

Thu Oct 19 01:25:39 2006 RCAPUTO [...] cpan.org - Correspondence added

No testcase or feedback from requester. Can't reproduce the problem or fix it. Perl 5.8.0 sucks anyway. Ticket is rejected.

Thu Oct 19 01:25:40 2006 The RT System itself - Status changed from 'stalled' to 'open'

Thu Oct 19 01:25:41 2006 RCAPUTO [...] cpan.org - Status changed from 'open' to 'rejected'