スタックの取得(ネィテブデバッガを作る2)

デバッグを行う上で実行位置に続いて重要なのがスタックの情報です。
別プロセスのスタック情報を取得するには、ReadProcessMemory APIを使用します。「ネィティブデバッガを作る」で取得したCONTEXT構造体のEspレジスタで示されるアドレス以降のデータを読み出します。

BYTE stackPointer[64];
DWORD readedSize(0);
HANDLE hProcess(0);
hProcess = ::OpenProcess(PROCESS_VM_READ, FALSE, debugEvent->dwProcessId);
if (NULL != hProcess)
{
// スタック領域からメモリを読み出す
if (::ReadProcessMemory(hProcess, (LPVOID )context.Esp, &readBuff, sizeof(readBuff), &readedSize))
{
// スタックダンプを表示する
}
}

ReadProcessMemory APIで確保されていないメモリ領域にアクセスすると、デバッグ対象となっているプロセスで不正なメモリアクセスがおこりDebugEventが発生します。ReadProcessMemoryで不正なメモリアクセスを起こし、DebugEventで再びReadProcessMemoryを呼び出し・・・という無限ループに陥らないように注意が必要です。
ReadProcessMemoryの第二パラメータや第三パラメータで割り当てられていないメモリを指定しても、ReadProcessMemoryはエラーを返さずに正常終了します。ReadProcessMemoryがエラーになるか否かで、正しくメモリを読み出せたか判断することはできません。

ネィティブデバッガを作る

WindowsOSやMozillaなどアプリケーションのデバッグ情報を送信する機能を備えたソフトウェアが増えています。Debugging Functions APIを使って実行中の不正なメモリアクセスなどを監視してデバッグ情報を取得する機能を確認してみましょう。
まずデバッグを行うにはCreateProcess APIを使ってデバッガからデバッグ対象のプロセスをDEBUG_PROCESSオプション付きで起動するか、あるいはデバッグ対象のプロセスからデバッガをDEBUG_ONLY_THIS_PROCESSオプション付きで起動する必要があります。
続いてWaitForDebugEvent APIを使用してデバッグ対象プロセス内でイベントが発生するのを待ちます。ここでは不正なメモリアクセスエラーだけを対象として考えます。dwDebugEventCodeがEXCEPTION_DEBUG_EVENT、ExceptionCodeがEXCEPTION_ACCESS_VIOLATIONの場合にエラーをトラップしていみます。これ以外にDLLのLoad/Unload、プロセスやスレッドの開始/停止、デバッグ標準出力へのメッセージや、プロセス内で発生した各種例外を取得することができます。
デバッグ対象プロセスの状態を取得するために、GetThreadContext APIを使用します。これによりデバッグ対象プロセス内で不正なメモリアクセスが発生した時のCPUレジスタの状態を取得できます。取得されるCONTEXT構造体の内容は使用しているCPUのアーキテクチャによって異なります。デバッグにこの情報を利用するためには、各種CPIアーキテクチャ毎にレジスタがどのように扱われるのか熟知している必要があります。
今回はx86 CPUアーキテクチャを対象としますので、CONTEXT構造体のeipレジスタに注目してください。eipレジスタの値が不正なメモリアクセスが発生した時に実行されていたアプリケーションコードの場所をしめします。あとはMAPファイルなどを確認して問題箇所を特定します
デバッグイベントに対する処理が終わったら、ContinueDebugEvent APIを呼び出します。このAPIの呼び出しによりデバッグイベントの発生により一時停止していしるデバッグ対象プロセスの処理を再開させます。

// デバッグ対象のプロセスを開始する
STARTUPINFO startupInfo;
PROCESS_INFORMATION processInfo;
::memset(&processInfo, 0x00, sizeof(processInfo));
::memset(&startupInfo, 0x00, sizeof(startupInfo));
startupInfo.cb		= sizeof(startupInfo);
if (CreateProcess(NULL, m_cmdLineInfo.m_runAppName.GetBuffer(), NULL, NULL, FALSE, DEBUG_PROCESS, NULL, NULL, &startupInfo, &processInfo))
{
// デバッグイベントを待つ
DEBUG_EVENT debugEvent;
while (WaitForDebugEvent(&debugEvent, INFINITE))
{
if (EXCEPTION_DEBUG_EVENT == debugEvent.dwDebugEventCode)
{
if (EXCEPTION_ACCESS_VIOLATION == debugEvent.u.Exception.ExceptionRecord.ExceptionCode)
{
// スレッドハンドルの取得
HANDLE hThread(0);
hThread = ::OpenThread(THREAD_GET_CONTEXT, FALSE, debugEvent->dwThreadId);
if (NULL != hThread)
{
// スレッドの状態を取得
CONTEXT		threadContext;
threadContext.ContextFlags	= CONTEXT_ALL;
if (GetThreadContext(hThread, &threadContext))
{
// ここでデバッグ処理をおこなう
}
}
}
}
ContinueDebugEvent(debugEvent.dwProcessId, debugEvent.dwThreadId, DBG_CONTINUE);
}
}

UPS互換バッテリーを購入してみた

我が家はオール電化なのだ。でも一人暮らしだし~と60A契約にしている。これで、冬場に暖房をつけつつ、パソコン立ち上げたまま、TVを見つつ、電子レンジを使いつつ、調理などをすると、ブレーカーを落として白くなることたびたびおこる。
そこでUPSを購入してパソコンにつないでおくことにした。といっても予算はそんなにない。
Yahooオークションなんかでは2000円ぐらいで中古を売っているけど、実は深い訳があるのだ。UPSの正規交換用バッテリーは1万~3万円ぐらいする高価な品物。交換用バッテリーを購入するよさんにちょっと足せば新品を変えてしまうのだ。
でもね・・・実はもっと安い市販のバッテリーでも動くんですよ。
というわけで本体はヤフオクからSmart-UPS 1000を落札。
バッテリーは電圧と容量、サイズ、コネクタの位置などで様々な規格品がありますが、それらがほぼ同じ同等製品であれば同じように使えるはずなのです。というわけで秋月電子からWP12-12を二個購入。
届いたバッテリーをさっそく空けてみますと・・・・微妙にコネクタの形状が異なります。正規品よりちょっとコネクタの横幅がせまいですが、多少狭い分には問題なくつながります。正規品は接着剤で二個のバッテリーが離れないように接合してありますが、そこのところは無視することにします。
で、取り付けて起動!ばっちりですよ♪ただし問題となるのはバッテリの廃棄。私の場合は実家が自動車整備工なんで、自動車用バッテリーに紛らわせて処分してもらうことにします。バッテリーを売っている自動車パーツショップであれば、不要バッテリーの有償引き受けもやっていると思うので、ちゃんと処分しましょう。
ちなみにSmart-UPS 500Jの場合はPXL12050、Smart-UPS 700の場合はWP8-12が使えるらしいです。自己責任でお試しあれ。

Error C2872: ‘IServiceProvider’: あいまいなシンボルです。

C++ CLRで記述したアプリケーションからCOMインターフェースを使用しようとすると「C2872: ‘IServiceProvider’: あいまいなシンボルです。」のコンパイルエラーが表示される。これは.NETのSystem.IServiceProviderとシンボルが重複しているのが原因です。
この問題を回避するには”using namespace System”よりも手前にヘッダファイルの#includeを記述します。

DVDを英国から個人輸入してみた

DVDの個人輸入が2chでちょっと祭りになっていた。英AmazonのDVD売上げのベスト10に日本のアニメが出てしまい、メジャーアニメタイトルの在庫がなくなるほどの盛況ぶりでした。このとき、つい出来心で頼んだDVDがようやく届きはじめたのです。
結論としては思っていたよりはるかに良いです。
さてDVDはリージョンコードや映像形式の違いにより、海外で購入したものを視聴することはできないようになってます。アメリカと日本で劇場公開時期が違っているときなど、劇場公開前にDVDが流通したりするのを防ぐための仕組みです。英国と日本はリージョンコードは同じですがTVの信号形式が異なるため、一般的なDVDプレイヤーやTVでは個人輸入したDVDを見ることはできません。ですがパソコンは英国で使われているPAL信号形式も、日本で使われているNTSC信号形式でも再生することができます。
PAL形式とNTSC形式にはいくつか大きな違いがあります。その一つが解像度です。日本で使われるNTSC形式の水平走査線の数は525本、英国で使われているPAL形式の水平走査線の数は625本、英国のほうが二割ほど解像度が高いのです。HDTVの720pは水平走査線が720本。これには及ばないまでも、パソコンで見てると明らかに画質が違うんですよ。
流石に同じDVDを二枚も持っていないので、動画を比較して提供できないのが残念。

屋外の常夜灯をLEDに変えてみました。

IMG_5230
IMG_5236

個人輸入していたLEDが届きました。常夜灯として屋外についている、12Vのハロゲンランプの代わりです。35W→3Wに消費電力が減りました。消費電力もさることながら、温度が気になっていたんですよ。芝生のところにあるので、そのうち悪条件が重なると燃え移ったりしないかと不安だったのです。

石壁にスポットをあてて、間接照明になってます。3Wで足りるか不安だったんですけど、まぁ大丈夫な様です。

codファイルを使用したデバッグ

リリース後のアプリケーションで例外が発生した場合、codファイルを使用して例外の発生した行を特定することができます。
コンパイル時に生成された、アセンブリ言語のコードと、コンピュータ語のコードを保存することができます。プロジェクトのプロパティを開いて、C/C++の出力ファイルにある「アセンブリの出力」を変更して、「アセンブリコード、コンピュータ語コード、ソースコード」を選択します。これでビルド時に拡張子codのファイルが生成されます。
マップファイルを使用することで、例外オフセットから障害が発生したアドレスを調べられることは「マップファイルを使用したデバッグ」で解説しました。

Address Publics by Value Rva+Base Lib:Object
0000:00000001 ___safe_se_handler_count 00000001
0000:00000000 ___ImageBase 00400000
0001:00000000 _wmain 00401000 f crashTest.obj
0001:00000020 ?funcA@@YAHXZ 00401020 f crashTest.obj
0001:00000050 ?funcB@@YAHH@Z 00401050 f crashTest.obj
0001:00000090 ?funcC@@YAXXZ 00401090 f crashTest.obj

ここで例外の発生している関数funcBと例外オフセットアドレスの差を求めます。この場合、例外オフセットが0x1064、 関数の先頭アドレスが0x1050で、差分は0x14(20)バイトです。ここでcodファイルのfuncBの場所を参照します。

PUBLIC ?funcB@@YAHH@Z ; funcB
; Function compile flags: /Odtp
; COMDAT ?funcB@@YAHH@Z
_TEXT SEGMENT
_val$ = -4 ; size = 4
_arg1$ = 8 ; size = 4
?funcB@@YAHH@Z PROC ; funcB, COMDAT

; 29 : {

00000 55 push ebp
00001 8b ec mov ebp, esp
00003 51 push ecx

; 30 : char *val = NULL;

00004 c7 45 fc 00 00
00 00 mov DWORD PTR _val$[ebp], 0

; 31 : strcpy(val, “Hello World”); // 1.ソースコードの31行目で例外が発生している

0000b 8b 45 fc mov eax, DWORD PTR _val$[ebp]
0000e 8b 0d 00 00 00
00 mov ecx, DWORD PTR $SG-6
00014 89 08 mov DWORD PTR [eax], ecx // 2.ここで例外が発生している
00016 8b 15 04 00 00
00 mov edx, DWORD PTR $SG-6+4
0001c 89 50 04 mov DWORD PTR [eax+4], edx
0001f 8b 0d 08 00 00
00 mov ecx, DWORD PTR $SG-6+8
00025 89 48 08 mov DWORD PTR [eax+8], ecx

; 32 : printf(“call funcB”);

00028 68 00 00 00 00 push OFFSET $SG-7
0002d ff 15 00 00 00
00 call DWORD PTR __imp__printf
00033 83 c4 04 add esp, 4

; 33 : return 0;

00036 33 c0 xor eax, eax

; 34 : }

00038 8b e5 mov esp, ebp
0003a 5d pop ebp
0003b c3 ret 0
?funcB@@YAHH@Z ENDP ; funcB
_TEXT ENDS

0x0014バイトの個所を探すと、2.の個所で例外が発生していることがわかります。これは1.で示されるソースコード上の31行目にあたります。この作業でリリース後のアプリケーションでもソースコード状の何処で例外が発生しているのか特定することができます。

SSEを有効にして最適化する

Visual Studio 2005から標準でMMX、SSE、SSE2命令を有効にした最適化をおこなえるようになりました。これらマルチメディア拡張命令を使用することで高速化を試みてみましょう。プロジェクトのプロパティを開き、C/C++のコード生成で「拡張命令セットを有効にする」のオプションを変更します。
SHA-256のサンプルプログラムを実行してみました。以下はその実行速度です。
設定なし・・14103ms
SSE・・・・・13604ms(3.5%)
SSE2・・・・12932ms(8.3%)
SSE2を有効にしただけで、8%ほどパフォーマンスが改善されています。
VC++コンパイラのSSE対応は一部の演算命令をSSE2のものに置き換えているだけで、Intel製のC++コンパイラように自動でベクトルか化を行うものではありません。ただしSSE命令を使用することによって使用できるレジスタの値が増え、その結果メモリ転送量が減って高速化する場合があるという程度のようです。
SHA-256のサンプルプログラムをベクトル化してみました。以下はその実行速度です。
SSE2(ベクトル化)・・・・17532ms
むしろ遅くなっています。
SHA256アルゴリズムはもともとベクトル化にはあまり向いていません。4ブロック128ビット分を一度に演算していますが、ベクトル化できるのは途中までで、最後に手前のブロックとの演算結果との計算は単純に4ブロック分を一度に演算するわけにはいかないからです。それを別にしてもあまりにも遅くなっている気がします。
実はSSE命令にはいくつかパフォーマンス上の欠点があります。
一つ目は16バイト分のメモリに一度にアクセスするため、キャッシュにヒットしない場合の性能低下が大きくなるのです。
二つ目はアライメントの問題。16バイト境界にアライメントされていないメモリへのアクセスは非常に遅くなるのです。
ハッシュ値の計算もととなるバイト列は都合が良いようにはアライメントされていません。これを128bit変数にセットする部分のオーバーヘッドが大きくてベクトル化の恩恵を相殺してしまっています。
SHA-256のサンプルプログラムにSSEの_mm_prefetch命令を4行ほど追加してみました。
SSE2(プリフェッチ)・・・・11918ms(15.5%)
SSEにはCPU内部のメモリキャッシュ動作を制御する命令が追加されています。大量のデータにアクセスする場合、キャッシャ制御命令を使ってメモリバスが使われていない隙間の時間に、データをキャッシュメモリに読みだすことができます。1ブロック分の処理中に、次に使用するブロックをキャッシュに読み込むことで、6%以上高速化しています。
IntelのCPUではキャッシュメモリを32バイトごとに管理しています。_mm_prefetch命令を導入する場合には32バイト毎に、メモリアドレスを指定する必要があります。
AES暗号のサンプルプログラムで「拡張命令セットを有効にする」のオプションを同じように実行してみました。以下はその実行速度です。
設定なし・・36052ms
SSE・・・・・45021ms(-24.8%)
SSE2・・・・45817ms(-27.0%)
むしろ遅くなっています。最適化の成否を高度に判断するものではないようです。よって使用する場合にはソースごとに適用するか否かをプログラマがハンダする必要があるようです。

VisualStudio 2005 Remote Debugの設定

・OSの設定
アプリケーションを実行するコンピュータにユーザアカウントを追加します。開発環境を動作させているコンピュータにログインする時に使用している同じアカウント名とパスワードで管理者ユーザを作成します。
コントロールパネルの管理ツールにあるローカルセキュリティポリシーを起動して、ローカルポリシーのセキュリティオプションにある「ローカルアカウントの共有とセキュリティモデル」の設定を「クラシック」に変更します。
ファイアウォールが有効になっている場合にはリモートデバッグを実行できません。必ず無効にしてください。
・Remote Debuggerのインストール
アプリケーションを実行するコンピュータに対してVisual Studio 2005インストールCDのvsRemote Debugger\x86\rdbgsetup.exeを実行してリモートデバッガをインストールしてください。
・デバッグ用ランタイムDLLのインストール
VC++で作成したネィテブアプリケーションのデバッグにはランタイムDLLが必要です。ランタイムDLLの導入を行わないと、デバッグ版のアプリケーションを実行することができません。以下のフォルダにあるデバッグ用ランタイムDLLを、デバッグするアプリケーションの実行ファイルと同じ場所にコピーします。このときDLLファイルだけではなく、マニュフェストファイルも一緒にコピーしてください。
C:\Program Files\Microsoft Visual Studio 8\VC\redist\Debug_NonRedist\x86\Micorosft.VC80.DebugOpenMP
C:\Program Files\Microsoft Visual Studio 8\VC\redist\Debug_NonRedist\x86\Microsoft.VC80.DebugCRT
C:\Program Files\Microsoft Visual Studio 8\VC\redist\Debug_NonRedist\x86\Microsoft.VC80.DebugMFC
・デバッグの手順
アプリケーションを実行するコンピュータにて「VisualStudio 2005 リモートデバッガ」を起動します。
その後、VisualStudioの開発環境からデバッグのプロセスにアタッチを実行してください。修飾子にアプリケーションを実行するコンピュータのコンピュータ名を指定すると、実行されているプロセスの一覧が表示されるので、デバッグするプロセスを選択します。
サービスのデバッグを行いた場合には、「VisualStudio 2005 リモートデバッガ構成ウィザード」を起動してリモートデバッガがサービスとして動作するように設定します。
・デバッガをサービスとして動作させる
ログイン前のアプリケーションの動作や、サービスとして登録したアプリケーションをデバッグするには、デバッガをサービスとして動作させる必要があります。プログラムメニューから「Visual Studio 2005 リモートデバッガ構成ウィザード」を実行することでサービスとして登録できます。ですが、これだけではまだサービスとしてリモートデバッガを利用することはできません。
リモートデバッガをサービスとして動作させるには、コントロールパネルの管理ツールからサービスを起動してください。Visual Studio 2005 Remote Debuggerというサービスが登録されています。サービスのプロパティを開いて自動起動に変更してください。同時にサービスを実行するアカウントに管理者権限を持つユーザアカウントを指定します。このあと再起動すると、リモートデバッガはサービスとして起動します。

メモリリーク個所の特定

VisualC++に付属しているCランタイムライブラリにはヒープメモリのリークを検出する機能が備わっています。その機能をもちいて、メモリリーク個所を特定してみましょう。
メモリリークの検出
メモリリークを検出するには_CrtDumpMemoryLeaksを呼び出します。このとき未解放のメモリがあればデバッグコンソールにそのメモリアドレスと先頭16バイトのダンプが表示されます。

Dumping objects ->
{108} normal block at 0x00143FC0, 256 bytes long.
Data: 48 65 6C 6C 6F 20 57 6F 72 6C 64 00 CD CD CD CD
Object dump complete.

この中の{}で囲まれた数字は、起動後に何番目に確保さえたメモリかを示します。
メモリリーク個所の特定
メモリリーク箇所を特定するには_CrtSetBreakAllocを使用します。_CrtSetBreakAllocに先ほどの{}で囲まれた数字を指定します。これによりリークしたメモリを確保した個所でアプリケーションを中断することができます。
しかしこの方法ではアプリケーションの起動後、メモリを確保する順番が変動しないことが保障されていないと場所を特定できません。
そういった場合には_CrtMemCheckpointと_CrtMemDumpAllObjectsSinceを組み合わせて使用します。

int breakCnt;
_CrtMemState stateOld;
_CrtMemCheckpoint(&stateOld);
//ここで意図的にメモリを確保してリークさせる
_CrtMemDumpAllObjectsSince(&stateOld); // (1)
_CrtSetBreakAlloc(breakCnt);
//ここでデバッグ対象となる処理をおこなう。
_CrtMemDumpAllObjectsSince(&stateOld); // (2)

処理を行う前のメモリステータスをCrtMemCheckpoint関数で保存し、_CrtMemCheckpoint以降に確保したメモリのうち解放されていない分が_CrtDumpMemoryLeaksと同じように出力されます。
(1)で出力された{00}の番号と、(2)で出力された{00}の番号の差分を算出しておき、次回実行時に(1)の出力を確認したうえでデバッガから_CrtSetBreakAllocのパラメータを設定します。