'Assertion ((svtype)((sv)->sv_flags & 0xff)) != 0xff failed: f...'
[download]

Did you notice that you failed to ever include the actual full error message? It is a nice touch to include the call stack that you included. But I wouldn't be surprised if there is useful information that has been replaced by "f..." in what you've provided.

I did a very quick look to see if I could find this assertion. I failed to find anything in your report that was much use in pointing to a specific assertion. But I did stumble upon this part of sv.h which seems to match the expression in the part of the error message that you preserved:

/* Sadly there are some parts of the core that have pointers to alread
+y-freed
   SV heads, and rely on being able to tell that they are now free. So
+ mark
   them all by using a consistent macro.  */
#define SvIS_FREED(sv)  ((sv)->sv_flags == SVTYPEMASK)
[download]

And searching for SvIS_FREED in the 5.10.1 source code only turned up this candidate:

/* delete a back-reference to ourselves from the backref magic associa
+ted
 * with the SV we point to.
 */

STATIC void
S_sv_del_backref(pTHX_ SV *tsv, SV *sv)
{
...
    assert(!SvIS_FREED(av));
[download]

Which I'm pretty sure is code that gets run when a weak ref is destroyed. But then the evidence that this is the assertion is rather indirect (but is enough to convince me -- after I did another search for "SVTYPEMASK" and found no candidates).

Running "git grep -i weak perl-5.10.1 ext/IO" finds only the use of the word "tweak" in ext/IO/ChangeLog. So I don't see the weak ref being the fault of IO::Socket::* or IO::Handle (all of which live under ext/IO in the Perl source code).

Are you using weak references somewhere? Not that I find it easy to imagine how your use of a weak reference could matter to the call to IO::Socket::Unix->new() that you showed.

A significant number of cases of successfully fixing similarly mysterious bugs leads me to suggest the following technique (which I've seen succeed significantly more often than I've seen it fail, somewhat astonishingly):

Look through the modules that you are making use of and find the one that makes use of the most "magic". In particular, modules that make use of XS are especially good candidates. Switch to a newer or older version of that module. Even better, stop using that module. You can often replace such modules with similar modules that don't use XS.

Often this will make the error go away or just happen even less frequently. Other times, I've seen it just change the error to something that is easier to debug (sometimes because it happens much more frequently and so can be reproduced in an environment where more details can be extracted). Getting rid of XS modules usually just makes the error go away (astonishingly often).

Update: Using threads is also an easy way to trigger mysterious errors, IME. (It isn't that you can't successfully use Perl "threads"; it is that is way too easy to get bizarre error messages when using threads, errors that just go away when you stop using "threads".)