Skip Menu |
 

This queue is for tickets about the Tk CPAN distribution.

Report information
The Basics
Id: 35033
Status: open
Worked: 25 min
Priority: 0/
Queue: Tk

People
Owner: Nobody in particular
Requestors: elmex [...] ta-sa.org
rt.cpan.org [...] plan9.de
Cc:
AdminCc:

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



Subject: Tk::fileevent clears all handlers, not just the requested one
Download (untitled) / with headers
text/plain 995b
The following program: #!/usr/bin/perl use Tk; open my $fh, "+>/tmp/tktest" or die; my $mw = new MainWindow; $mw->fileevent ($fh, readable => "1"); $mw->fileevent ($fh, writable => "2"); warn $mw->fileevent ($fh, "readable"); warn $mw->fileevent ($fh, "writable"); $mw->fileevent ($fh, readable => ""); warn $mw->fileevent ($fh, "readable"); warn $mw->fileevent ($fh, "writable"); Outputs: Tk::Callback=SCALAR(0xa51950) at /tmp/tk.pl line 11. Tk::Callback=SCALAR(0x9230c0) at /tmp/tk.pl line 12. Warning: something's wrong at /tmp/tk.pl line 14. Warning: something's wrong at /tmp/tk.pl line 15. i.e. the "writable" handle gets cleared errornously, contrary to documentation, which explicitly states that readavlke and writable event handlers can be deleted seperately.
Download (untitled) / with headers
text/plain 387b
When I try this as workaround within a called fileevent handler, I get segfaults: my $r = $mw->fileevent ($self->{fh}, "readable"); my $w = $mw->fileevent ($self->{fh}, "writable"); $r = "" if $self->{poll} =~ /r/i; $w = "" if $self->{poll} =~ /w/i; $mw->fileevent ($self->{fh}, readable => $r); $mw->fileevent ($self->{fh}, writable => $w); Something is rotten here.
Download (untitled) / with headers
text/plain 192b
When I play around a lot, I sometimes don't get segfaults, but after I set the handlers to the values returned by fileevent and ask fort he handlers again, they have both been cleared again.
Download (untitled) / with headers
text/plain 796b
The subject line is a correct explanation of what happens. In the perl code the 'sub filevent' looks at return from XS call to handler. If it isn't true then it untie-s the file handle which in turn frees up the other handlers and leaves the references you saved in the workround pointing at nothing. What I think should happen is that the XS code should in the 3-arg case return NOT the callback it created (if any) as it does now, but rather the "mask" of active handlers. If the mask is zero then the untie is correct. It did not help diagnosis that your example does $mainwindow->fileevent($fh,'readable',"1"); The "1" isn't a sane callback, I am still confused by why it seems to generate a viable callback object rather than complaining. Will try and fix that at the same time.
From: rt.cpan.org [...] plan9.de
Download (untitled) / with headers
text/plain 870b
[NI-S - Sat Dec 3 15:51:20 2005]: Show quoted text
> > It did not help diagnosis that your example does
I am sorry, but fortunately the problem happens regardless of the handler. (My actual usage uses a code reference). However, I *did* assume that "1" was a correct arguemnt, as the manpage uses strings for that argument and talks about "evaluating" it, as opposed to calling it. If the interface would use more perl-ish undef and cod references and "calling" I would not have assumed that a string is a valid callback. However, even when using code references, the function does not return the same callback originally used, and the value returned cannot be used to set the callback, which is potentially another problem. Thanks for looking into this! I use it in the "AnyEvent" module, which allows module auhtors to use file events etc. in Tk, Glib and Event-based programs.
Download (untitled) / with headers
text/plain 186b
In case my last entry sounded a bit off: I _am_ sorry that I complicated debugging by mixing two seperate issues, I just wanted to say why I did it, and that I didn't do it on purpose :)
Download (untitled) / with headers
text/plain 132b
Please try attached patch. This changes return from XS part of code so that untie should only happen when last handler is deleted.
Download patch
application/octet-stream 573b

Message body not shown because it is not plain text.

Download (untitled) / with headers
text/plain 428b
[NI-S - Thu Dec 29 08:04:11 2005]: Show quoted text
> > Please try attached patch. > This changes return from XS part of code so that untie > should only happen when last handler is deleted.
I checked it against my testcases, they work fine. I also removed the workaround I had for Tk in Net::FCP and am running a daemon with hundreds of simultaneous connections all on the Tk event loop for a few minutes now - works fine, too :) Thanks!
Subject: #16246 reappeared: Tk::fileevent clears all handlers, not just the requested one
Download (untitled) / with headers
text/plain 274b
Hi! Even though the bug #16246 was resolved once it seems to be still (or again?) in the recent Tk version. This is my testcase: http://www.ta-sa.org/files/txt/b7c669b2ff74c8bfb3c57ee9c94e94f9.txt The 'READABLE' event is never detected, even though there is data waiting.
Download (untitled) / with headers
text/plain 487b
On Mon Apr 14 17:17:33 2008, ELMEX wrote: Show quoted text
> Hi! > > Even though the bug #16246 was resolved once it seems to be still (or > again?) > in the recent Tk version. > > This is my testcase: > http://www.ta-sa.org/files/txt/b7c669b2ff74c8bfb3c57ee9c94e94f9.txt > > The 'READABLE' event is never detected, even though there > is data waiting.
The patch was never applied. Does http://rt.cpan.org/Ticket/Attachment/150276/46775/patch still works for you with Tk804.028? Regards, Slaven
Download (untitled) / with headers
text/plain 756b
On Fri Sep 12 18:08:04 2008, SREZIC wrote: Show quoted text
> On Mon Apr 14 17:17:33 2008, ELMEX wrote:
> > Hi! > > > > Even though the bug #16246 was resolved once it seems to be still (or > > again?) > > in the recent Tk version. > > > > This is my testcase: > > http://www.ta-sa.org/files/txt/b7c669b2ff74c8bfb3c57ee9c94e94f9.txt > > > > The 'READABLE' event is never detected, even though there > > is data waiting.
> > The patch was never applied. Does > http://rt.cpan.org/Ticket/Attachment/150276/46775/patch > still works for you with Tk804.028? >
Unfortunately the patch makes t/leak.t fail now. Obviously the introduction of using newSViv() now created a memory leak. Need some additional investigation if and how this could be fixed. Regards, Slaven


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

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.