Re: ActivePerl dies in msvcrt.dll under Windows

Can you provide some details or examples of the code in your script that triggers the crash? It's very hard to diagnose the problem without it. If you can cut down the code or walk through it in the debugger to the precise point that it crashes, that might shed some light.

As a side note, are you forking? That has shown some issues in Windows (since it really isn't a fork, but a new thread.) See Perl forking and shared memory strangeness under Windows as an example.

-xdg

Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

Comment on Re: ActivePerl dies in msvcrt.dll under Windows

Replies are listed 'Best First'.
Re^2: ActivePerl dies in msvcrt.dll under Windows by hawtin (Prior) on Nov 28, 2005 at 20:45 UTC
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.	[reply]

Replies are listed 'Best First'.

Re^2: ActivePerl dies in msvcrt.dll under Windows
by hawtin (Prior) on Nov 28, 2005 at 20:45 UTC

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.

[reply]