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

EnterpriseZine / 2014年3月19日 10時0分

▲ 図2 -Pオプションでスケジューラーの数をいっぱい増やしてみました。

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

●案件の概要

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

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

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

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

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

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

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

古賀 啓一郎[著]

EnterpriseZine

トピックスRSS

ランキング