Bram Moolenaar | f9393ef | 2006-04-24 19:47:27 +0000 | [diff] [blame] | 1 | *debug.txt* For Vim version 7.0f. Last change: 2006 Apr 24 |
Bram Moolenaar | e344bea | 2005-09-01 20:46:49 +0000 | [diff] [blame] | 2 | |
| 3 | |
| 4 | VIM REFERENCE MANUAL by Bram Moolenaar |
| 5 | |
| 6 | |
| 7 | Debugging Vim *debug-vim* |
| 8 | |
| 9 | This is for debugging Vim itself, when it doesn't work properly. |
Bram Moolenaar | acf5345 | 2005-12-17 22:06:52 +0000 | [diff] [blame] | 10 | For debugging Vim scripts, functions, etc. see |debug-scripts| |
Bram Moolenaar | e344bea | 2005-09-01 20:46:49 +0000 | [diff] [blame] | 11 | |
| 12 | 1. Location of a crash, using gcc and gdb |debug-gcc| |
| 13 | 2. Windows Bug Reporting |debug-win32| |
| 14 | |
| 15 | ============================================================================== |
| 16 | |
| 17 | 1. Location of a crash, using gcc and gdb *debug-gcc* |
| 18 | |
| 19 | When Vim crashes in one of the test files, and you are using gcc for |
| 20 | compilation, here is what you can do to find out exactly where Vim crashes. |
| 21 | This also applies when using the MingW tools. |
| 22 | |
| 23 | 1. Compile Vim with the "-g" option (there is a line in the Makefile for this, |
| 24 | which you can uncomment). |
| 25 | |
| 26 | 2. Execute these commands (replace "11" with the test that fails): > |
| 27 | cd testdir |
| 28 | gdb ../vim |
| 29 | run -u unix.vim -U NONE -s dotest.in test11.in |
| 30 | |
| 31 | 3. Check where Vim crashes, gdb should give a message for this. |
| 32 | |
| 33 | 4. Get a stack trace from gdb with this command: > |
| 34 | where |
| 35 | < You can check out different places in the stack trace with: > |
| 36 | frame 3 |
| 37 | < Replace "3" with one of the numbers in the stack trace. |
| 38 | |
| 39 | ============================================================================== |
| 40 | |
| 41 | 2. Windows Bug Reporting *debug-win32* |
| 42 | |
Bram Moolenaar | f9393ef | 2006-04-24 19:47:27 +0000 | [diff] [blame] | 43 | If the Windows version of Vim crashes in a reproducible manner, you can take |
| 44 | some steps to provide a useful bug report. |
Bram Moolenaar | e344bea | 2005-09-01 20:46:49 +0000 | [diff] [blame] | 45 | |
Bram Moolenaar | f9393ef | 2006-04-24 19:47:27 +0000 | [diff] [blame] | 46 | |
| 47 | GENERIC ~ |
| 48 | |
| 49 | You must obtain the debugger symbols (PDB) file for your executable: gvim.pdb |
| 50 | for gvim.exe, or vim.pdb for vim.exe. It should be available from the same |
| 51 | place that you obtained the executable. Be sure to use the PDB that matches |
| 52 | the EXE (same date). |
Bram Moolenaar | e344bea | 2005-09-01 20:46:49 +0000 | [diff] [blame] | 53 | |
| 54 | If you built the executable yourself with the Microsoft Visual C++ compiler, |
| 55 | then the PDB was built with the EXE. |
| 56 | |
Bram Moolenaar | f9393ef | 2006-04-24 19:47:27 +0000 | [diff] [blame] | 57 | Alternatively, if you have the source files, you can import Make_ivc.mak into |
| 58 | Visual Studio as a workspace. Then select a debug configuration, build and |
| 59 | you can do all kinds of debugging (set breakpoints, watch variables, etc.). |
| 60 | |
| 61 | If you have Visual Studio, use that instead of the VC Toolkit and WinDbg. |
| 62 | |
| 63 | For other compilers, you should always use the corresponding debugger: TD for |
| 64 | a Vim executable compiled with the Borland compiler; gdb (see above |
| 65 | |debug-gcc|) for the Cygwin and MinGW compilers. |
| 66 | |
| 67 | |
| 68 | Debugging Vim crashes with Visual Studio 2005/Visual C++ 2005 Express ~ |
| 69 | |
| 70 | First launch vim.exe or gvim.exe and then launch Visual Studio. (If you don't |
| 71 | have Visual Studio, follow the instructions in src/INSTALLpc.txt to obtain a |
| 72 | free copy of Visual C++ 2005 Express Edition.) |
| 73 | |
| 74 | On the Tools menu, click Attach to Process. Choose the Vim process. |
| 75 | |
| 76 | In Vim, reproduce the crash. A dialog will appear in Visual Studio, telling |
| 77 | you about the unhandled exception in the Vim process. Click Break to break |
| 78 | into the process. |
| 79 | |
| 80 | Visual Studio will pop up another dialog, telling you that no symbols are |
| 81 | loaded and that the source code cannot be displayed. Click OK. |
| 82 | |
| 83 | Several windows will open. Right-click in the Call Stack window. Choose Load |
| 84 | Symbols. The Find Symbols dialog will open, looking for (g)vim.pdb. Navigate |
| 85 | to the directory where you have the PDB file and click Open. |
| 86 | |
| 87 | At this point, you should have a full call stack with vim function names and |
| 88 | line numbers. Double-click one of the lines and the Find Source dialog will |
| 89 | appear. Navigate to the directory where the Vim source is (if you have it.) |
| 90 | |
| 91 | If you don't know how to debug this any further, follow the instructions |
| 92 | at ":help bug-reports". Paste the call stack into the bug report. |
| 93 | |
| 94 | If you have a non-free version of Visual Studio, you can save a minidump via |
| 95 | the Debug menu and send it with the bug report. A minidump is a small file |
| 96 | (<100KB), which contains information about the state of your process. |
| 97 | |
| 98 | |
| 99 | Debugging Vim with Debugging Tools ~ |
| 100 | |
Bram Moolenaar | e344bea | 2005-09-01 20:46:49 +0000 | [diff] [blame] | 101 | You can download the Microsoft Visual C++ Toolkit from |
| 102 | http://msdn.microsoft.com/visualc/vctoolkit2003/ |
| 103 | This contains the command-line tools, but not the Visual Studio IDE. |
| 104 | |
| 105 | The Debugging Tools for Windows can be downloaded from |
| 106 | http://www.microsoft.com/whdc/devtools/debugging/default.mspx |
| 107 | This includes the WinDbg debugger. |
| 108 | |
Bram Moolenaar | e344bea | 2005-09-01 20:46:49 +0000 | [diff] [blame] | 109 | |
| 110 | ========================================================================= |
| 111 | vim:tw=78:ts=8:ft=help:norl: |