C++线程附加/删除段错误

Question

我使用用C++编写的插件来运行MySQL上的查询.它在Xojo(www.xojo.com)制作的应用程序中使用.

问题是,如果执行的查询太多,它会在linux上崩溃并出现分段错误.

插件本身的工作原理是在执行查询之前从调用线程中分离,以便不阻塞主应用程序等,然后在完成后重新附加.我认为重新附加是问题(linux中的gdb调试看起来像这样)但是由于Xojo框架上没有符号,我不太确定.

这是用于分离和重新附着的两种方法/功能

void ReattachCurrentThread(void *token)
{
    static void (*pAttachThread)(void*) = nullptr;
    if (!pAttachThread)
        pAttachThread = (void (*)(void *)) gResolver("_UnsafeAttachCurrentThread");
    if (pAttachThread) pAttachThread( token );
}

void * DetachCurrentThread(void)
{
    static void * (*pDetachThread)(void) = nullptr;
    if (!pDetachThread)
        pDetachThread = (void * (*)(void)) gResolver("_UnsafeDetachCurrentThread");
    if (pDetachThread) return pDetachThread();
    return nullptr;
}

这里有一个叫做的地方:

REALdbCursor MySQLPerformSelect(MySQLDatabaseData *db, REALstring queryStr)
{
    if (db->fConnection == nullptr) return nullptr;

    if (!LockDatabaseUsage( db )) return nullptr;

    REALstringData stringData;
    if (!REALGetStringData( queryStr, REALGetStringEncoding( queryStr ), &stringData )) return nullptr;

    void *detachToken = DetachCurrentThread();
    int err = mysql_real_query( db->fConnection, (const char *)stringData.data, stringData.length );
    ReattachCurrentThread( detachToken );
    db->CaptureLastError();

    REALDisposeStringData( &stringData );

    REALdbCursor retCursor = nullptr;
    if (0 == err) {
        // Allocate a cursor
        MySQLCursorData *curs = new MySQLCursorData;
        bzero( curs, sizeof( MySQLCursorData ) );

        curs->fCursor = new MySQLCursor( db );

        retCursor = NewDBCursor( curs );
    }

    UnlockDatabaseUsage( db );

    return retCursor;
}

我的问题是:上面的代码是否有任何问题,是否会导致段错误,因为它不会在某种程度上小心等等？我不是一个C++程序员,但在我的理解中似乎太直率了,就像没有试图查看线程是否可用.再次,我不是一个C++程序员所以我所说的都可能是荒谬的......

"整个"插件的代码在这里: 插件的源代码

Answer 1

您确定DetachCurrentThread()总是返回指向令牌的指针吗？添加以下检查并查看是否有帮助：

void *detachToken = DetachCurrentThread();
if (detachToken == nullptr) return nullptr; // ensure the pointer to a token is returned before proceeding further.