-
Notifications
You must be signed in to change notification settings - Fork 33
/
Copy pathdebug.jax
171 lines (119 loc) · 8.95 KB
/
debug.jax
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
*debug.txt* For Vim バージョン 9.1. Last change: 2024 May 11
VIMリファレンスマニュアル by Bram Moolenaar
Vim のデバッグ *debug-vim*
これは、Vim 自体が正しく動作しない場合にデバッグするためのものである。
Vim script や関数などのデバッグについては、|debug-scripts| を参照。
1. gcc と gdb を使ってクラッシュの場所を特定する |debug-gcc|
2. メモリリークの特定 |debug-leaks|
3. Windows でのバグレポート |debug-win32|
==============================================================================
1. gcc と gdb を使ってクラッシュの場所を特定する *debug-gcc* *gdb*
Vim がテストファイルの 1 つでクラッシュし、コンパイルに gcc を使用している場
合、Vim がどこでクラッシュするかを正確に見つけるためにできることがある。これは
MingW ツールを使用している場合にも当てはまる。
1. "-g" オプション付きで Vim をコンパイル (src/Makefile にそのための行があるの
で、それをコメントアウトする)。さらに "strip" を無効化する (strip をインス
トールしないか、"STRIP = /bin/true" の行を使う)。
2. 次のコマンドを実行する ("11" の所を失敗したテストの番号に変える): >
cd testdir
gdb ../vim
run -u unix.vim -U NONE -s dotest.in test11.in
3. Vim のクラッシュを確認する。gdb は関連するメッセージを表示するはずである。
4. 次のコマンドでスタックトレースを表示できる: >
where
< 次のコマンドで別の場所のスタックトレースを表示できる: >
frame 3
< "3" をスタックトレース内の番号の 1 つに置き換える。
==============================================================================
2. メモリリークの特定 *debug-leaks* *valgrind*
Linux を使っていて Vim がメモリリークしていると思われる場合は、メモリリークを
正確に特定するのに valgrind ツールが非常に役立つ。
まず、EXITFREE を定義して Vim をビルドする。MAKEFILE でこれを検索して、行のコ
メントを外す。
次のコマンドで Vim を起動する:
>
valgrind --log-file=valgrind.log --leak-check=full ./vim
Note: Vim の実行はとても遅くなる。.vimrc が大きかったり多くのプラグインを入れ
ていたりすると起動にとても時間がかかるので、その場合は "--clean" 引数を指定し
て起動する。
ライブラリがメモリリークを起こしている場合もよくある。例えば getpwuid() や
XtVaAppCreateShell() など。それらを避けることはできない。リークしているバイト
数は数キロバイト以下のはずである。
==============================================================================
3. Windows でのバグレポート *debug-win32*
Windows版の Vim が再現可能な手段でクラッシュした場合、次の方法で有用なバグレ
ポートを作成できる。
3.1 一般事項 ~
実行可能ファイルに対応したデバッグシンボルファイル (PDB) を取得する必要がある。
gvim.exe には gvim.pdb、vim.exe には vim.pdb が必要である。あなたが実行可能ファ
イルを入手したのと同じ場所に用意されているはずである。EXE に対応した (同じ日付
の) PDB でなければならない。
Microsoft Visual C++ コンパイラを使って自分で実行可能ファイルを作成した場合は、
PDB は EXE と一緒に作成されている。
Visual Studio を持っている場合、VC Toolkit と WinDbg の代わりにそれを使用する。
他のコンパイラを使っている場合は、それぞれ適切なデバッガを使用する必要がある。
Cygwin または MinGW のコンパイラ用の gdb (上記参照 |debug-gcc|) など。
*debug-vs2005*
3.2 Visual Studio 2005/Visual C++ 2005 Express で Vim をデバッグする ~
最初に、vim.exe か gvim.exe を起動し、Visual Studio を起動する。(Visual Studio
を持っていない場合は、|get-ms-debuggers| の説明に従って、無料の Visual C++
2005 Express Edition を入手する。)
メニューから「ツール/プロセスにアタッチ」を選択し、Vim のプロセスを選択する。
そして、Vim を操作してクラッシュを再現する。「ハンドルされていない例外が発生し
ました」という Visual Studio のダイアログが表示されるので、中断ボタンをクリッ
クしてプロセスを中断する。
シンボルが読み込めず、ソースコードを表示できなかったときは、もう 1 つダイアロ
グが表示される。OK をクリックする。
ウィンドウがいくつか開く。呼び出し履歴ウィンドウの右クリックメニューから「シン
ボルの読み込み」を選択する。シンボル検索ダイアログが開くので、(g)vim.pdb のあ
るディレクトリを選択する。
このとき、呼び出し履歴ウィンドウには Vim の関数名や行番号が表示されているはず
である。どれかをダブルクリックするとソースの検索ダイアログが表示される。Vim の
ソースがあるディレクトリを選択する (ソースがあれば)。
さらに詳しくデバッグする方法が分からないときは、":help bug-reports" の説明に
従う。バグレポートに呼び出し履歴を貼り付ける。
有料版の Visual Studio を使っている場合は、デバッグメニューから minidump を保
存できるので、それをバグレポートに添付する。minidump は 100KB 以下の小さなファ
イルで、Vim のプロセスに関する情報が入っている。
Visual C++ 2005 Express Edition では minidump を保存できない。just-in-time デ
バッガ (クラッシュを検出して自動的に起動されるデバッガ) もインストールされな
い。それらが必要なときは WinDbg (|debug-windbg|) を使う。
*debug-windbg*
3.3 WinDbg を使って Vim をデバッグする ~
WinDbg の入手方法は |get-ms-debuggers| を参照。
Visual Studio IDE を使うのと同じように、WinDbg から Vim のプロセスにアタッチで
きる。プログラムがクラッシュしたときに、事後分析デバッガ (postmortem debugger)
として、WinDebug を自動的に起動することができる。事後分析デバッガとして WinDeb
を設定するには "windbg -I" を実行する。
WinDbg から、実行中の Vim のプロセスにアタッチするには、WinDeb を起動し、File
メニューから「プロセスにアタッチ」を選択し、Vim のプロセスを選択して OK をク
リックする。
メニューから「File->Symbol File Path」を選択し、Vim PDB の入っているフォルダを
symbolpath に追加する。Vim のソースファイルもある場合は、File メニューの
Source File Path を使う。WinDbg でソースファイルを開いたり、ブレークポイントを
設定したりできる。Vim をクラッシュさせると、クラッシュした場所のソースファイル
が WinDbg で開かれる。View メニューを使って、コールスタック、ローカル変数、
ウォッチウィンドウなどを見ることができる。
事後分析デバッガとして WinDbg を使っている場合、WinDbg から Vim のプロセスにア
タッチする必要はない。Vim をクラッシュさせるだけで WinDbg が自動的に起動する。
上述のように、シンボルファイルパスとソースファイルパスを設定する。
minidump を保存するには、WinDbg コマンドラインで次のコマンドを入力する: >
.dump vim.dmp
<
*debug-minidump*
3.4 Minidump を開く ~
Visual Studio か WinDbg を使って minidump を開くことができる。
Visual Studio 2005 の場合: メニューから「ファイル->開く->プロジェクト/ソリュー
ション」選択し、.dmp ファイルを開く。F5 キーを押してデバッガを起動する。
|debug-vs2005| の指示に従って Symbol File Path を設定する。
WinDbg の場合: メニューから「File->Open Crash Dump」を選択する。|debug-windbg|
の指示に従って Symbol File Path を設定する。
*get-ms-debuggers*
3.5 Microsoft デバッグツールの入手方法 ~
Windows 用のデバッグツールは次の場所からダウンロードできる
https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/debugger-download-tools
これには WinDbg デバッガが含まれている。
Visual C++ 2005 Express Edition は次の場所から無料でダウンロードできる。
http://msdn.microsoft.com/vstudio/express/visualC/default.aspx
=========================================================================
vim:tw=78:ts=8:noet:ft=help:norl: