Tk::Event::IO::fileevent() corrupts inheritted IO::Sockets

[p5pRT]

Migrated from rt.perl.org#3235 (status was 'resolved')

Searchable as RT3235$

[p5pRT]

From gavin.brock@nssmb.com

Created by zaragoza@usa.net

The following code fails​:

package Foo; use IO​::Socket; use base qw(IO​::Socket​::INET);

sub new {   my ($pack\,$tk) = @​_;   my $obj = $pack->SUPER​::new(Proto => 'udp');

  $$obj->{Foo_prop1} = "value1"; # OK\, foo's property   $tk->fileevent($obj\, 'readable'\, sub {warn "FooBar"});

  ## The above line badly ties the object\,   ## so the following line fails   $$obj->{Foo_prop2} = "value2";

  return $obj; }

package main; my $tk = Tk​::MainWindow->new(); my $foo = Foo->new($tk); Tk​::MainLoop;

Error​:   Can't locate object method "FETCH" via package "Tk​::Event​::IO" at ./test.pl line 14.

I can work arroun this\, by duping my $obj as a IO​::Handle\, but it's ugly. Why does Tk tie my $obj without asking?

Cheers\, Gavin

Perl Info

``` Site configuration information for perl 5.00503: Configured by jonathon at Tue Mar 30 09:51:19 JST 1999. Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration: Platform: osname=solaris, osvers=2.5.1, archname=sun4-solaris uname='sunos pueblo 5.5.1 generic_103640-22 sun4u sparc sunw,ultra-1 ' hint=previous, useposix=true, d_sigaction=define usethreads=undef useperlio=undef d_sfio=undef Compiler: cc='gcc', optimize='-O', gccversion=2.8.1 cppflags='-DPURIFY -DPACK_MALLOC -DTWO_POT_OPTIMIZE -I/usr/local/include' ccflags ='-DPACK_MALLOC -DTWO_POT_OPTIMIZE -I/usr/local/include' stdchar='unsigned char', d_stdstdio=define, usevfork=false intsize=4, longsize=4, ptrsize=4, doublesize=8 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 alignbytes=8, usemymalloc=y, prototype=define Linker and Libraries: ld='gcc', ldflags =' -L/usr/local/lib' libpth=/lib /usr/lib /usr/ccs/lib /usr/local/lib libs=-lsocket -lnsl -ldl -lm -lc -lcrypt libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' ' cccdlflags='-fPIC', lddlflags='-G -L/usr/local/lib' Locally applied patches: @INC for perl 5.00503: /home/user/gb83196/perl/lib/ /home/sb/perl5.005/sparc-sunos5/lib /home/sb/perl5.005/share/lib /home/sb/perl5.005/sparc-sunos5/lib/site_perl /home/sb/perl5.005/sparc-sunos5/lib/site_perl/ph /home/sb/perl5.005/share/lib/site_perl . Environment for perl 5.00503: HOME=/home/user/gb83196 LANG (unset) LANGUAGE (unset) LD_LIBRARY_PATH=/home/user/gb83196/rvplayer:/usr/dt/lib LOGDIR (unset) PATH=/usr/dt/bin:/usr/openwin/bin:/usr/bin:/usr/ccs/bin:/usr/ucb:/usr/local/bin:/usr/share/local/bin:/opt/bin:/home/sb/perl5.005/share/bin:/home/sb/perl5.005/sparc-sunos5/bin:/usr/sbin PERLLIB=/home/user/gb83196/perl/lib/ PERL_BADLANG (unset) SHELL=/home/user/gb83196/bin/sun5/tcsh ```

[p5pRT]

From [Unknown Contact. See original ticket]

Gavin Brock \zaragoza@​usa\.net writes​:

This is a bug report for perl from zaragoza@​usa.net\, generated with the help of perlbug 1.26 running under perl 5.00503.

----------------------------------------------------------------- [Please enter your report here]

The following code fails​:

package Foo; use IO​::Socket; use base qw(IO​::Socket​::INET);

sub new { my ($pack\,$tk) = @​_; my $obj = $pack->SUPER​::new(Proto => 'udp');

$$obj->{Foo_prop1} = "value1"; # OK\, foo's property $tk->fileevent($obj\, 'readable'\, sub {warn "FooBar"});

## The above line badly ties the object\,

It does not "badly tie" it it ties it with TIEHANDLE.

I can work arroun this\, by duping my $obj as a IO​::Handle\, but it's ugly.

You could also work round it by defining :

sub Tk​::Event​::IO​::FETCH { my ($globref\,$key) = @​_; ... }

Why does Tk tie my $obj

So that​: A. if you close() the handle I get a chance to remove the thing   from data structures before Tk crashes due to access to no longer   valid file handle. B. if you attempt to read() more than is there I can   despatch Tk events while waiting.

without asking?

So what should I do ? - popup a dialogue

  ->messageBox(-message => "May I tie $obj"\, -type => 'YesNo')  

You have (via the fileevent call) "given" the object to Tk. So you "asked me" to "look after this object" ;-)

[p5pRT]

From [Unknown Contact. See original ticket]

Nick Ing-Simmons writes​:

## The above line badly ties the object\,

It does not "badly tie" it it ties it with TIEHANDLE.

Which is not expected\, thus bad.

I can work arroun this\, by duping my $obj as a IO​::Handle\, but it's ugly.

You could also work round it by defining :

sub Tk​::Event​::IO​::FETCH {

If so\, this should have been done by Tk itself. But I doubt it.

  $tk->fileevent($obj\, 'readable'\, sub {warn "FooBar"});

$obj is probably a glob ref\, right?

  $$obj->{Foo_prop1} = "value1";

$obj is a hash ref ref\, right? I'm confused.

Unles a glob can work as a hash ref in the above syntax\, and you tie the glob ref instead of the glob.

Ilya

[p5pRT]

From [Unknown Contact. See original ticket]

Ilya Zakharevich \ilya@​math\.ohio\-state\.edu writes​:

Nick Ing-Simmons writes​:

## The above line badly ties the object\,

It does not "badly tie" it it ties it with TIEHANDLE.

Which is not expected\, thus bad.

fileevent is passed a filehandle - it happens to implement its behaviour by tie-ing that handle.

I can work arroun this\, by duping my $obj as a IO​::Handle\, but it's ugly.

You could also work round it by defining :

sub Tk​::Event​::IO​::FETCH {

If so\, this should have been done by Tk itself.

Why - Tk was expecting to be passed a file handle (globref) - it was not expecting calling code to be messing with glob elements via that ref. FETCH would presumably have to handle SCALAR\, ARRAY and HASH elements of the glob - I was not even aware that tie'ing the glob (as a HANDLE) has any effects on the other elements.

$tk->fileevent($obj\, 'readable'\, sub {warn "FooBar"});

$obj is probably a glob ref\, right?

Yes.

$$obj->{Foo_prop1} = "value1";

$obj is a hash ref ref\, right? I'm confused.

Unles a glob can work as a hash ref in the above syntax\, and you tie the glob ref instead of the glob.

I assumed that syntax is messing with the hash part of the glob via the reference. Doing that is asking for trouble when multiple modules are involved (IO​::Socket\, Tk​::Event​::IO\, ...) and user has found that trouble ;-)

[p5pRT]

From [Unknown Contact. See original ticket]

On Sat\, May 13\, 2000 at 10​:41​:15AM +0100\, Nick Ing-Simmons wrote​:

It does not "badly tie" it it ties it with TIEHANDLE.

Which is not expected\, thus bad.

fileevent is passed a filehandle - it happens to implement its behaviour by tie-ing that handle.

You could also work round it by defining :

sub Tk​::Event​::IO​::FETCH {

If so\, this should have been done by Tk itself.

Why - Tk was expecting to be passed a file handle (globref) - it was not   ^^^^^^^ expecting calling code to be messing with glob elements via that ref.   ^^^^^^^^^

... and *this* is a bug.

If Tk meeds messing with the FH\, it should be messing with IO part of the glob\, not with the glob as a whole.

Ilya

[p5pRT]

From [Unknown Contact. See original ticket]

Ilya Zakharevich \ilya@​math\.ohio\-state\.edu writes​:

On Sat\, May 13\, 2000 at 10​:41​:15AM +0100\, Nick Ing-Simmons wrote​:

It does not "badly tie" it it ties it with TIEHANDLE.

Which is not expected\, thus bad.

fileevent is passed a filehandle - it happens to implement its behaviour by tie-ing that handle.

You could also work round it by defining :

sub Tk​::Event​::IO​::FETCH {

If so\, this should have been done by Tk itself.

Why - Tk was expecting to be passed a file handle (globref) - it was not ^^^^^^^ expecting calling code to be messing with glob elements via that ref. ^^^^^^^^^

... and *this* is a bug.

If Tk meeds messing with the FH\, it should be messing with IO part of the glob\, not with the glob as a whole.

Ok. But as far as I am aware you have to pass a glob to tie to achieve TIEHANDLE behaviour.

What I have at present is​:

sub fileevent { my ($widget\,$file\,$mode\,$cb) = @​_; my $imode = imode($mode); unless (ref $file)   {   no strict 'refs';   $file = Symbol​::qualify($file\,(caller)[0]);   $file = \*{$file};   } my $obj = tied(*$file); $obj = tie *$file\,'Tk​::Event​::IO'\, $file unless $obj && $obj->isa('Tk​::Event​::IO'); if (@​_ == 3)   {   return $obj->handler($imode);   } else   {   my $h = $obj->handler($imode\,$cb);   undef $obj;   untie *$file unless $h;   } }

I will gladly change that to any incantation which will effect a tie of the incoming HANDLE so that I can intercept close()\, readline() read() etc.

[p5pRT]

From [Unknown Contact. See original ticket]

On Sat\, May 13\, 2000 at 02​:59​:37PM +0100\, Nick Ing-Simmons wrote​:

If Tk meeds messing with the FH\, it should be messing with IO part of the glob\, not with the glob as a whole.

Ok. But as far as I am aware you have to pass a glob to tie to achieve TIEHANDLE behaviour.

Then *this* is a bug. ;-) Or if it is not\, the fact that tiehandle()ing messes the SCALAR etc. parts is a bug.

my $obj = tied(*$file); $obj = tie *$file\,'Tk​::Event​::IO'\, $file unless $obj && $obj->isa('Tk​::Event​::IO');

No warning on re-tie()ing? [Not that it will help in the discussed case...]

Ilya

[p5pRT]

From [Unknown Contact. See original ticket]

Ilya Zakharevich (lists.p5p)​:

Then *this* is a bug. ;-)

I seriously hate to say this\, but in the past two days you have identified seven bugs and fixed zero.

[p5pRT]

From [Unknown Contact. See original ticket]

Simon Cozens writes​:

Then *this* is a bug. ;-)

I seriously hate to say this\, but in the past two days you have identified seven bugs and fixed zero.

And your point is "So shut up"? Sorry\, but you need to have more credentials that what you have for me to listen to such an advice.

And BTW\, this is going to continue. I'm not interested much in perl development any more. And I do not consider this as *my* fault.

Hope this helps\, Ilya

[p5pRT]

From [Unknown Contact. See original ticket]

Nick\, Ilya\,

I sent a reply on this thread a while back\, but it seems to have disappeared. The highlight was that when I defined my own Tk​::Event​::IO​::FETCH sub\, it turned out that is was the scalar tie fetch (not the hash one) that was being called. Once this was defined "sub Tk​::Event​::IO​::Fetch { $_[0] }" all worked fine under 5.005. No other function (eg STORE) were required.

However\, I then tested under 5.6.0\, when I tried to access the hash key in the DESTROY sub\, I got the following​:

(in cleanup) Can't call method "FETCH" on an undefined value at test.pl line 21 during global destruction.

Below is the perl-bug output for my 5.6 build.

Cheers\,

Gavin

Perl Info

``` Flags: category=core severity=low Site configuration information for perl v5.6.0: Configured by jonathon at Tue Apr 18 15:42:45 JST 2000. Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration: Platform: osname=solaris, osvers=2.5.1, archname=sun4-solaris uname='sunos pueblo 5.5.1 generic_103640-31 sun4u sparc sunw,ultra-2 ' config_args='' hint=previous, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=undef d_sfio=undef uselargefiles=define use64bitint=undef use64bitall=undef uselongdouble=undef usesocks=undef Compiler: cc='gcc', optimize='-O', gccversion=2.95.2 19991024 (release) cppflags='-DPACK_MALLOC -DTWO_POT_OPTIMIZE -fno-strict-aliasing -I/usr/local/include' ccflags ='-DPACK_MALLOC -DTWO_POT_OPTIMIZE -fno-strict-aliasing -I/usr/local/include' stdchar='unsigned char', d_stdstdio=define, usevfork=false intsize=4, longsize=4, ptrsize=4, doublesize=8 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=4 alignbytes=8, usemymalloc=y, prototype=define Linker and Libraries: ld='gcc', ldflags ='-L/usr/local/lib -R/usr/local/lib ' libpth=/lib /usr/lib /usr/ccs/lib /usr/local/lib libs=-lsocket -lnsl -ldb -ldl -lm -lc -lcrypt -lsec libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' ' cccdlflags='-fPIC', lddlflags='-G -L/usr/local/lib -R/usr/local/lib' Locally applied patches: @INC for perl v5.6.0: /home/user/gb83196/perl/lib/ /opt/perl5.6/lib/5.6.0/sun4-solaris /opt/perl5.6/lib/5.6.0 /opt/perl5.6/lib/site_perl/5.6.0/sun4-solaris /opt/perl5.6/lib/site_perl/5.6.0 /opt/perl5.6/lib/site_perl . Environment for perl v5.6.0: HOME=/home/user/gb83196 LANG (unset) LANGUAGE (unset) LD_LIBRARY_PATH=/home/user/gb83196/rvplayer:/usr/dt/lib LOGDIR (unset) PATH=/home/user/gb83196/bin:/home/sb/teknekron/tss_root/rel_s4_5x/bin:/usr/d t/bin:/usr/openwin/bin:/usr/bin:/usr/ccs/bin:/usr/ucb:/usr/local/bin:/usr/sh are/local/bin:/opt/bin:.:/home/user/gb83196/bin:/home/user/gb83196/private-b in:/home/sb/perl5.005/share/bin:/home/sb/perl5.005/sparc-sunos5/bin:/usr/sbi n:/xenv/java/sun4/5.x/1.1.3/bin:/home/user/gb83196/rvplayer PERLLIB=/home/user/gb83196/perl/lib/ PERL_BADLANG (unset) SHELL=/home/user/gb83196/bin/sun5//tcsh ```

[p5pRT]

From [Unknown Contact. See original ticket]

On Sun\, May 14\, 2000 at 11​:12​:56PM +0900\, Gavin Brock wrote​:

I sent a reply on this thread a while back\, but it seems to have disappeared. The highlight was that when I defined my own Tk​::Event​::IO​::FETCH sub\, it turned out that is was the scalar tie fetch (not the hash one) that was being called. Once this was defined "sub Tk​::Event​::IO​::Fetch { $_[0] }" all worked fine under 5.005. No other function (eg STORE) were required.

Here is the problem​:

perl -MDevel​::Peek -wle "sub a​::TIEHANDLE {bless []} tie *x\,'a'; Dump \*x" SV = RV(0x5b814) at 0x40c94   REFCNT = 1   FLAGS = (TEMP\,ROK)   RV = 0x319d0   SV = PVGV(0x3e7c0) at 0x319d0   REFCNT = 4   FLAGS = (GMG\,SMG\,RMG\,MULTI)   IV = 0   NV = 0   MAGIC = 0x84518   MG_VIRTUAL = &vtbl_packelem   [...]

There is no reason why this tie should have set SMG and RMG flags.

Ilya

[p5pRT]

From @chorny

On perl 5.14.0\, output is "FLAGS = (MULTI\,IN_PAD)" and example from the first message of ticket does not die.

On Sun May 14 02​:48​:14 2000\, RT_System wrote​:

On Sun\, May 14\, 2000 at 11​:12​:56PM +0900\, Gavin Brock wrote​:

I sent a reply on this thread a while back\, but it seems to have disappeared. The highlight was that when I defined my own Tk​::Event​::IO​::FETCH sub\, it turned out that is was the scalar tie fetch (not the hash one) that was being called. Once this was defined "sub Tk​::Event​::IO​::Fetch { $_[0] }" all worked fine under 5.005. No other function (eg STORE) were required.

Here is the problem​:

perl -MDevel​::Peek -wle "sub a​::TIEHANDLE {bless []} tie *x\,'a'; Dump \*x" SV = RV(0x5b814) at 0x40c94 REFCNT = 1 FLAGS = (TEMP\,ROK) RV = 0x319d0 SV = PVGV(0x3e7c0) at 0x319d0 REFCNT = 4 FLAGS = (GMG\,SMG\,RMG\,MULTI) IV = 0 NV = 0 MAGIC = 0x84518 MG_VIRTUAL = &vtbl_packelem [...]

There is no reason why this tie should have set SMG and RMG flags.

Ilya

-- Alexandr Ciornii\, http​://chorny.net

[p5pRT]

@iabyn - Status changed from 'open' to 'resolved'

[p5pRT]

From gavin@brock-family.org

Thanks Alexandr\, never expect to see this old one show up again!! Have to go and find out why I wanted it again...