C++ 使用SWIG和MinGW创建的Lua模块导致解释器在退出时崩溃

我有以下文件：

你好。h

#ifndef HELLO_H
#define HELLO_H

class Hello {
    private:
        int _number;

    public:
        Hello(int number);
        void printHello(void) const;
};

#endif

你好。cpp

#include "hello.h"
#include <iostream>

Hello::Hello(int number)
    : _number(number) {
}

void Hello::printHello(void) const {
    std::cout << "Hello, " << this->_number << std::endl;
}

CMakeLists.txt

CMAKE_MINIMUM_REQUIRED(VERSION 2.8)
FIND_PACKAGE(Lua51)
INCLUDE_DIRECTORIES(${LUA_INCLUDE_DIR})
ADD_LIBRARY(
    "hello"
    SHARED
    "hello_wrap.cxx"
    "hello.cpp"
)
TARGET_LINK_LIBRARIES(hello "${LUA_LIBRARIES}")
SET_TARGET_PROPERTIES(hello PROPERTIES PREFIX "")

我使用SWIG生成hello_wrap.cxx，然后通过CMake创建MinGW makefile，并构建它们。这将导致hello.dll

打开lua解释器，我键入：

hello=require('hello')
inst=hello.Hello(23)
inst:printHello()

正如预期的那样，它会按我的要求打印出“Hello，23”，因此模块加载似乎工作正常

然而，当我这样做时：

os.exit()

我得到以下错误：

"This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information."

然后是lua.exe崩溃。当我简单地执行以下操作时，也会发生这种情况：

hello=require('hello')
os.exit()

有人知道我该如何解决这个问题吗

提前谢谢

编辑：以下是depends.exe在通过lua.exe运行test.lua和问题行时生成的输出

***************************| Module Dependency Tree |***************************
*                                                                              *
* Legend: F  Forwarded Module   ?  Missing Module        6  64-bit Module      *
*         D  Delay Load Module  !  Invalid Module                              *
*         *  Dynamic Module     E  Import/Export Mismatch or Load Failure      *
*                               ^  Duplicate Module                            *
*                                                                              *
********************************************************************************

[   ] LUA.EXE
     [   ] KERNEL32.DLL
          [   ] API-MS-WIN-CORE-RTLSUPPORT-L1-1-0.DLL
          [   ] NTDLL.DLL
          [   ] KERNELBASE.DLL
               [ ^ ] NTDLL.DLL
          [   ] API-MS-WIN-CORE-PROCESSTHREADS-L1-1-0.DLL
          [   ] API-MS-WIN-CORE-HEAP-L1-1-0.DLL
          [   ] API-MS-WIN-CORE-MEMORY-L1-1-0.DLL
          [   ] API-MS-WIN-CORE-HANDLE-L1-1-0.DLL
          [   ] API-MS-WIN-CORE-SYNCH-L1-1-0.DLL
          [   ] API-MS-WIN-CORE-FILE-L1-1-0.DLL
          [   ] API-MS-WIN-CORE-IO-L1-1-0.DLL
          [   ] API-MS-WIN-CORE-THREADPOOL-L1-1-0.DLL
          [   ] API-MS-WIN-CORE-LIBRARYLOADER-L1-1-0.DLL
          [   ] API-MS-WIN-CORE-NAMEDPIPE-L1-1-0.DLL
          [   ] API-MS-WIN-CORE-MISC-L1-1-0.DLL
          [   ] API-MS-WIN-CORE-SYSINFO-L1-1-0.DLL
          [   ] API-MS-WIN-CORE-LOCALIZATION-L1-1-0.DLL
          [   ] API-MS-WIN-CORE-PROCESSENVIRONMENT-L1-1-0.DLL
          [   ] API-MS-WIN-CORE-STRING-L1-1-0.DLL
          [   ] API-MS-WIN-CORE-DEBUG-L1-1-0.DLL
          [   ] API-MS-WIN-CORE-ERRORHANDLING-L1-1-0.DLL
          [   ] API-MS-WIN-CORE-FIBERS-L1-1-0.DLL
          [   ] API-MS-WIN-CORE-UTIL-L1-1-0.DLL
          [   ] API-MS-WIN-CORE-PROFILE-L1-1-0.DLL
          [   ] API-MS-WIN-SECURITY-BASE-L1-1-0.DLL
          [F^ ] NTDLL.DLL
     [   ] MSVCRT.DLL
          [ ^ ] KERNELBASE.DLL
          [ ^ ] NTDLL.DLL
          [   ] API-MS-WIN-CORE-CONSOLE-L1-1-0.DLL
          [   ] API-MS-WIN-CORE-DATETIME-L1-1-0.DLL
          [ ^ ] API-MS-WIN-CORE-DEBUG-L1-1-0.DLL
          [ ^ ] API-MS-WIN-CORE-ERRORHANDLING-L1-1-0.DLL
          [ ^ ] API-MS-WIN-CORE-FIBERS-L1-1-0.DLL
          [ ^ ] API-MS-WIN-CORE-FILE-L1-1-0.DLL
          [ ^ ] API-MS-WIN-CORE-HANDLE-L1-1-0.DLL
          [ ^ ] API-MS-WIN-CORE-HEAP-L1-1-0.DLL
          [   ] API-MS-WIN-CORE-INTERLOCKED-L1-1-0.DLL
          [ ^ ] API-MS-WIN-CORE-LOCALIZATION-L1-1-0.DLL
          [ ^ ] API-MS-WIN-CORE-LIBRARYLOADER-L1-1-0.DLL
          [ ^ ] API-MS-WIN-CORE-MEMORY-L1-1-0.DLL
          [ ^ ] API-MS-WIN-CORE-MISC-L1-1-0.DLL
          [ ^ ] API-MS-WIN-CORE-NAMEDPIPE-L1-1-0.DLL
          [ ^ ] API-MS-WIN-CORE-PROCESSENVIRONMENT-L1-1-0.DLL
          [ ^ ] API-MS-WIN-CORE-PROCESSTHREADS-L1-1-0.DLL
          [ ^ ] API-MS-WIN-CORE-PROFILE-L1-1-0.DLL
          [ ^ ] API-MS-WIN-CORE-STRING-L1-1-0.DLL
          [ ^ ] API-MS-WIN-CORE-SYNCH-L1-1-0.DLL
          [ ^ ] API-MS-WIN-CORE-SYSINFO-L1-1-0.DLL
          [ ^ ] API-MS-WIN-CORE-UTIL-L1-1-0.DLL
     [ ^ ] MSVCRT.DLL
     [   ] LUA52.DLL
          [ ^ ] KERNEL32.DLL
               [F^ ] NTDLL.DLL
          [ ^ ] MSVCRT.DLL
          [*  ] HELLO.DLL
               [ ^ ] KERNEL32.DLL
                    [F^ ] NTDLL.DLL
               [ ^ ] MSVCRT.DLL
               [   ] LIBGCC_S_DW2-1.DLL
                    [ ^ ] KERNEL32.DLL
                         [F^ ] NTDLL.DLL
                    [ ^ ] MSVCRT.DLL
                    [*^ ] LIBGCC_S_DW2-1.DLL
               [   ] LIBSTDC++-6.DLL
                    [ ^ ] KERNEL32.DLL
                         [F^ ] NTDLL.DLL
                    [ ^ ] MSVCRT.DLL
                    [ ^ ] MSVCRT.DLL
                    [ ^ ] LIBGCC_S_DW2-1.DLL
                    [*^ ] LIBGCC_S_DW2-1.DLL
               [*^ ] LIBGCC_S_DW2-1.DLL
[*  ] SNXHK.DLL
     [ ^ ] KERNEL32.DLL
          [F^ ] NTDLL.DLL
     [*^ ] KERNEL32.DLL

编辑：添加了“cmake-G”MinGW Makefiles”的输出和构建

cmake-G“MinGW makefile”

mingw32 make

Scanning dependencies of target hello
[ 50%] Building CXX object CMakeFiles/hello.dir/hello_wrap.cxx.obj
[100%] Building CXX object CMakeFiles/hello.dir/hello.cpp.obj
Linking CXX shared library hello.dll
[100%] Built target hello

---

以下是一些可以尝试的东西：

您的cmake具有

FIND_包（Lua51）

，这可能会导致hello.dll链接到Lua 5.1，而您正在运行Lua 5.2

通过visual studio运行lua test.lua。您可以通过两种方法来实现，其中一种是运行lua test.lua并使脚本暂停，等待输入；在它等待输入时，运行VisualStudio并附加到lua进程；然后在lua控制台中按enter键，以便脚本继续；您可能知道故障发生的位置（post文件/行#）

我怀疑问题是系统DLL，更可能的是hello.DLL是用不兼容的设置构建的，例如单线程而不是多线程。检查您链接到的Lua是否是使用相同编译器设置构建的mingw的Lua。 make中最重要的信息是构建和链接的最终命令。在创建Lua时检查编译和构建命令是什么（可能为make设置verbose标志——您发布的只是显示g++正在运行的状态消息，而不是显示包含路径等的命令行参数），并找到如何使用cmake获取这些命令

原则上，您应该能够复制Lua makefile，并用hello.lib和co替换列出lua51.lib等的几行

---

您能在调试器中运行此程序以便捕获吗？如果删除

os.exit（）

，并将其替换为

Ctrl-Z

？如果您使用该组合键退出解释器，它还会崩溃吗？我找不到一个合适的lua调试器，我尝试了LuaEdit进行调试，但它也崩溃了，没有任何有意义的东西。使用LuaAPI运行C++脚本，通过GDB在脚本“程序接收信号SIGSEV，分段故障.0x775 DDFE4在NTDLL！RtlFreeHeap（））中从C:\Windows \Stase3\\NTDLL.DLL退出。此外，如果您运行的测试脚本没有

os.exit（）？我相信
os.exit
只是在下面调用abort或terminate，所以任何需要进行的清理都可能无法完成。lua.exe

链接到哪个C运行时？默认情况下，MinGW将链接到

MSVCRT.DLL

，而不是任何较新的visualc版本，而不进行任何长度的更改。用于Windows的Lua正在（IIRC）链接到

MSVCR80.DLL

。混合使用C运行时将导致最终的痛苦，这通常是由于多个内存分配器与从一个版本的

malloc（）

传递到另一个版本的

free（）

的指针之间的混淆造成的。查看正在发生的事情的最好方法是使用

DEPENDS.EXE

，以了解哪些DLL正在真正使用。您好，感谢您的回复，我使用了find_软件包（Lua51），因为我拥有的CMake版本中没有FindLu52.CMake脚本。但是，从CGUID给出的输出可以看出，它似乎定位了5.2个版本的库，按照上面的步骤（添加IO。Read（）调用脚本，在LUA.EXE中运行脚本，附加VisualC++处理）在0x77 E2DFE4（NTDLL.DLL）中给出以下错误未处理的异常。在lua.exe:0xc000005:Access违例读取位置0x6241C41F中，我猜这就是gdb抱怨的RtlFreeHeap函数。我正在尝试的步骤，看看它是否作为一个损坏的dllYeah出现，我编译了lua使用mingw32-make，这是相同的命令，我用来建立hello.dll。虽然在构建lua.exe时我使用了源代码附带的makefile，但是在我的构建中，makefile是由cmake生成的，所以我不确定它们是否具有不同的编译器设置。我可以发布这两个文件，看看是否有人能看到任何东西，我自己也不确定makefile语法发布makefiles会有太多代码，最重要的是最终的编译和链接命令以及命令行参数。我编辑了这篇文章，将多条评论列成一个更有用的答案。如果仍然不走运，我想我们将不得不结束这个问题，它将更适合作为一个讨论论坛，而且您还没有聊天特权（至少需要20个代表点）。

-- The C compiler identification is GNU 4.8.1
-- The CXX compiler identification is GNU 4.8.1
-- Check for working C compiler: C:/MinGW/bin/gcc.exe
-- Check for working C compiler: C:/MinGW/bin/gcc.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: C:/MinGW/bin/g++.exe
-- Check for working CXX compiler: C:/MinGW/bin/g++.exe -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Found Lua51: C:/Users/forgottenmaster/Dropbox/lua/lua-5.2.3/src/liblua.a
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Users/forgottenmaster/Dropbox/lua/modules/c++

Scanning dependencies of target hello
[ 50%] Building CXX object CMakeFiles/hello.dir/hello_wrap.cxx.obj
[100%] Building CXX object CMakeFiles/hello.dir/hello.cpp.obj
Linking CXX shared library hello.dll
[100%] Built target hello