BlizzardでのDiabloIV開発とVisualStudioでのLinuxメモリダンプのデバッグ

マイクロソフトのブログには、最近、ディアブロIVに取り組んでいるブリザードのシニアソフトウェアエンジニアであるビルランドルフが書いた記事が掲載されました。この記事では、Diablo IVでの作業の詳細について説明し、特にVisualStudioを使用してLinuxベースのコードをデバッグする方法について説明します。本日、この資料の翻訳をお届けします。

前書き

Diablo IVで作業するときは、すべてのコードをWindowsで記述してから、さまざまなプラットフォーム用にコンパイルします。これは、Linuxを実行するサーバーにも当てはまります。 （コードには条件付きコンパイルディレクティブが含まれており、必要に応じて、特定のプラットフォーム用に特別に記述されたフラグメントが含まれています。）私たちの作業は多くの理由でこのように構成されています。手始めに、私たちのチームの主要な専門スキルはWindowsです。私たちのサーバープログラマーでさえ、Windows開発に最も精通しています。チームのすべてのプログラマーが同じツールと同じ知識ベースを使用できることを高く評価しています。



Windowsで開発を行うもう1つの最も重要な理由は、VisualStudioが提供する高機能で信頼性の高いツールセットを利用できることです。そして、Linuxで何かを開発していたとしても、Linuxの世界にはVisualStudioと比較できるものは何もないと言えます。



確かに、このため、サーバーがクラッシュしたときに発生するいくつかの問題に直面し、メモリダンプをデバッグする必要があります。失敗した仮想マシン（より正確にはコンテナ）にリモートでログインする機能があります。gdbを実行して、何が起こったのかを調べることができます。しかし、このアプローチには多くの欠点があります。たとえば、ソースコードと一緒にバイナリをデプロイしません。その結果、仮想マシンまたはコンテナを操作する場合、ソースコードはgdbセッションで使用できません。



もう1つの問題は、gdb自体にあります。事実、このツールを定期的に使用しないと、自分に合ったレベルで習得することができません。簡単に言えば、開発者は使い慣れたツールを使用してコードをデバッグすることをいとわないでしょう。 gdbをよく知っている開発者は2〜3人だけなので、問題が発生した場合は、開発者が問題を探します。そして、これはプログラマーにとってワークロードの最適な分散とは言えません。



私たちは常に、直感的なLinuxコードをデバッグする方法を見つけたいと思っていました。そのため、使い慣れた環境でこの問題を正確に解決できる新しいVisualStudio機能を使用できることにとても興奮しています。そして、このおかげで私たちの夢が実現したと言っても過言ではありません。

コードのデバッグプロセスについて

Visual StudioでのLinuxコードのデバッグは、Linux用のWindowsサブシステム（WSL）がシステムにインストールされている場合、またはLinuxへの接続が接続マネージャーで構成されている場合にのみ可能 です。すべてのバックエンド開発者は、プロジェクトをデプロイするディストリビューションを使用してWSLをインストールしています。私が書いたスクリプトを実行して、WSLでサーバーを構築するために必要なすべての開発ツールとサポートライブラリをインストールします。



（メイントピックから少し離れます。WSLは、開発者がLinuxビルドの変更をテストできる、現存する最高の環境であるという結論に達したことを強調したいと思います。この作業スキームは非常に便利に見えます。 WSLに切り替え、コマンドcd



を使用 して共有コードディレクトリに移動し、そこから直接プロジェクトをビルドします。これは、仮想マシンやコンテナを使用するよりもはるかに優れたソリューションです。CMakeを使用してプロジェクトをビルドする場合は、次を使用することもできます。WSLの組み込み VisualStudioサポート。）



私たちのアセンブリについて少しお話しします。私たちはWindowsでコードを開発し、このOSで動作するように設計されたサーバーのWindowsバージョンを持っています。これは、通常のプロジェクト機能で作業するときに役立ちます。ただし、サーバー側のコードをLinuxにデプロイしているため、Linuxでのビルドが必要です。 Linuxアセンブリは、ビルドファームで作成されます。 Linuxコンピューターで実行されるビルドシステムを使用します。その助けを借りて、サーバープロジェクトと対応するコンテナーが組み立てられ、後でデプロイされます。 Linuxバイナリは、コンテナにのみデプロイされます。通常、開発者はこれらのコンテナにアクセスできません。



インフラストラクチャ内のサーバーの1つに障害が発生すると、特別なスクリプトによってこれが通知されます。その後、ダンプファイルが共有ネットワークフォルダーに書き込まれます。 LinuxまたはVisualStudioでこれらのファイルをデバッグするには、動作するプログラムが必要です。デバッグするときは、デプロイされたコンテナで使用されているものとまったく同じ共有ライブラリを使用すると便利です。これらのファイルを取得するには、別のスクリプトを使用します。まず、ダンプをローカルマシンにコピーしてから、スクリプトを実行して、このダンプに関する情報を渡します。スクリプトは、テストされたバージョンのコード用にビルドされたDockerコンテナーをダウンロードし、そこからサーバーの実行可能ファイルと特定の一般的なランタイムライブラリを抽出します。これはすべてgdbに必要です。 （これは、gdbを使用する場合、次の場合に発生する可能性のある互換性の問題を回避しますシステムのWSLバージョンがデプロイされたLinuxバージョンと完全に同じでない場合。）デバッグセッションを設定するスクリプトは、にデータを書き込みます。 ~/.gdbinit



、共有ライブラリがシステムライブラリであることを示します。



次に、Visual Studioに移動し、そこで楽しみが始まります。 Windowsバージョンのサーバー用のビルドソリューションをダウンロードしています。次に、コマンドを使用して新しいデバッグダイアログを開き Debug -> Other Debug Targets -> Debug Linux Core Dump with Native Only



ます。チェックボックス Debug on WSL



をオンにして、ダンプファイルとサーバーバイナリ（WSLを対象としています！）へのパスを入力します。その後、ボタンDebug



を押して 何が起こっているかを見てください。





VisualStudioでデバッグを開始



するVisualStudioは、WSLでgdbを自動的に起動します。システムがしばらくの間ディスクを操作した後、失敗したプログラムのコールスタックが表示され、命令ポインタが対応するコード行に設定されます。これは本当に勇敢な新しい世界です！



次に、障害自体の特定について説明します。適切なイベントをインターセプトしていくつかのサービス手順を実行するフォールトハンドラーがあります。したがって、障害自体に関する情報は、シングルスレッドサーバーのコールスタックのより深い場所にあります。ただし、一部のサーバーはマルチスレッド化されています。また、クラッシュはどのスレッドでも発生する可能性があります。障害ハンドラーは、障害のあるファイルのコードと行番号に関する情報をログに記録します。したがって、このデータを調べると、最初の手がかりが得られます。このコードの実行に対応するコールスタック内の場所を探しています。



昔、つまり数週間前は、gdbを使用してすべてのスレッドをバックトレースし、結果のリストをスキャンして、コールスタックがクラッシュした可能性が最も高いスレッドを見つけていました。たとえば、スレッドが休止状態にあった場合、おそらくクラッシュしませんでした。スリープ状態のスレッドを処理しているフレームと情報が数個を超えるスタックが必要です。次に、問題が何であるかを理解するために、コードを調べる必要があります。単純なものであれば、コードですぐに確認できます。より複雑な問題に直面した場合は、gdbの機能を利用してプロセスの状態を調査する必要があります。



しかし、Visual Studioは、以前よりもはるかに強力な機能を提供します。マルチスレッド環境では、デバッグセッションでウィンドウを開き Threads



、スレッドをクリックしてスタックを表示できます。ただし、これはgdbで使用されるアプローチと非常によく似ています。したがって、たとえば50スレッドを学習する必要がある場合、それはかなり時間のかかる退屈な作業になる可能性があります。幸い、Visual Studioには、このタスクをはるかに簡単にするツールがあります。これはParallelStacksウィンドウ です。



確かに、Erica Sweetと彼女のチームがParallel Stacksについて教えてくれるまで、私たちのほとんどはParallelStacksについて知りませんでした。デバッグセッション中にコマンドを実行する場合 Debug -> Windows -> Parallel Stacks



-新しいウィンドウが開き、調査中のプロセスの各スレッドのコールスタックに関する情報が表示されます。これは、プロセス空間全体の鳥瞰図のようなものです。任意のスレッドの任意のスタックフレームをダブルクリックできます。その後、VisualStudioはソースコードウィンドウとコールスタックウィンドウの両方でこのフレームにジャンプします。これは、時間を節約するのに大いに役立ちます。



クラッシュサイトの近くにコードが表示されたら、マウス、QuickWatch、または多くのVisualStudioツールのいずれかを使用して変数を調べることができます。もちろん、リリースビルドでは、多くの変数が最適化されていますが、同時に、多くは最適化されていません。Visual Studioインターフェイスを使用すると、gdbを使用する前よりもはるかに高速に問題を特定できます。

結果

私たちのチームは、私たちが開発している環境であるVisualStudioでLinuxダンプをデバッグできることを嬉しく思います。私たちにとって、これは大きな改善です。これにより、これまで以上に多くの開発者が実際の問題を診断できるようになります。これにより、私たち全員がVisualStudioの強力なデバッグツールを利用できるようになります。作業環境の準備が完了したら、文字通り数分でVisualStudioのデバッグセッションに参加できます。この機能により、問題の発見速度と作業の効率が大幅に向上します。エリカと彼女のチームの助けに感謝します。



Visual Studioで最も役立つものは何ですか？