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

Owner: Nobody in particular
Requestors: CHORNY [...]

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

Subject: t/poe_loop_tk/wheel_run_size.t hangs on Linux
Download (untitled) / with headers
text/plain 699b
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/ 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/ 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/ 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,
Download (untitled) / with headers
text/plain 1.2k
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: "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.

This service is sponsored and maintained by Best Practical Solutions and runs on infrastructure.

Please report any issues with to