develooper Front page | perl.perl5.porters | Postings from December 2004

[perl #32967] [PATCH] Re: More B bugs: svref_2object

Thread Previous | Thread Next
Stephen McCamant
December 28, 2004 16:02
[perl #32967] [PATCH] Re: More B bugs: svref_2object
Message ID:
>>>>> "AT" == Alexey Tourbin <(via RT) <>> writes:

AT> Hello,

AT> Recently I reported this bug on perl5-porters mailing list.
AT> As there seems to be no immediate interest to this bug,
AT> I file it for future revision.  I assign severity=medium
AT> because reference counting mechanism seems to be affected.

AT> Brief description: consequent svref_2object calls produce wrong
AT> B objects in certain cases.  Detailed explanation and test cases
AT> are available via the following links:


I think your diagnosis is correct. The B module in general, and
svref_2object in particular, does not increase the reference count of
the SV and OP objects the B::SV and B::OP proxies point to, so bad
things happen if the proxy is used after the underlying object is
freed. (I bet with more experimentation you could get a segfault, for

However, I think the best solution is "don't do that, then". B is
intended for looking at the parse tree, which isn't generally in
danger of going away, rather than for examining transient values. It
wouldn't be out of the question to change B so that it always
SvREFCNT_inc'd the SVs it wrapped, but it would be a fairly major
change, with some tricky aspects (for instance, should it try to hide
the increased count from the B::SV:REFCNT method?). Trying to
reference count OPs would be harder, since most of them don't actually
store a reference count.

The appended documentation patch attempts to explain that one
shouldn't do what you tried to do.

 -- Stephen

---	(revision 18175)
+++	(working copy)
@@ -368,6 +368,10 @@
 way to get an initial "handle" on an internal perl data structure
 which can then be followed with the other access methods.
+The returned object will only be valid as long as the underlying OPs
+and SVs continue to exist. Do not attempt to use the object after the
+underlying structures are freed.
 =item amagic_generation
 Returns the SV object corresponding to the C variable C<amagic_generation>.
@@ -523,7 +527,11 @@
 these structures.
 Note that all access is read-only.  You cannot modify the internals by
-using this module.
+using this module. Also, note that the B::OP and B::SV objects created
+by this module are only valid for as long as the underlying objects
+exist; their creation doesn't increase the reference counts of the
+underlying objects. Trying to access the fields of a freed object will
+give incomprehensible results, or worse.

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About