Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#2020 Function _set_invalid_parameter_handler does not exist in MSVCRT.DLL

WSL
pending
Earnie Boyd
needs test (57)
Bug
none
Feature_in_WSL_4.1
False
2014-08-24
2013-08-28
Earnie Boyd
No

Windows 8 may have this, I don't know but Windows 7 doesn't. We need to at least use MSVCRT_VERSION or perhaps some other macro.

Discussion

  • David Librik
    David Librik
    2013-09-05

    I've figured out what's going on. The problem here has nothing to do with Windows 8 vs. 7.

    _set_invalid_parameter_handler was introduced in Visual C++ 2005, and only appears in MSVCR80.DLL and later. (So it is in MSVCR90.DLL, MSVCR90D.DLL, MSVCR100.DLL, etc.) Therefore the symbol should only appear in libmsvcr90.a and above.

    Unfortunately it was added -- by mistake -- to earlier MinGW import libraries in /lib. It is in libmsvcrt.a, libmsvcrtd.a, libmsvcr70.a, libmsvcr70d.a. The first of these is especially a problem because it is the default library for MinGW GCC. It needs to be removed from those libraries, because the corresponding DLLs do not export it.

    This error is causing all current MinGW builds of Bison (Yacc), a standard Unix tool, to crash at startup.

     
    • Earnie Boyd
      Earnie Boyd
      2013-09-19

      The problem here has nothing to do with Windows 8 vs. 7.

      We care about the Windows version supplying msvcrt.dll and whether or not a symbol is supplied by MSVCRT.DLL. The other DLL are not guaranteed to exist on Windows OS and present us with a differing issue of memory clobbering that requires one to muck with the GCC specs to get correct. Just wanted to make clear that problems have everything to do with a Windows OS version.

      Unfortunately it was added -- by mistake -- to earlier MinGW import libraries in /lib. It is in libmsvcrt.a, libmsvcrtd.a, libmsvcr70.a, libmsvcr70d.a. The first of these is especially a problem because it is the default library for MinGW GCC. It needs to be removed from those libraries, because the corresponding DLLs do not export it.

      In version 5.0 I plan to break this apart and supply different .def files instead of the one .def.in file. It will be easier for us to get the symbols correct per the versioned libraries. At some point GCC needs to be able to handle a user request to use these libraries gracefully within a common GCC spec file.

      This error is causing all current MinGW builds of Bison (Yacc), a standard Unix tool, to crash at startup.

      I'll use these to test my changes which for 4.1 may be a complete removal of the symbol from the header and library file but I'll try to avoid removing it from libmsvcr80 and above.

       
  • David Librik
    David Librik
    2013-09-05

    Specifically:

    The symbol should continue to appear in libmsvcr80.a, libmsvcr80d.a, libmsvcr90.a, libmsvcr90d.a, libmsvcr100.a, libmsvcr100d.a.

    It should be removed from libmsvcrt.a, libmsvcrtd.a, libmsvcr70.a, libmsvcr70d.a, libmsvcr71.a, libmsvcr71d.a.

    (This is true for both the _set_invalid_parameter_handler symbol and its import stub, but I assume that will automatically be handled by the tools that build the libmsvcr*.a import libraries.)

     
  • Earnie Boyd
    Earnie Boyd
    2013-09-19

    I've created a __MINGW_MSVCR_PREREQ(runtime) macro function to test that __MSVC_RUNTIME__ is defined and greater than or equal to (runtime). I then changed stdlib.h to use that macro to declare the _set_invalid_parameter_handler function. The plan will be to let GCC define __MSVC_RUNTIME__ version based on a -msvc=## or similar switch controlled via the specs which will also control the linker library specification. Until then the user will -D__MSVC_RUNTIME__=## in the CFLAGS.

     
  • Earnie Boyd
    Earnie Boyd
    2013-09-19

    • labels: --> needs test
    • status: assigned --> pending
    • Resolution: later --> fixed
     
  • JensG
    JensG
    2014-07-19

    Hi,

    maybe dumb question, but which version do I have to use to get that thing fixed? Is it yet released or what does "fixed, needs test" imply? Is there a nightly build, maybe?

     
    Last edit: JensG 2014-07-19
  • Keith Marshall
    Keith Marshall
    2014-07-19

    • Resolution: fixed --> none
     
  • Keith Marshall
    Keith Marshall
    2014-07-19

    He says he fixed it, but I'm not convinced. All his faffing aside, the fundamental problem is that he gratuitously -- and extremely foolishly -- removed all of the version specific filters from the msvcrt.def.in file, (which is what defines the content for all variants of libmsvcr*.a); the correct solution is to reinstate those filters, and he most definitely has not done so; until he does, this cannot be classified as fixed.

    This problem was not apparent in mingwrt-3.20, (where exposure of the offending symbol is correctly restricted to msvcr80.dll and greater numbered variants); I suggest you continue to use that.

     
    Last edit: Keith Marshall 2014-07-19