Unusual copy of UNKNOWN in a routine

Question

I hit an error in the perl SVN 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 error or a subversion error. This is an important 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 Unusual Copy? And whose fault is it?

Edit: software version

• subversion 1.6.15-1
• perl 5.14.0-1

---

Resolution: This happens when compiling with incompatible flags:

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

Answer 1

This perldoc gives you a short answer, but a short STFW session gives a little more detail. This basically indicates a broken 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 much more interesting, without assigning $ throwAway, this is an invisible error (although in the "Usage Warnings" section, it will at least show you that you are trying to access an uninitialized value). It's just that when you do a new task, you see strange behavior.

Since @_ is essentially lexically bound to the subroutine, and the arguments are passed by reference, this small subroutine basically pulls the carpet from underneath itself, discarding what @_ points to (you get the same behavior if you change undef to the destination , fwiw). I found several posts on perl5 porters that mention this as an artifact that the items on the stack do not count and therefore are not cleared.

So, until I have looked through all the code in your full source in depth, I will go further and guess that something is messing with something that was transferred to @_; then when @_ is referenced again, Perl tells you that something is rotting in Denmark.

The immediate problem is an error in the script / iow module. There is also a deeper Perl problem not referring to these elements, but I suspect that you will be able to install the module faster in the near future. :-)

HTH- Brian

Answer 2

A "Unusual copy" occurs when the Perl stack is damaged or contains non-calculators. This happens as a result of errors in Perl itself or in XS modules. (The Brian Gerard example performs one of a long list of known errors related to the fact that the stack is not recounted.)

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

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

You might want to release a stack trace, but you may have to create one yourself using caller to avoid panic when building a stack trace.

Answer 3

Probably a perl error. SVN :: Base has XS components, but an error occurs in pure pearl code, and I believe that perl should never allow this to happen. However, it is possible that SVN :: Base has some kind of weird XS that sets it up.

Best idea: file with subcomponent subversion bindings_swig_perl and perlbug both.