3

QByteArrayでclearを呼び出すと、次の例外が生成されます。

*glibcが検出されました* /home / yan / FPS2 / FPS2：ダブルフリーまたは破損（ファストトップ）：

0 ?? 1 ??
2無料
3QByteArray:: clear（）
4 FPSengine :: getDatagrams
5 FPSengine :: xmitData
6 FPSengine :: getData
7 threadDatalog :: run
8 ??
9 start_thread
10 clone
11 ?? 0

これはqtのバグですか、それとも私のコードと関係がありますか？QObjectsがスレッドセーフではないことは知っていますが（QT定義は、同じオブジェクトインスタンスの同じ関数を呼び出す複数のスレッドではありません）、私の関数にはミューテックスがあります。また、同じ関数が頻繁に呼び出されても、このエラーが発生することはめったにありません。PSこれを防ぐ方法は、env varMALLOC_CHECK_0です。

このURLは同様の問題に関連しており、一部の投稿は、互換性のないバージョンのglibcが原因であると示唆しているようです。

***glibcが検出されました***perl：ダブルフリーまたは破損（！prev）：0x0c2b7138 ***

4

3 に答える 3

4

これは、関数呼び出しによって返された一時的なものを参照するなど、さまざまなものであるQByteArray可能性がありますが、Qtのバグである可能性は低いです（IMO）。

デバッグに関するいくつかの考えを次に示します。

  • Valgrindの下で実行し、問題が浮き彫りになるかどうかを確認します
  • デバッグシンボルが使用可能なバージョンのQtに対してアプリケーションを実行します
  • コアダンプを有効にして、コアファイルを取得するかどうかを確認します
于 2010-02-04T05:44:04.483 に答える
2

これは、アプリケーションがマルチスレッド化されているという事実によって引き起こされます。オブジェクトはメインスレッドに属していますが、QBytearray でミューテックスを使用したにもかかわらず、別のスレッドで使用されています。はい、メインスレッドにも udpSocket が必要です

于 2010-02-26T01:02:24.567 に答える
1

あなたが qt のバグを発見したとは思えません。このエラーはさまざまな理由で発生する可能性がありますが、重要なのは、既に解放されているメモリへの参照があることを意味します。デバッガーを実行して、問題の原因を調べてみてください。gdb と valgrind を使用すると、問題を追跡できることを願っています。

于 2010-02-04T05:45:43.700 に答える