Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery
 
PerlMonks  

ActivePerl dies in msvcrt.dll under Windows

by hawtin (Prior)
on Nov 28, 2005 at 13:52 UTC ( [id://512176]=perlquestion: print w/replies, xml ) Need Help??

hawtin has asked for the wisdom of the Perl Monks concerning the following question:

I am having difficulty running a script under ActivePerl 5.8.7 (both build 813 and 815). Running normally it works perfectly but under the debugger (i.e. with -d) I get a message "Perl Command Line Interpreter has encountered a problem and needs to closed. We are sorry for the inconvenience... Please tell Microsoft about this problem" The error message blames a Microsoft DLL:

  AppName: perl.exe
  AppVer: 5.8.7.815	 
  ModName: msvcrt.dll
  ModVer: 7.0.2600.2180
  Offset: 000373dc

The msvcrt.dll has FileVer: (7.0:2600.2180) and ProdVer: (6.1:8638.2180). I am running Windows XP Professional Version 2002 Service Pack 2.

Has anyone else seen this? Is there something I can do?

I am not a Windows expert, but the DLL would seem to control the virtual terminal (in which I am running the script of course). The msvcrt.dll appears to have been upgraded recently (my company practices remote upgrading of our systems, probably to stop us getting bored). I thought I could use the previous msvcrt.dll under which I never saw the error, but I can't get perl to use a different version from the OS, and if I change the one in the windows directory the OS refuses to startup.

Very occasionally instead of a Windows crash I get a debugger message:

  

Malformed  UTF-8  character  (unexpected   continuation  byte  0x97,  with  no
  preceding start byte) in substitution iterator at C:/Perl/lib/Carp/Heavy.pm
  line 61. 
Malformed UTF-8 character (unexpected  non-continuation byte 0x03, immediately
  after start byte 0xc8) in substitution iterator at  C:/Perl/lib/Carp/Heavy.pm
  line 61.
    ...

Originally I thought that the XML parsing (done via XML::SAX) was causing the problem so I put in code to check all the XML as it was being read, but that had no effect. Switching between XML::SAX::Expat and XML::SAX::ExpatXS caused the place where the problem manifested to change but didn't fix it. I now think that the loading of shared libraries is moving the bug so this message is a red herring.

Can anyone shed any light?

Replies are listed 'Best First'.
Re: ActivePerl dies in msvcrt.dll under Windows
by xdg (Monsignor) on Nov 28, 2005 at 15:40 UTC

    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.

      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.

Re: ActivePerl dies in msvcrt.dll under Windows
by thundergnat (Deacon) on Nov 28, 2005 at 19:25 UTC

    I'm not sure I have useful advice, but some observations.

    msvcrt.dll is the MicroSoft Visual C run time dynamic link library. The main run time library for programs compiled with Microsoft Visual C.

    If your Perl installation worked correctly with the previous version of msvcrt.dll, try putting a copy in the perl/bin directory. The perl interpreter will use the one in its' local directory rather than using the system version/copy.

    That should (may) solve the problem locally. You may still have issues if you need to distribute your script to other systems.

      The name makes sense, I assume that ActivePerl is compiled with Visual C then.

      I tried putting a version of the dll in:

      • The perl bin directory
      • Another bin directory early in my path
      • The local directory
      • My local lib (where a whole load of modules live)

      The program still dies and the error message always shows that the msvcrt.dll that is in C:/windows/system32 is the one that dies. As I mentioned in desperation I tried changing that but the OS refuses to boot

      So, yes I agree that is how I thought that DLLs worked under Windows, but for this case my understanding was wrong

      Since I am always running in the Command window I wondered if that is loading up the DLL and then refusing to dislodge it with an earlier version? As I said I am no Windows expert

        Since I am always running in the Command window I wondered if that is loading up the DLL and then refusing to dislodge it with an earlier version?

        No. That will not be the cause.

        When you placed your dll in these directories, did you also ensure that the directory in question also appeared earlier in the path than the c:\windows\system32?

        The only reason why it would favour the windows\system32 copy over the others paths, is if the former appears earlier in the path. For more information, see the link in Re: Perl/TK application and DLL hell on Win32, and the quote in Re^3: Perl/TK application and DLL hell on Win32.

        I've just tried this with the 5 different versions of msvcrt.dll that I found on my system dating from 1999 through to 2004, and they all worked (for a cursory test) in conjunction with Perl5.8.7 (AS813).

        There is another way that might help you resolve the issues involved, though I wouldn't recommend it for production use.

        If you rename the old dll to some other name (sticking to 6 characters) and then binary edit both perl.exe & perl58.dll (once in the former and twice in the latter. MAKE BACKUPS FIRST!!!), to change the references to 'mscvrt' to whatever name you gave the old version, you will ensure that only that old dll will be used.

        Again, I just tried this with the oldest and newest versions of msvcrt on my system, and binary edited copies of perl5.8.7.exe and perl58.exe from as813, and they all passed cursory testing of using pack & unpack on unicode data.

        If ensuring that you pick up the old version of the dll doesn't fix your problem, you will need to provide a cut down version to demonstrate it, or load up a binary debugger to find out what in your code starts the chain to the point of failure.


        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
Re: ActivePerl dies in msvcrt.dll under Windows
by randyk (Parson) on Nov 29, 2005 at 05:57 UTC
    Might any of the XS-based modules that your script uses been compiled with a compiler other than VC++ 6? Or perhaps an external library that a module relies on? This in principle can lead to problems. For example, using modules compiled with VC++ 7 with ActivePerl (which is compiled with VC++ 6) will load two different C runtime libraries (msvcrt.dll and msvcrt7x.dll). While this might not be a problem most of the time, there can be instances where a conflict arises - for example, using one of the dlls to allocate some memory and then later using the other to try to free it.

      Might any of the XS-based modules that your script uses been compiled with a compiler other than VC++ 6?

      That sounds extremely likely, it feels about right. I'll have a play

      Thanks

Re: ActivePerl dies in msvcrt.dll under Windows
by JamesNC (Chaplain) on Nov 29, 2005 at 00:43 UTC
    Without some example code, I would guess that the data you are feeding the parser does not have a valid UTF-8 signature. I am pretty sure it has nothing to do with the dll you are referring to. Instead it likely a bug not handled very gracefully in one of the routines in one of the modules you require. ( Again, no script, no ideas). Try using Encode to make sure you have the correct encoding on all your strings. Or, try removing all UTF-8 encodings. Did you try running your code in the debugger?

    JamesNC

      Running normally it works perfectly but under the debugger...

      There are no bugs (or crashes) unless I am running under the debugger. I tried a number of varients of encode/decode and the script also works perfectly on Solaris and Linux (with exactly the same source data)

        I worded that part pooly, I meant the UTF in the debugger, did that look fine too? ( you might examine with pack/unpack ), If it does, then create a bug on ActivePerl's site, it is free and quick to set up an account.
        JamesNC
Re: ActivePerl dies in msvcrt.dll under Windows
by Anonymous Monk on Nov 29, 2005 at 15:37 UTC
    Hawtin, msvcrt.dll is _M_icro_S_oft _V_isual _C_(++) _R_un _T_ime .dll :) mmmmnn... acronyms are yummy... One thing to try is this -- put the version you'd like Perl to use in the /perl/bin folder, as windows happily attempts to provide the .dll file first in the application's folder, and then in the system directory. Good luck!

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://512176]
Approved by Corion
Front-paged by TStanley
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others meditating upon the Monastery: (8)
As of 2024-03-28 15:02 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found