2

H.264アプリケーションでエンコーディングを使用しQTKitています。

このアプリケーションは常に「segmentation fault」または「 」でクラッシュしEXEC_BAD_ACCESSます。

私のデバッガーは、次の場所でクラッシュを示しています。

0x7fff801fea94:  je     0x7fff801feba6           ; JVTLib_101906(JVTLib_100990*, JVTLib_101383 const*, JVTLib_101895*) + 3886

( ... )

0x7fff801feaba:  movl   $1, 24(%r13)

最後の " movl" 行でクラッシュが発生します。コメントで、それがエンコーダーJVTからのモジュールであることがわかりますH.264(私は推測します)。

私が理解できないのは、私のコードは長い間機能していたということです。昨日から不安定です。「Instruments」を使用すると、コードは正常に実行されます。したがって、メニューのポップアップには何らかの問題があるはずです。videoroutines のコメントを外すと正常に動作します (つまり、メニューにメモリの問題がないことを意味します)。

背後にある「魔法」を理解するQTKitことは刺激的です。

編集: オブジェクト名が表示されるようになりました: クラッシュはQTBackgroundQueueRun' スレッドで発生し、オブジェクトは ' です: 'PBRemoveObjectInternal(FSRefParam*, unsigned char)'

解決策:みなさん、こんにちは。私はついに問題を見つけました!Goole たちを探すのは、長くて大変な作業でした。

QTKitタイマーによって中断されるのが好きではありません。デバッグ シンボルを含めて「デバッグ」モードでプロジェクトをコンパイルし、つまり gdb を実行すると、アプリがクラッシュします。

NSLog は「リリース」モードで動作しています。ほとんどのデバッグの問題では、これでうまくいきます。したがって、コードを「実際に」デバッグする必要がある場合は、QTCaptureMovieFileOutput 関連のすべてのコードが削除されるプロジェクト設定にいくつかのマクロ定義を追加します。これで完了です。なぜ QTKit がこれらのことに敏感なのか不思議です。しかし、Quicktime は非常に古いコードであり、Apple は Quicktime X でモダニズムを行っていることは周知のとおりです。したがって、次回はより良いリリースが期待できます。

4

0 に答える 0