将MuparserX与QThreadPool一起使用时程序崩溃

I want to run multiple MuparserX parsers concurrently using QThreadPool. Here's the code:

我想使用QThreadPool同时运行多个MuparserX解析器。这是代码:

#include <iostream>
#include <QRunnable>
#include <QThreadPool>
#include "mpParser.h"

struct Task: public QRunnable {
    void run() override {
        //Create a new parser
        mup::ParserX p;
    }
};

int main(int argc, char *argv[])
{
    for (int i = 0; i != 10; ++i)
        QThreadPool::globalInstance()->start(new Task);

    while (QThreadPool::globalInstance()->activeThreadCount() > 0) {}

    return 0;
}

However, my program crashes with either "list iterators incompatible" or "list iterator not dereferencable" errors in the destructor mup::ParserX::~ParserX(). This happens only with MSVC13 and 15, and only in debug builds; release builds run without error and produce the expected output. GCC debug and release builds both work fine. Is there some nuance of Microsoft's compiler that's causing this, or is my program incorrect?

但是,我的程序在析构函数mup :: ParserX :: ~ParserX()中崩溃了“list iterators incompatible”或“list iterator not dereferencable”错误。这仅在MSVC13和15中发生,并且仅在调试版本中发生;发布版本运行没有错误并产生预期的输出。 GCC调试和发布版本都可以正常工作。微软的编译器是否有一些细微差别造成这种情况,或者我的程序是不正确的?

1 个解决方案

#1

I have found a work-around for this problem, though not really a clean solution. The error occurs in mup::IToken::~IToken(), when the macro MUP_LEAKAGE_REPORT is defined. The macro (automatically defined in debug builds) invokes a static member in a non-thread-safe way, giving rise to the iterator error. The simple solution is to just comment out the line where the macro is defined. In my version of MuparserX, it is in mpDefines.h, line 100:

我找到了解决这个问题的方法,虽然不是一个干净的解决方案。当定义宏MUP_LEAKAGE_REPORT时,mup :: IToken :: ~IToken()中会发生错误。宏(在调试版本中自动定义)以非线程安全的方式调用静态成员,从而引发迭代器错误。简单的解决方案是只注释定义宏的行。在我的MuparserX版本中,它位于mpDefines.h,第100行:

  #define MUP_LEAKAGE_REPORT

As far as I can tell, the macro is only used for debugging MuparserX and doesn't have any effect on the behavior of the parser.

据我所知,该宏仅用于调试MuparserX,并且对解析器的行为没有任何影响。