Bizarre copy of UNKNOWN in subroutine entry

Question

I'm hitting a bug in the SVN perl module when using git:

Bizarre copy of UNKNOWN in subroutine entry at 
/usr/lib/perl5/vendor_perl/SVN/Base.pm line 80.

And I'm not quite sure if this is a perl bug or a subversion bug. This is the relevant part:

# insert the accessor
if (m/(.*)_get$/) {
    my $member = $1;
    *{"${caller}::$1"} = sub {
    &{"SVN::_${pkg}::${prefix}${member}_". # <<<< line 80
          (@_ > 1 ? 'set' : 'get')} (@_)
      }
}

(full source)

What is a "Bizarre copy"? And whose fault is it?

Edit: software versions

• subversion 1.6.15-1
• perl 5.14.0-1

---

Resolution: This happens when you compile with incompatible flags:

https://groups.google.com/d/msg/subversion_users/EOru50ml6sk/5xrbu3luPk4J

Answer 1

That perldoc gives you the short answer, but a brief STFW session yields a little more detail. This is basically evidence of a smashed stack in Perl.

Trivial example:

#!/usr/bin/perl
my @A = 1..5;
sub blowUp {
   undef @A;
   my $throwAway = {};
   print for @_;       # <== line 6
}
blowUp(@A);
__END__
bash$ ./blowitup
Bizarre copy of HASH in print at ./blowitup line 6.

And to make it that much more entertaining, without the $throwAway assignment, it's an invisible error (though under 'use warnings' it will at least still tell you that you're trying to access an uninitialized value). It's just when you make a new assignment that you see the strange behavior.

Since @_ is essentially lexically scoped to the subroutine, and arguments are passed by reference, that little subroutine basically pulls the rug out from under itself by undef'ing the thing that @_ was pointing to (you get the same behavior if you change the undef to an assignment, fwiw). I've found a number of postings on perl5-porters that mention this as an artifact of the fact that items on the stack are not reference counted and therefore not cleanly freed.

So while I haven't looked through all of the code in your full source in depth, I'll go ahead and guess that something in there is messing with something that was passed in on @_ ; then when @_ is referenced again, Perl is telling you that something's rotten in Denmark.

The immediate problem is a bug in the script/module, iow. The deeper issue of Perl not reference counting these items is also there, but I suspect you'll have better luck fixing the module in the short term. :-)

HTH- Brian

Answer 2

A "Bizarre copy" occurs when Perl's stack is corrupted or contains non-scalars. It occurs as the result of bugs in Perl itself or in XS modules. (Brian Gerard's example exercises one of a long list of known bugs related to the stack not being ref-counted.)

You could isolate the problem by adding the following to the anon sub:

warn("Calling SVN::_${pkg}::${prefix}${member}_".(@_ > 1 ? 'set' : 'get')."...");

You might even want to emit a stack trace, but you might have to build it yourself using caller to avoid triggering the panic when building the stack trace.