4

以下のコードを valgrind でコンパイルして実行すると、スレッドに参加したときにスレッドが解放され、後で参照されなくなったときに、既に解放されているメモリが読み取られるように見えます。

これは valgrind の「誤検知」ですか? そうでない場合、大規模な並列プログラムでは一般に無視しても安全ですか? どうすれば回避できますか？

int main (string[] args) {
    Thread<int> thread = new Thread<int>.try ("ThreadName", () => { 
            stdout.printf ("Hello World");
            return 0;
    });

    thread.join ();
    return 0;
}


==2697== Invalid read of size 4
==2697==    at 0x50F2350: g_thread_unref (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3800.1)
==2697==    by 0x400A65: _vala_main (in /home/lockner/test)
==2697==    by 0x400A9C: main (in /home/lockner/test)
==2697==  Address 0x5dc17e8 is 24 bytes inside a block of size 72 free'd
==2697==    at 0x4C2B60C: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==2697==    by 0x50F2547: g_thread_join (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3800.1)
==2697==    by 0x400A4B: _vala_main (in /home/lockner/test)
==2697==    by 0x400A9C: main (in /home/lockner/test)

「thread = NULL;」を手動で追加すると 生成された C コードの join 呼び出しと _g_thread_unref0 マクロの間で、valgrind 出力で無効な読み取りがなくなりました。

g_thread_join (thread);
result = 0;
thread = NULL;
_g_thread_unref0 (thread);
return result;
4

2 に答える 2

4

glib-2.0.vapi に欠落している注釈であることが判明しました

join() の上に [DestroysInstance] を追加すると、問題が解決します。

于 2013-12-11T12:09:54.120 に答える