0

ハングする PyQt アプリケーションがあります。

Qt 4.7.4 (64 ビット) Python 2.6.1 GCC 4.2.1 OSX 10.6.8

ハングの位置はさまざまです。ハングの 1 つの場所を無効化または書き換えると、その直後に別の場所でハングが発生します。

アプリケーションは、数千のカスタム データ オブジェクトを返す可能性のある検索を実行します。各データ オブジェクトには、50 の子オブジェクトが含まれる可能性があります。

ログを記録すると、これらのカスタム オブジェクトを作成するループでハングが発生する傾向があることがわかります。

また

アプリケーションはスレッドを使用していますが、これらのスレッドを無効にしてもハングが発生します。(これを確認するためにLaszlo Nagy のスタック トレース ツールを使用しています。メイン スレッドとスタック トレーサ スレッドのみが実行されている場合でもハングが発生します。)

アプリケーションは、イメージ ファイルを読み取り、作成します。I/O ロックが原因である可能性は低いようですが、まだ除外していません。

私は疑問に思う

作成できる Python オブジェクトの数に制限はありますか?

私が到達している可能性のある他の制限はありますか？

ガベージ コレクションのための明示的なオブジェクトの削除は行っていません。するべきか？

他に通常の容疑者はいますか？

編集 (8/13):

  • QTimer.singleShot は知っておくと良いことであり、有力候補ですが、このアプリは singleShot を使用していません。

  • アプリケーションがハングすると、100% の CPU (および約 140 MB のメモリ) を要求します。

  • できるだけ早く strace を試して、何が明らかになるか見てみます。

4

1 に答える 1

1

私は dtruss (OSX の strace に相当するもの) を試しましたが、結果はあまり役に立ちませんでした。

最後に、同僚のアドバイスを受けて、ソースをハングしていないことがわかっている最後の状態にロールバックしました。その後、クラスごとに変更を再導入しました。

犯人は、2 つの異なる QWidget クラスから継承するクラスでした。

class undoableWidget(QWidget) :
...

class tearableWidget(QTabWidget) :
...

class culpritWidget(undoableWidget, tearableWidget):

    def __init__(self, parentWidget, tabName):

        undoableWidget.__init__(self, parentWidget)
        tearableWidget.__init__(self, parentWidget, tabName)

アプリケーションがまったく機能したことに驚いています。

さらに調査を進めると、そもそも undoableWidget が QWidget から継承する必要がないことが判明しました。

アプリケーションがハングしなくなり、安堵して目がくらみます。

アドバイスありがとう。あなたは私のデバッグの習慣を改善するのに役立ちました.

于 2012-08-14T00:08:20.910 に答える