That assert also appears in sv_clear().

Indeed! In fact, that assertion is likely the culprit. I previously missed that line from my "git grep SVTYPEMASK perl-5.10.1" output.

But now I realize that the assertion that I pointed out can't be the one that is to blame because it uses "!(...==...)" which might well get changed by the optimizer into "...!=..." but such an optimization would not impact the string that the C preprocessor produces and that gets included in the error message.

So the "weak ref" stuff was a red herring.

So this bug is a little more mundane. We have a scalar with a ref count of 0 that has been freed that is trying to be cleared again. Eliminating XS modules (or up- or down-grading them) can still be useful, but is not as likely to matter as with the more mysterious scenario of a rogue weak ref being destroyed, IME.

The smell of this bug is becoming more similar to "subtle bugs in Perl that only seem to appear in long-running Perl daemons". So the bug might stop happening if the daemon can be made to run something like:

    exec( $^X, $0, @ARGV );
    die "Couldn't exec self: $!";
[download]

Every so often (like once per day).

Update: Use of "threads" still seems plausible as a major contributing factor.