2017-01-11 7 views
1

次のコードは、setupVar.wait行でstd :: system_errorをスローします。奇妙なことは、これが断続的に起こるということです。いくつかのコード行を削除することによって、それは正常に実行されますが、必ずしもそうではありません。これは大きなコードブロックから削除されているので、私がやりたいことは停止して待つことだけです。条件変数のウェイトスロー例外

私は(コードはファイルTest2.cppである)次のコマンドを使用して、構築し、DEV-toolset2(GCC 4.8.2)を使用して、CentOSの6で実行しています:

g++ -O0 -g3 -Wall -c -fmessage-length=0 -std=c++11 -pthread -m64 -o"src/Test2.o" "../src/Test2.cpp" 
g++ -Wl,--no-as-needed -lpthread -o Test2 ./src/Test2.o 

他の奇妙なことこれがCentOS 7(gcc 4.8.5)で完璧に動作するということです。

#include <iostream> 
#include <thread> 
#include <mutex> 
#include <condition_variable> 
#include <unistd.h> 

using namespace std; 

int main() { 
    cout << "!!!Start!!!" << endl; 

    bool flag = false; 
    std::timed_mutex setupMtx; 
    std::condition_variable_any setupVar; 

    std::unique_lock<std::timed_mutex> setupLock(setupMtx); 

    std::thread theThread(
     [&flag] 
     { 
      cout << "!!!In thread!!!" << endl; 
      flag = true; 
     } 
    ); 

    sleep(1); 
    setupVar.wait(setupLock); 

    theThread.join(); 

    cout << "!!!End!!!" << endl; 

    return 0; 
} 

私は私を実行し得る:

!!!Start!!! 
!!!In thread!!! 
terminate called after throwing an instance of 'std::system_error' 
    what(): 
Aborted (core dumped) 

はsetupVar.waitで例外をスローする場合は原因となるコード自体に何か問題はありますか?誰かがこの問題の原因となる可能性のある他のアイディアを持っていますか?

ちょうどさらなる情報のため、出力exeファイル上でlddを実行しています:それはかなりあいまいだったが

linux-vdso.so.1 => (0x00007ffc37968000) 
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00000034a8c00000) 
    libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00000034b2c00000) 
    libm.so.6 => /lib64/libm.so.6 (0x00000034a8800000) 
    libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00000034b2000000) 
    libc.so.6 => /lib64/libc.so.6 (0x00000034a8400000) 
    /lib64/ld-linux-x86-64.so.2 (0x00000034a7c00000) 
+0

g ++(Ubuntu 5.4.0-6ubuntu1〜16.04.4)5.4.0 20160609で、g ++の同じフラグを使用してこのコードをローカルで試してみましたが、うまくいきます。 ) これはシステム固有のバグでなければなりません。 – foolo

+0

はい、CentOS 7でもgcc 4.8.5で動作させることができれば、それは私を驚かせるものではありません。私は別のライブラリバージョンを入れようと努力してくれるはずだと思います。ちなみに、私がtimed_mutexをプレーンなmutexに変更し、condition_variable_anyをcondition_variableに変更すると、それが動作し、これが[このバグ]の現れではないかと思うようになります(http://stackoverflow.com/questions/ 17518464/why-does-stdtimed-mutextry-lock-for-not-work) – jattman

答えて

0

OKを、最後にこれを考え出しました。ちょうど誰かが後でこれを渡るオフチャンスで掲示する。

私はCentOSの6

上のgcc 4.8を取得する簡単な方法として、devtoolset-2-gccのパッケージを(私は実際にCERNからの鉱山を持って)インストールされているので、これが関連している https://rhn.redhat.com/errata/RHBA-2014-1035.htmlに記載されているバグの現れでありますリンク上から引用

  • 以前は、 "STD :: condition_variable_any" C++ 11種類が誤ってGCCで を定義しました。その結果、 でコンパイルされたRed Hat Developer Toolsetコードは、より新しいバージョンのlibstdC++を使用して、より古いバージョンのライブラリである を実行することができませんでした。ヘッダーファイルが更新され、ヘッダーのみ "condition_variable_any"が追加され、 _GLIBCXX_DTS2_CONDITION_VARIABLE_ANYマクロと共に使用されます。マクロが定義されると、 コンパイルはlibstdC++のどのバージョンでも動作します。 (BZの#1120929)

従って溶液をcondition_variable含む前_GLIBCXX_DTS2_CONDITION_VARIABLE_ANYマクロを定義することです。