develooper Front page | perl.perl5.porters | Postings from February 2003

Re: odd (or not so odd?) segmentation fault in 5.8.0

Thread Previous | Thread Next
From:
Mark Mielke
Date:
February 17, 2003 07:59
Subject:
Re: odd (or not so odd?) segmentation fault in 5.8.0
Message ID:
20030217160751.GA6339@mark.mielke.cc
On Mon, Feb 17, 2003 at 11:15:57AM +0000, Dave Mitchell wrote:
> On Mon, Feb 17, 2003 at 02:14:59AM +0200, Enache Adrian wrote:
> > I expected from it to:
> > 1. print '(1) (1) (1)' ... 
> > 2. go in some crazy loop.
> Before proceeding, mg_get() saves, then turns off, any magic associated
> with the SV  - I guess to avoid recursive crazy loops like you mention.
> This is why 'untie $a', and '$a' have no magical effect within
> FETCH().

Fair enough. I wasn't horribly surprised of this.

> The cause of the original coredump was that *a = \1 was immediately
> freeing the tied scalar, since things pushed onto the stack aren't
> refcounted. You can (almost) achieve similar effects with code like
>     $a = 1; f($a);
>     sub f { *a = \1; do_something_with($_[0]) }

I'm certain that it must be related, however, it isn't obvious to me why
the following code has the same effect:

    sub TIESCALAR { bless [] }
    sub FETCH     { *b = *a; *a = \ 1 }
    tie($a, __PACKAGE__);
    print $a;

Shouldn't the additional reference count from $b keep $a from being freed,
and if so, why does mg_get() fail? (Or is a different piece of code dumping
core in this case?)

> except that av_fetch() has explicit code it in such that when it
> tries to retrieve element n from @_, it checks that its a freed scalar,
> and if so, returns undef instead. This is pure hackery since sometimes the
> sv may have since been reassigned.

I suppose this is one more example as to why reference counting isn't
obviously the better solution to garbage collection than algorithms such
as mark & sweep. Reference counting has a cost, and in certain places,
reference counting is purposefully neglected under the justification of
'performance', and therefore holes exist that scenarios such as the above
can fall prey to.

It would be nice to be able to set up demand-loadable scalars just as
it is possible to set up demand-loadable subroutines, however, if it
looks like this will just be too much trouble, I'll stop asking
embarassing questions. :-)

mark

-- 
mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
|\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   | 
|  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada

  One ring to rule them all, one ring to find them, one ring to bring them all
                       and in the darkness bind them...

                           http://mark.mielke.cc/


Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About