I don't think ActiveState even compiles in threading support

They do, and have since 5.6.1. Maybe before.

Characteristics of this binary (from libperl):
  Compile-time options: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES PERL
+_IMPLICIT_CONTEXT PERL_IMPLICIT_SYS
  Locally applied patches:
        ActivePerl Build 811
        21540 Fix backward-compatibility issues in if.pm
        23565 Wrong MANIFEST.SKIP
  Built under MSWin32
  Compiled at Dec 13 2004 09:52:01
[download]

Are you using fork?

Why these questions. The error message

Attempt to free unreferenced scalar: SV 0x1e77330, Perl interpreter: 0
+x15d45fc ...
[download]

Is telling you that during garbage collection (sorry, Reference Counting Automated Memory Management Cleanup! Hereafter referred to as GC :), the Perl interpreter represented by the handle 0x15d45fc, attempted to free the scalar at location 0x1e77330 and discovered that it didn't own that piece of memory.

To my knowledge, this can only occur when a reference is passed between two separate instances of the Perl Interpreter running within the same process. And that, (to my knowledge), can only occur if you are using threads. Either explicitly through the use of threads, or (whatever that word is that means the opposite of explicitly that simply won't form in my head just now), through the use of ActivePerl's fork emulation, which uses threads.

In general, as the warning occurs during cleanup of a variable, if it happens when the program is exiting, then you can usually safely ignore it as your program is exiting anyway. If you are using a very recent version of perl, 5.8.8 or later from memory, then you can disable the warning using no warnings 'threads';. But if it occurs at some other time in the code, and particulary if you get the same message (with different scalars), repeatedly, it probably represents and memory leak.

It's also possible that the cross-interpreter-passed scalar has (silently), caused other problems that have not been detected, so it usually worth tracking the problem down to the source. To do that, you would need to post more code, preferably a minimal testcase.

Most of the above is based upon my own investigations of the problem--I've seen it a lot in my threaded code, though much less recently. I've never seen the title error occur outside of either threaded, or pseudo-forked code. By implication, there would need to be multiple interpreters involved for one of them to discover a scalar it did not own. The only way I know of to have multiple interpreters is via threads, though theoretically, if you were embedding Perl into a C program, you could create multiple interpreters without using threads. There may be other situations in which the message could occur that I am unaware of.

To my knowledge, this can only occur when a reference is passed between two separate instances of the Perl Interpreter running within the same process

All it takes is an inappropriate SvREFCNT_dec() in XS code to generate the error:

use warnings;
use Inline C => Config => BUILD_NOISY => 1;

use Inline C => <<'EOC';

SV * foo() {
     SV * y = newSViv(42);
     SvREFCNT_dec(y);
     return y;
}

EOC

foo();
[download]


Cheers,
Rob

no, I'm not using threads or fork() or even system()...nothing in that vein. I don't think any of the modules I'm using (DBI, File::Copy, List::MoreUtils, MP3::Tag) are, either. Can't say for sure though.

__________
Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.
- Terry Pratchett