So claiming before that it most definitely was in threads->detach is simply not true. At least not by itself.

I have severe criticism on the implementation of threads in Perl. You will find some of it at Things you need to know before programming Perl ithreads. And I too have been frustrated at the seemingly random way of crashing that threaded Perl programs sometimes have. But in the end, there's a reason for it: by using threads, it just becomes an order of magnitude harder to trace and fix.

When you're debugging threaded programs, you need to develop a brain that can run several processes simultaneously, which is pretty hard if you're used to just needing to follow a single process' logic. At every point in your code, you need to make sure that there can not be another thread intervening.

Some (core) libraries may not be there yet. libnet may be one of them.

One final note: since you seem to be using Activestate's Perl (I'm assuming here, since you said you downloaded a binary for Win32), it may be wise to also alert ActiveState of your problem as well: most of the Win32 Perl expertise is located at ActiveState, and interaction with p5p has recently become what I would call "suboptimal".

One more final note: don't count on it being fixed for 5.8.3. Nicholas Clark has indicated that only stable bug fixes will be allowed in at this point. Without even an indication of the cause of the problem, I don't think a bug fix will be stable enough to be deemed ok by Nick. On the bright side: I wouldn't be surprised if the problem is in libnet, which would imply a version of CPAN (or ActiveState's ppm repository) could become available quickly after the problem has been found and fixed.

Liz