4

アプリの 1 つ (リリース バージョン) が応答しなくなったため、強制終了する必要がありました。

OS X がハング レポート(クラッシュ レポートなし) を表示し、それを *.crash ファイルにコピーしました。

HockeyApp などのサービスを使用したりatos、クラッシュ レポートを直接シンボル化できることは認識していますが、OS X アプリのハング レポートをシンボル化するにはどうすればよいですか?

4

1 に答える 1

10

しばらくして、通常のクラッシュ レポートとは少し異なるハング レポートの処理方法を見つけました。これが私がしたことです：

  1. Xcode で、オーガナイザーでクラッシュしたアプリの対応するアーカイブを検索し、Finder で表示します (右クリック)。
  2. アーカイブを右クリックし、 を選択しますShow Package Contents。
  3. からのファイルと対応するファイルをディレクトリ*.appからデスクトップなどの新しいフォルダにコピーします。新しいフォルダーにMyApp.appとMyApp.app.dSYMがあります。ファイルの命名は重要です。Products*.dSYMdSYMs
  4. lsターミナル経由で新しいフォルダーに。

ツール (「数値アドレスをバイナリ イメージまたはプロセスのシンボルに変換する」) を使用atosするには、最初に実行時のアプリの読み込みアドレスと、アプリがハングしている間のスタック フレームのアドレスを特定する必要があります。

  1. ハング レポートを開き、行Binary Images:の下のどこかにある行を見つけますHeaviest stack for ...。私の場合、これは次のようになります。

    Binary Images:
     **0x107b0f000** -        0x108b59fff  com.company.MyApp 1.1.0 (2)  <6080DCE1-9086-311C-899F-CC22B32D694D>  /Applications/MyApp.app/Contents/MacOS/MyApp
      0x7fff89c7e000 -     0x7fff89c87fff  libsystem_pthread.dylib (105.10.1)  <3103AA7F-3BAE-3673-9649-47FFD7E15C97>  /usr/lib/system/libsystem_pthread.dylib
      0x7fff8b0bf000 -     0x7fff8bc06fff  com.apple.AppKit 6.9 (1344.36)      <D94A7D32-A789-37EA-A85C-BEFA7DE716E6>  /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
      0x7fff8bd6e000 -     0x7fff8c09cfff  com.apple.Foundation 6.9 (1152.12)  <C0EE9DA6-C111-358A-8874-DA175BB797D6>  /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation

0x107b0f000** で囲まれたアドレスは、コピーする必要がある私たちのロード アドレスです。

  1. 次に、シンボル情報を検索したいアドレスを検索する必要があります。つまり、ハングの原因となった実際のメソッド シグネチャとコード行を取得する必要があります。したがって、ハング レポートの先頭にあるスタックで、「最も重いスタック」の下にあるアプリの名前を調べます。

    Heaviest stack for the main thread of the target process:
  10  start + 1 (libdyld.dylib + 13769) [0x7fff91df35c9]
  10  NSApplicationMain + 1832 (AppKit + 10612) [0x7fff8b0c1974]
  10  -[NSApplication run] + 594 (AppKit + 95459) [0x7fff8b0d64e3]
  10  -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 194 (AppKit + 145072) [0x7fff8b0e26b0]
  10  _DPSNextEvent + 964 (AppKit + 147201) [0x7fff8b0e2f01]
  10  _BlockUntilNextEventMatchingListInModeWithFilter + 71 (HIToolbox + 190347) [0x7fff96ae378b]
  10  ReceiveNextEventCommon + 431 (HIToolbox + 190794) [0x7fff96ae394a]
  10  RunCurrentEventLoopInMode + 235 (HIToolbox + 191439) [0x7fff96ae3bcf]
  10  CFRunLoopRunSpecific + 296 (CoreFoundation + 464984) [0x7fff901f1858]
  10  __CFRunLoopRun + 927 (CoreFoundation + 466495) [0x7fff901f1e3f]
  10  __CFRunLoopDoSources0 + 269 (CoreFoundation + 469005) [0x7fff901f280d]
  10  __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 (CoreFoundation + 525953) [0x7fff90200681]
  10  __NSThreadPerformPerform + 293 (Foundation + 416988) [0x7fff8bdd3cdc]
  10  ??? (MyApp + 62967) [0x108b1e5f7]
  8  ??? (MyApp + 48600) [0x108b1add8]
  8  -[IKImageBrowserView(ImageBrowserLayout) itemFrameAtIndex:] + 63 (ImageKit + 400983) [0x7fff91140e57]
[...]

この例のスタック トレースの最後に、MyApp が 2 回リストされていることがわかります。0x108b1e5f7、 、の両方のアドレスをコピーして0x108b1add8、レポートを閉じます。

  1. これで を使用する準備が整いましたatos。ターミナルで次のように入力し、Return キーを押します。

    atos -o MyApp.app/Contents/MacOS/MyApp -arch x86_64 -l 0x107b0f000 0x108b1e5f7  0x108b1add8

  2. atos同じディレクトリ内の *.dSYM ファイルを使用してアドレスを記号化し、うまくいけば次のような出力が得られます。

    -[MainWindowController loadDidFinish:] (in MyApp) (MainWindowController.m:127)
-[MainWindowController view:stringForToolTip:point:userData:] (in MyApp) (MainWindowController.m:231)

ええ、それは有望に見えます! コード行ではなく、入力したのと同じアドレスを出力する場合atosは、何か問題が発生しています。ここでのエラーの主な原因はおそらく間違ったメモリ アドレスであるため、正しいアドレスを選択したことを確認してください。

さらに質問がある場合はお知らせください (@raffael_me)。

于 2014-12-15T11:05:40.030 に答える