Skip Menu |

This queue is for tickets about the Want CPAN distribution.

Report information
The Basics
Id: 2196
Status: open
Priority: 0/
Queue: Want

People
Owner: robin [...] cpan.org
Requestors: schwern [...] pobox.com
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in:
  • 0.01
  • 0.02
  • 0.03
  • 0.04
  • 0.05
  • 0.06
  • 0.07
Fixed in: 0.09



Subject: want() bus error inside tie, also require v5.6
require v5.6 is not backwards compatible and will simply be a syntax error on earlier versions of Perl which kinda defeats the purpose. The attached patch changes it to 5.006. And the real problem... trying to use want() inside the FETCH() method of a tied scalar causes a bus error. The attached patch demonstrates the bug (t/tie.t). I get the same result with both OS X's default 5.6.0 and a 5.8.0 I built myself. Here's the strack trace from running tie.t under gdb with perl 5.8.0 on OS X. $ gdb perl5.8.0 GNU gdb 5.3-20021014 (Apple version gdb-250) (Sat Dec 7 02:14:27 GMT 2002) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "powerpc-apple-macos10". Reading symbols for shared libraries .. done (gdb) set args -Mblib t/tie.t (gdb) run Starting program: /usr/local/bin/perl5.8.0 -Mblib t/tie.t [Switching to process 4925 thread 0xb03] Reading symbols for shared libraries . done Reading symbols for shared libraries ... done Reading symbols for shared libraries . done Reading symbols for shared libraries . done 1..2 ok 1 Program received signal EXC_BAD_ACCESS, Could not access memory. XS_Want_parent_op_name (cv=0x0) at Want.xs:132 132 U16 i = l->length; (gdb) bt #0 XS_Want_parent_op_name (cv=0x0) at Want.xs:132 #1 0x0035c6a0 in Perl_pp_entersub () at pp_hot.c:2773 #2 0x00342b8c in Perl_runops_debug () at dump.c:1398 #3 0x002e7858 in Perl_call_sv (sv=0x3f752c, flags=64) at perl.c:1924 #4 0x0034e59c in S_magic_methpack (sv=0x3f3eb4, mg=0x1162cc, meth=0x40 <Address 0x40 out of bounds>) at mg.c:1329 #5 0x0034d840 in Perl_magic_getpack (sv=0x0, mg=0xf52d0) at mg.c:1342 #6 0x00348334 in Perl_mg_get (sv=0xc103c) at mg.c:124 #7 0x0036338c in Perl_sv_2bool (sv=0xc103c) at sv.c:3305 #8 0x0035db3c in Perl_pp_or () at pp_hot.c:315 #9 0x00342b8c in Perl_runops_debug () at dump.c:1398 #10 0x002e73b0 in S_run_body (oldscope=313128) at perl.c:1681 #11 0x002e6ef8 in perl_run (my_perl=0x0) at perl.c:1600 #12 0x000027a0 in main (argc=3, argv=0xbffffbbc, env=0x2) at perlmain.c:85 #13 0x00002490 in _start (argc=3, argv=0xbffffbbc, envp=0xbffffbcc) at /SourceCache/Csu/Csu-45/crt.c:267 #14 0x00002310 in start () (gdb)
--- Want.pm 2003/03/08 16:06:29 1.1 +++ Want.pm 2003/03/08 16:06:42 @@ -1,6 +1,6 @@ package Want; -require v5.6; +require 5.006; use Carp 'croak'; use strict; use warnings; @@ -12,7 +12,7 @@ our @EXPORT = qw(want rreturn lnoreturn); our @EXPORT_OK = qw(want howmany wantref); -our $VERSION = '0.05'; +our $VERSION = '0.051'; bootstrap Want $VERSION; --- MANIFEST 2003/03/08 16:16:15 1.1 +++ MANIFEST 2003/03/08 16:16:30 @@ -10,3 +10,4 @@ t/boolean.t t/err.t t/object.t +t/tie.t --- t/tie.t 2003/03/08 16:16:23 1.1 +++ t/tie.t 2003/03/08 16:16:26 @@ -0,0 +1,17 @@ +#!/usr/bin/perl -w + +use Test; +plan tests => 2; + +{ + package Foo::Tie; + use Want; + + sub TIESCALAR { return bless \[] } + sub FETCH { return want('BOOL') ? 1 : 0 } + sub STORE { } +} + +ok( tie $foo, 'Foo::Tie' ); + +ok( $foo || 0 );
From: danboo [...] cpan.org
[MSCHWERN - Sat Mar 8 11:25:37 2003]: Show quoted text
> > And the real problem... trying to use want() inside the FETCH() method > of a tied scalar causes a bus error. The attached patch > demonstrates the bug (t/tie.t). I get the same result with both OS > X's default 5.6.0 and a 5.8.0 I built myself. >
I ran into the same issue inside FETCH() for tied hashes. It seems related to tied methods not using entersub ops (see below). As near as I can tell, on line 215 from Want.xs (version 0.7) 'return_op' ends up being equal to 0. This eventually leads to a segfault in attempting to get the length of an oplist (Want.xs:132). Maybe I can learn a bit more about perl ops and submit a patch, but until then I thought I'd share what I'd figured out. Fixing this could lead to some really nice tied dwimmery. - Dan Boorstein segfault, implicit version: 10:25 PM danboo ~ $ perl -MO=Concise -MWant -e 'sub TIEHASH { bless {} } sub FETCH { want("REF") } tie %foo, "main"; $foo{bar} ' d <@> leave[1 ref] vKP/REFC ->(end) 1 <0> enter ->2 2 <;> nextstate(main 321 -e:1) v ->3 7 <@> tie vK/2 ->8 3 <0> pushmark s ->4 5 <1> rv2hv[t1] sKRM/1 ->6 4 <$> gv(*foo) s ->5 6 <$> const(PV "main") s ->7 8 <;> nextstate(main 321 -e:1) v ->9 c <2> helem vK/2 ->d a <1> rv2hv sKR/1 ->b 9 <$> gv(*foo) s ->a b <$> const(PVIV "bar") s/BARE ->c working, explicit version: 10:25 PM danboo ~ $ perl -MO=Concise -MWant -e 'sub TIEHASH { bless {} } sub FETCH { want("REF") } tie %foo, "main"; (tied %foo)->FETCH' f <@> leave[1 ref] vKP/REFC ->(end) 1 <0> enter ->2 2 <;> nextstate(main 321 -e:1) v ->3 7 <@> tie vK/2 ->8 3 <0> pushmark s ->4 5 <1> rv2hv[t1] sKRM/1 ->6 4 <$> gv(*foo) s ->5 6 <$> const(PV "main") s ->7 8 <;> nextstate(main 321 -e:1) v ->9 e <1> entersub[t3] vKS/TARG ->f 9 <0> pushmark s ->a c <1> tied sKPM/1 ->d b <1> rv2hv[t2] sKRM/1 ->c a <$> gv(*foo) s ->b d <$> method_named(PVIV "FETCH") ->e
This is a known bug, which seems to be impossible to fix. (At least, I can't think of a way to fix it.) In Want 0.09, it gives an error message rather than a segfault.
If it's fixed, could this be marked closed?
On Wed Nov 19 19:52:48 2014, ETJ wrote: Show quoted text
> If it's fixed, could this be marked closed?
I don’t think it is fixed. The original poster’s tie example crashes for me in 0.23.
On Wed Nov 19 21:08:24 2014, SPROUT wrote: Show quoted text
> On Wed Nov 19 19:52:48 2014, ETJ wrote:
> > If it's fixed, could this be marked closed?
> > I don’t think it is fixed. The original poster’s tie example crashes > for me in 0.23.
I think to find the equivalent of return_op, you would need to search the savestack and look for SAVEt_OP. To do that, you would have to make a list of all SAVEt_ types and their sizes, which vary between perl versions. That doesn’t sound like fun. :-(