Actually no, I can't. I have spent a few days trying to pin it down but when I have found a location and change the script the bug just pops up somewhere else. When I thought that the unichar errors were significant I kept adding checks that packed and unpacked strings, once the check was in place the crash would appear somewhere "nearby".

The behaviour "feels like" a memory corruption in a low level C library. There are also the facts that:

• the same script runs on both Linux and Solaris with no problems
• all modules have use strict;use warnings;
• this problem only appeared after the dll was changed

The script does use XML, encryption, sockets and all sorts of other stuff. I tried to create a simple version that exhibits the behaviour but couldn't. No doubt there is some interaction between those that is causing it.

I did play with both forking and threading in earlier versions, but I failed to create a version that exploited them and remained portable, so I dropped that bit.