But i don't use semaphores, only locks (i'm locking Object-InsideOut type object). I assume that perlish locks are implemented using low level semaphores?

Yes. A condition variable is a C struct containing a count of the threads waiting, and a semaphore handle:

typedef struct win32_cond { LONG waiters; HANDLE sem; } perl_cond;
[download]

When a condition variable is garbage collected (DESTROYed), the semaphore handle is closed, then the memory for the struct is freed. The panic you are seeing is occurring when the attempt to close the semaphore handle fails. The only way I can see this happening is if there is a second attempt to DESTROY a condition variable that has previously been destroyed.

That would put the root cause of problem outside of the realms of your code firmly in the auspices of Perl/threads::shared. But that doesn't help you solve or work around your problem; nor does it give the maintainers any clue as to the circumstances under which the bug is occurring.

The only long-term viable way forward that I see, is for you to remove as much of the proprietary code and dependencies from the code as you can, whilst retaining the flow that causes the bug to occur, and then post that. Odds are that this would allow us to find a workaround that you could fold back into your proprietary code; and give the maintainers a testcase on which to base a future fix.

Looking at the change history for threads::shared, there were changes relating to shared object destruction in the latest build (which you are using), and earlier in version 1.33. My first step would be to downgrade thread::shared on your installation to version 1.32 and see if that 'fixes' the problem.

But for a long term fix, you should really consider trying to come up with a cut-down testcase for the problem, that you have permission to publish. (The smaller the better!).