▼ 2009/1/19 (月) 11:43:46 anonymous 　
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; InfoPath.1) Sleipnir/2.8.4
[770] Grepでアクセスバイオレーション
rev1495以降のテストバイナリで、Grep時にアクセスバイオレーションが発生します。
rev1495、rev1501、rev1516で確認しています。rev1428以前やANSI版では発生しません。
Grep中、一定量の検索をすると落ちるように見えます。
現状詳しい再現条件はわかりません。

他の方々の報告がないため、当方の環境に起因するものかとも考えましたが、
ダウンロードしてきたテストバイナリをそのまま起動しても現象は発生しました。

下記のどの環境でも発生しました。
・Win XP SP2 (JP)
・Win XP SP3 (JP)
・Win XP SP2 (ENG)
・Win XP SP2 (ENG)
・Win 2000 SP4 (ENG)

再現手順や詳細などが必要でしたらその旨お伝えください。
できる限りの情報を集めようと思います。


▼ 2009/1/19 (月) 21:03:09 ryoji 　
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; InfoPath.1; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
[771] Re:Grepでアクセスバイオレーション
単純にGrepするだけでは自分の環境では起きないみたいです。
クラッシュ時にミニダンプを採取するようにしたものを作ったので、それを使ってanonymousさんのWin XP SP3 (JP)環境で再現させて、ダンプファイル（35KB程度）をUpしていただけないでしょうか？

BugReport/25
http://sakura.qp.land.to/?BugReport%2F25
▼ 2009/1/20 (火) 19:32:02 anonymous 　
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022) Sleipnir/2.8.4
[774] Re2:Grepでアクセスバイオレーション
素早いレス、ありがとうございます。

Platform SDKはインストールしておらず、みなさんで再現できる条件ではないかもしれないのが心苦しいですが・・・。
trunk2などのソースで再現してみようとしましたが、再現しませんでした。

以下、詳細情報になります。

・D:\xampp 下で、"src"をGrep
・Grep条件入力のチェックボックスは、サブフォルダからも検索するにチェック、それ以外はチェック無し
・結果出力、結果出力形式はそれぞれどちらでも再現
・リアルタイム表示のチェックの有無に関わらず発生
・Grep中の窓では784件、リアルタイム表示では793行目まで表示されたあたりで落ちる。(Grepの終了前)

ひとまずこれくらいあげておきます。
切り分けに必要な手順等あれば情報ください。
▼ 2009/1/20 (火) 22:34:41 anonymous 　
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022) Sleipnir/2.8.4
[776] Re3:Grepでアクセスバイオレーション
肝心なことを・・・。
ダンプファイル、以下にあげておきました。
BugReport/25
http://sakura.qp.land.to/?BugReport%2F25

syatさんの環境でも再現できたようなのでもうあまり必要ではないかもしれませんが・・・。
▼ 2009/1/21 (水) 00:01:06 ryoji 　
Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5 (.NET CLR 3.5.30729)
[777] 「CheckKanjiCode の修正(rev1472)」の問題かしら？
ダンプファイルを見てみました。
解析状況を報告しておきます。

発生しているエラー内容:
0x00422e30 (sakuraW.exe) でハンドルされていない例外が発生しました: 0xC0000005: 場所 0x09647bf8 を読み込み中にアクセス違反が発生しました。

エラー箇所:
ECodeType CCodeMediator::DetectUnicode( CESI* pcesi ) の最終行
CCodeMediator.cpp(118):
	return pcesi->m_aWcInfo[ pcesi->GetBOMType() ].eCodeID;
のところで落ちています。
この関数は、
rev1472 [Fix] CheckKanjiCode の修正＋α(>>unicode:711)
で追加されたもののようなので、rev1472 を境に問題が起きるようになった可能性があります。
＃自分はまだこの周辺のコードを読んでないので、今のところ原因まではわかりません。

呼び出し元を辿ると、

ECodeType CCodeMediator::CheckKanjiCode( const char* pBuf, int nBufLen )
CCodeMediator.cpp(158)
↑
ECodeType CFileLoad::FileOpen( LPCTSTR pFileName, ECodeType CharCode, int nFlag, bool* pbBomExist )
CFileLoad.cpp(147)
↑
int CGrepAgent::DoGrepFile(
CGrepAgent.cpp(1021)

になってます。
▼ 2009/1/21 (水) 00:28:58 げんた 　
INCM1.23c
[778] Re: 「CheckKanjiCode の修正(rev1472)」の問題かしら？
>エラー箇所:
>ECodeType CCodeMediator::DetectUnicode( CESI* pcesi ) の最終行
>CCodeMediator.cpp(118):
>        return pcesi->m_aWcInfo[ pcesi->GetBOMType() ].eCodeID;
>のところで落ちています。
GetBOMType()が取り得る値の1つにESI_BOMTYPE_UNKNOWNがあり，CESI.hでこれが -1 と定義されています．
ESI_BOMTYPE_LE,ESI_BOMTYPE_BEのどちらとも判定できなかった場合に確保したアドレスより手前にアクセスしてしまうのではないでしょうか．

あ，でも手前には他の変数がありますね．
逆に直後にあるm_eWcBomTypeが何か別の値で上書きされて，その後ここを通るととんでもないところにアクセスするのでしょうか．

アクセスしたアドレスとpcesiのアドレスからm_aWcInfo[]のインデックスが分かるとヒントになるかもしれませんね．
(外してたらごめんなさい)
▼ 2009/1/21 (水) 18:42:23 ryoji 　
Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5 (.NET CLR 3.5.30729)
[781] Re2: 「CheckKanjiCode の修正(rev1472)」の問題かしら？
修正してコミットしました（>>unicode:779）

対象とするファイルのサイズがゼロのとき、
CCodeMediator::CheckKanjiCode()の
        pcesi->SetInformation()
がfalseを返すのにそのまま
        nret = DetectUnicode( pcesi );
に突入してしまうのがまずかったようです。
pcesi->m_eWcBomType
の値が不確定のままなのでm_aWcInfo[]のインデックスがとんでもない値になってました。
▼ 2009/1/22 (木) 00:59:24 anonymous 　
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022) Sleipnir/2.8.4
[783] Re3: 「CheckKanjiCode の修正(rev1472)」の問題かしら？
> 修正してコミットしました（>>unicode:779）
対応ありがとうございます。
rev1519のバイナリにて、思う存分Grepできています。

当方、試用、不具合報告くらいしか協力できませんが、応援しております。
▼ 2009/1/22 (木) 14:26:19 ラスティブ 　
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5 (.NET CLR 3.5.30729)
[784] Re3: 「CheckKanjiCode の修正(rev1472)」の問題かしら？
▼ ryojiさん
> 修正してコミットしました（>>unicode:779）
>
> 対象とするファイルのサイズがゼロのとき、
> CCodeMediator::CheckKanjiCode()の
>         pcesi->SetInformation()
> がfalseを返すのにそのまま
>         nret = DetectUnicode( pcesi );
> に突入してしまうのがまずかったようです。
> pcesi->m_eWcBomType
> の値が不確定のままなのでm_aWcInfo[]のインデックスがとんでもない値になってました。

ANSI 版のパッチに反映させました。
修正ありがとうございました。メモリリークのほうなど、
すっかり見落としていて自分では見つけられそうになかったです（汗）
重ね重ね、ありがとうございました。
▼ 2009/1/20 (火) 12:52:35 di 　
Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4
[772] Re:Grepでアクセスバイオレーション
私の環境でも同様にGrepで稀に落ちるようになりました。
発生し始めたリビジョンも同じかと。
拡張子のフィルタリング等で母体数を減らすと落ちなくなっている感じです。
環境はWinXP SP3です。

#ダンプの取得に協力したいのは山々ですが、職場のセキュリティの関係で
#ファイルのアップロードが出来ません．．．無念。orz
▼ 2009/1/20 (火) 18:34:07 anonymous 　
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648)
[773] Re:Grepでアクセスバイオレーション
もう少し詳細情報をください。
・Grep条件は、何文字くらい？全角文字を含む？
・ファイルは、*.*のみ？　除外指定してる？
・単語単位で探す、大文字小文字区別などのチェック状態は？
・正規表現は使ってます？
・検索ファイル数は何ファイルくらい？単に母体数が多いと言われても人それぞれですから
・ヒット数は何件くらい？
・たとえば、Program Files\Platform SDK\Samplesを検索するとかなら他の人もできます
▼ 2009/1/20 (火) 21:49:38 syat 　
Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5
[775] Re2:Grepでアクセスバイオレーション
私の環境でも再現しました。
http://www.apachefriends.org/jp/xampp-windows.html
xamppのzipを適当な場所に解凍し、その中でsrcをGrepすると落ちます。鉄板。
バイナリファイル内を検索したときに落ちている雰囲気です。
▼ 2009/1/21 (水) 18:45:03 ryoji 　
Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5 (.NET CLR 3.5.30729)
[782] Re3:Grepでアクセスバイオレーション
▼ syatさん
> 私の環境でも再現しました。

情報ありがとうございます。
僕のところでもこれで再現しました。(^^;
コミットした修正(>>unicode:779)での動作確認に使用しました。
INCM/CMT
Cyclamen v3.81
[ut:0.010][st:0.010]