Shoeisha Technology Media

EnterpriseZine(エンタープライズジン)

EnterpriseZine(エンタープライズジン)

テーマ別に探す

005 めんどうくさいSQL Serverのデバッグ

edited by DB Online   2014/03/19 10:00

 ある時、SQL Serverがメモリダンプ出力したのでそれを解析してほしいという話が来ました。SQL Serverは、access violationなどのエラーが発生すると障害解析用にメモリダンプを出力するのです。

案件の概要

 メモリダンプにはプログラムコードやエラーが発生した時のスレッドスタックなど、エラー調査に必要な情報が保存されていますから、これらを解析しエラーの原因を解明しなければいけませんでした。

エラーの発生条件を調べる

 お客様からの情報は、ダンプファイルが出力されたというだけでどのような状況でエラーが発生したのかなど具体的なことはわからなかったのですが、とりあえずデバッガでメモリダンプを開きエラーになった原因を確認しました。

 すると、CPUレジスタの状態から不正なメモリアドレスにアクセスしていることが原因でエラーが発生したことがわかりました。

図1 こんな感じ
▲ 図1 こんな感じ

 エラーとなった直接的な原因やプログラムコードは特定できましたが、不正なメモリアドレスにアクセスすることになった経緯がすぐにはわからなかったので、ひとまず、社内のバグデータベースをエラーとなった関数名やスレッドスタックなどをキーワードに検索してみました。すると、すぐに似たような事例がみつかり、どうやら既に修正済みの問題のようだということがわかりました。

 あらためてメモリダンプからSQL Serverのバージョンを確認し、お客様が使用しているSQL Serverには修正モジュールが適用されていないことを確認します。これで、既知の問題に合致しているということはほぼ間違いないなと思いましたが、念のため、事例に記載されているエラーがどのような時に発生するのかを詳しく確認してみることにしました。

 開発チームの調査ログによると、どうやらこのエラーはレースコンディションの問題のようでした。ごく稀なタイミングでオブジェクトの参照カウンターがずれてしまうらしいのです。参照カウンターがずれてしまうことで、まだオブジェクトを参照しているスレッドが存在しているのにもかかわらず別のスレッドが誤ってオブジェクトを解放してしまうのです。


著者プロフィール

バックナンバー

連載:マイクロソフト古賀啓一郎の「今月のケースファイル」

もっと読む

All contents copyright © 2007-2019 Shoeisha Co., Ltd. All rights reserved. ver.1.5