小さい頃はエラ呼吸

いつのまにやら肺で呼吸をしています。


【cppcheck】Buffer 'xxx' is being written before its old content has been used.

はじめに

C++の静的解析ツール「cppcheck」でソースコードを静的解析した場合に、以下の警告がでることがあります。

Buffer 'xxx' is being written before its old content has been used.

cppcheckのバージョン
  • v1.64
サンプルプログラム

以下のソースプログラムを解析にかけると表示されます。

#include "stdafx.h"
#include <Windows.h>

int _tmain(int argc, _TCHAR* argv[])
{
	char pBuffer[10];
	char val1[5] = "hoge";
	char val2[5] = "fuga";
	memset(pBuffer, 0, sizeof (pBuffer));
	memcpy(pBuffer, val1, sizeof(val1));

	printf("%s", pBuffer);

	memset(pBuffer, 0, sizeof (pBuffer)); //←この行が原因で警告が出る
	memcpy(pBuffer, val2, sizeof(val2));

	return 0;
}

警告の意味としては、「変数に格納された古い値が使われる前に別の値が格納されたけど無駄な処理じゃない?」、みたいなニュアンスだと思います。ここでは明示的な初期化を意味しているから、ここで警告だされるのは的外れかなと思っています。

この警告が出たら、ソースコードを確認して初期化処理だったら、無視するのが得策だと思います。

【cppcheck】Checking if unsigned variable 'xxx' is less than zero.

はじめに

C++の静的解析ツール「cppcheck」でソースコードを静的解析した場合に、以下の警告がでることがあります。

Checking if unsigned variable 'xxx' is less than zero.

cppcheckのバージョン
  • v1.64
サンプルプログラム

以下のソースプログラムを解析にかけると表示されます。

#include "stdafx.h"
#include <Windows.h>

int _tmain(int argc, _TCHAR* argv[])
{
	ULONG hoge = 0;

	// 何らかの処理

	if (hoge < 0)
	{
		// エラー処理
	}

	return 0;
}

警告の意味は、「unsignedな変数で0未満になることをチェックしている」です。
ULONG(unsigned long)は、正の値しかとらないので、値がマイナスになることはないので、変数の型を誤っているか、エラー処理そのものが不要である可能正があります。

ノットイコール(not equal)記号をIMEで変換する

はじめに

イコールの否定(ノットイコール)を記号を文章中に入力したくて、変換の方法を探してみたら、「いこーる」って打って変換すれば良かったみたい。
f:id:replication:20140427103036p:plain

Windows7のWERでアプリケーションのクラッシュダンプを取得する方法

はじめに

Windows7のWER(Windows Error Reporting)を使うと、アプリケーションが異常終了した際に、クラッシュダンプを採取することができます。

技術/Windows/メモリダンプ取得方法メモ - Glamenv-Septzen.net技術/Windows/メモリダンプ取得方法メモ - Glamenv-Septzen.net

Windowsダンプの極意 エラーが発生したら、まずダンプ解析!
上原 祥市
アスキー・メディアワークス
売り上げランキング: 27,059

WERのレジストリを変更する

1.コマンドプロンプトを右クリックで選択し、管理者として実行します。
2.以下の3つのコマンドを実行し、レジストリを変更します。

reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps" /v DumpFolder /t REG_EXPAND_SZ /d ^%LOCALAPPDATA^%\CrashDumps /f

このコマンドで、クラッシュダンプの保存先を%LOCALAPPDATA%\CrashDumpsに指定しています。

reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps" /v DumpCount /t REG_DWORD /d 10 /f

ダンプファイルの保存回数を10回に指定しています。

reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps" /v DumpType /t REG_DWORD /d 2 /f

ダンプファイルの種類として、フルダンプを採取します。

以上で設定は終了です。アプリケーションが異常終了した際には、以下のフォルダにクラッシュダンプが保存されます。

C:\Users\Administrator\AppData\Local\CrashDumps

WinDbgを使ってクラッシュダンプファイルを解析する

はじめに

前回の記事では、WERの仕組みを使ってアプリケーションがクラッシュした場合に、自動的にクラッシュダンプを吐くようにしました。
この記事では、出力されたクラッシュダンプをWinDbgを使って解析したいと思います。

 ツールを使いこなして、バグハント!
Mario Hewardt Daniel Pravat
アスキー・メディアワークス
売り上げランキング: 517,151

WinDbgの入手

WinDbgは、以下のページからダウンロードすることができます。


インストールウィザードに従い、WinDbgのインストールを行います。



WinDbgの起動

スタートメニューから「Windows Kits」→「Debugging Tools for Windows(X86)を展開し、WinDbg(X86)を選択します。

シンボルファイルパスの設定

WinDbgを起動したら、シンボルファイルパスを設定します。
1.FileメニューからSymbol File Path(Ctrl + S)を選択します。

2.以下のパスを指定し、OKボタンをクリックします。

SRV*c:\symbols*http://msdl.microsoft.com/download/symbols


これで、ダンプファイルの解析時に、c:\symbolsフォルダが自動的に作成され、マイクロソフトのサイトからシンボルファイルがダウンロードされるようになります。

さらに、クラッシュしたアプリケーションのシンボルファイル(.pdb)がある場合は、そのファイルパスも指定すると解析の助けとなります。複数のシンボルファイルパスを指定する場合は、セミコロンで連結します。

ダンプファイルを解析する

シンボルファイルの設定が完了したら、ダンプファイルをドラッグ&ドロップで読み込ませます。

いよいよ、ダンプファイルの解析を行います。画面下部のコマンド欄に以下のコマンドを入力すると、解析がはじまります。

!analyze -v


解析が完了すると、以下のようなコールスタックが出力されます。クラッシュの原因となった関数名が分かるかもしれません。