Question

我遇到了一些应该使用glfw3和OpenMP的代码的问题（顺便说一句，在OSX上使用g ++ 5.3.0）。这是我编写的一些数学软件的简化，看起来它在这一点上进展顺利。代码本身它巨大，甚至我的例子都非常大（我劫持了一个已经有glfw工作的旧教程项目），所以我将附加git repo代码生活在重复。我已经查看了多线程引起的其他glfw3问题，并提出了this和this。

glfwAppTutorial git repo!

齿轮应用中存在问题。当我在没有OpenMP的情况下编译它时，它可以工作。当我使用OpenMP编译它并且只使用1个线程时，它可以工作。当我转向使用2个线程时，它会在glfwPlatformPollEvents调用上发生段错误。我在创建上下文时通过std :: this_thread :: get_id（）调用检查了线程id，然后当我要更新它时，但是当我移动到多个omp线程时它仍然似乎是段错误在我添加特定命令集之后。它比那更怪异。这段开创性的代码是我开始做一些计算量很大的东西，当然我想并行化。代码看起来像这样（glfwAppTutorial / gears / src / gears.cpp :: glloop用于主版本，为了清晰起见，删除了多余的东西）：

// gears.cpp excerpt
#pragma omp parallel
{
    int tid;
    double *fx, *fy, *fz;
    tid = omp_get_thread_num();

    fx = frc_ + (3*tid)*10;
    for (int i = 0; i < 3*10; ++i) {
        fx[i] = 0.0; // BOOM!!!!!!!!!, including this segfaults, but not here...
    }
    fy = frc_ + (3*tid+1)*10;
    fz = frc_ + (3*tid+2)*10;

    std::cout << "Running on thread: " << tid << std::endl;

    #pragma omp for schedule(runtime) nowait
    for (int i = 0; i < 10; ++i) {
        // simulate work
        std::mt19937_64 eng{std::random_device{}()};  // or seed however you want
        std::uniform_int_distribution<> dist{10, 100};
        std::this_thread::sleep_for(std::chrono::milliseconds{dist(eng)});
    }
    // synchronize if we need to
    #pragma omp barrier

} // pragma omp parallel

前面定义了frc_（并将其归零为全部0.0倍）：

// gears.hpp excerpt
nthreads = omp_get_num_threads();
frc_ = new double[3*10*nthreads];
for (int i = 0; i < 3*10*nthreads; ++i) {
    frc_[i] = 0.0;
}

当然，在这个例子中，一切都在（glfwApp.cpp）下运行：

//glfwApp.cpp excerpt
void glfwApp::glfwloop() {
    while(!glfwWindowShouldClose(_window)) {
        this->glloop();

        glfwSwapBuffers(_window);
        glfwPollEvents();
    }
}

导致segfault的行是fx [i] = 0.0，但该行不是实际的segfault源。程序段错误在gleCallList或glfwPlatformPoll中。那么有人知道可能会发生什么吗？不使用glfw3的仅计算版本很好，我使用valgrind（或OSX，Instruments）来检查可能的问题。我所做的只是一些指针算术应该相当简单，但由于某种原因不是。我会努力创建一个更多更简单的例子，因为我意识到这可能无法遵循，但它已经让我疯了几天了

这是来自OSX的堆栈跟踪，因为Xcode和gdb现在正在愚蠢

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0x0000000000000110

VM Regions Near 0x110:
--> 
    __TEXT                 0000000106019000-0000000106020000 [   28K] r-x/rwx SM=COW  /Users/USER/*

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libGPUSupportMercury.dylib      0x00007fff8d03f57c gpusLoadCurrentVertexArray + 132
1   com.apple.AMDRadeonX4000GLDriver    0x000000010b66c695 gldUpdateDispatch + 2819
2   GLEngine                        0x00007fff8b69bad4 gleDoDrawDispatchCore + 533
3   GLEngine                        0x00007fff8b63e636 gleSetupAndDrawArraysOrElementsOutOfLine_ListExec + 886
4   GLEngine                        0x00007fff8b5c8a6a gleCallList + 170
5   gears                           0x000000010601bc25 gears::draw() + 199
6   gears                           0x000000010601c285 gears::glloop() + 33
7   gears                           0x000000010601dd2a glfwApp::glfwloop() + 60
8   gears                           0x000000010601dcea glfwApp::start() + 24
9   gears                           0x000000010601d04a main + 171
10  libdyld.dylib                   0x00007fff967475ad start + 1

Answer 1

除非在并行区域的动态范围内调用gears的构造函数，omp_get_num_threads()返回1，因此frc_不够宽，不能容纳多个线程的数据并且堆被第一段中显示的代码破坏。尝试将omp_get_num_threads() here替换为omp_get_max_threads()，看看是否有帮助。另外，请确保代码中某处omp_set_dynamic(0);并且中间没有调用omp_set_num_threads()，否则团队规模可能会因某个并行区域而异，并且{{1} }}

在glCallList上使用OpenMP段错误的GLFW3（在glfw的其他地方）

1 个答案: