Skip Menu |

This queue is for tickets about the POE-Loop-Tk CPAN distribution.

Report information
The Basics
Id: 82678
Status: open
Priority: 0/
Queue: POE-Loop-Tk

People
Owner: Nobody in particular
Requestors: CHORNY [...] cpan.org
Cc:
AdminCc:

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



Subject: t/poe_loop_tk/wheel_run_size.t hangs on Linux
t/poe_loop_tk/wheel_run_size.t ................ Cannot redirect into tied STDOUT. Untying it at /home/c/perl5/perlbrew/perls/perl-5.16.2/lib/site_perl/5.16.2/POE/Test/Loops/wheel_run_size.pm line 39. Use of uninitialized value $chldout in scalar chomp at /home/c/perl5/perlbrew/perls/perl-5.16.2/lib/site_perl/5.16.2/POE/Wheel/Run.pm line 617. Use of uninitialized value $chldout in string ne at /home/c/perl5/perlbrew/perls/perl-5.16.2/lib/site_perl/5.16.2/POE/Wheel/Run.pm line 618. perl: ../../src/xcb_io.c:249: process_responses: Assert «(((long) (dpy->last_request_read) - (long) (dpy->request)) <= 0)» failed. (last line is translated from Russian) -- Alexandr Ciornii, http://chorny.net
On Sun Jan 13 07:21:20 2013, CHORNY wrote: Show quoted text
> perl: ../../src/xcb_io.c:249: process_responses: Assert «(((long) > (dpy->last_request_read) - (long) (dpy->request)) <= 0)» failed. > (last line is translated from Russian)
This isn't a POE-specific problem. A web search for the assertion message reveals "About 118,000 results". It's also not limited to Tk. A lot of the web pages mentioning the error are for Gtk+ and other things. "The assertion is an X server assertion. dpy is your display. Not sure what the error is or why it appears to be associated with your sendto. xcb is the X protocol C-language Binding." This discussion seems relevant: http://gtk.10911.n7.nabble.com/Gtkmm-and-fork-td44573.html "You should call _exit() (and incidentally NOT exit()) at the end of the child process. (That is at the end of the if block representing the child process.)" _exit() is POSIX::_exit(). The pattern is that an active X connection is duplicated during a fork() or thread, and then both copies try to do something with the socket. This breaks the X protocol. As far as I can tell from reading several web pages, the solution is either (a) "don't do that" or (b) don't let one of the forks/threads use the socket. If (a) isn't an option, then I'll need a test case to reproduce the problem here.