1<html lang="en"> 2<head> 3<title>Bug Reporting - Debugging with GDB</title> 4<meta http-equiv="Content-Type" content="text/html"> 5<meta name="description" content="Debugging with GDB"> 6<meta name="generator" content="makeinfo 4.13"> 7<link title="Top" rel="start" href="index.html#Top"> 8<link rel="up" href="GDB-Bugs.html#GDB-Bugs" title="GDB Bugs"> 9<link rel="prev" href="Bug-Criteria.html#Bug-Criteria" title="Bug Criteria"> 10<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage"> 11<!-- 12Copyright (C) 1988-2013 Free Software Foundation, Inc. 13 14Permission is granted to copy, distribute and/or modify this document 15under the terms of the GNU Free Documentation License, Version 1.3 or 16any later version published by the Free Software Foundation; with the 17Invariant Sections being ``Free Software'' and ``Free Software Needs 18Free Documentation'', with the Front-Cover Texts being ``A GNU Manual,'' 19and with the Back-Cover Texts as in (a) below. 20 21(a) The FSF's Back-Cover Text is: ``You are free to copy and modify 22this GNU Manual. Buying copies from GNU Press supports the FSF in 23developing GNU and promoting software freedom.'' 24--> 25<meta http-equiv="Content-Style-Type" content="text/css"> 26<style type="text/css"><!-- 27 pre.display { font-family:inherit } 28 pre.format { font-family:inherit } 29 pre.smalldisplay { font-family:inherit; font-size:smaller } 30 pre.smallformat { font-family:inherit; font-size:smaller } 31 pre.smallexample { font-size:smaller } 32 pre.smalllisp { font-size:smaller } 33 span.sc { font-variant:small-caps } 34 span.roman { font-family:serif; font-weight:normal; } 35 span.sansserif { font-family:sans-serif; font-weight:normal; } 36--></style> 37<link rel="stylesheet" type="text/css" href="../cs.css"> 38</head> 39<body> 40<div class="node"> 41<a name="Bug-Reporting"></a> 42<p> 43Previous: <a rel="previous" accesskey="p" href="Bug-Criteria.html#Bug-Criteria">Bug Criteria</a>, 44Up: <a rel="up" accesskey="u" href="GDB-Bugs.html#GDB-Bugs">GDB Bugs</a> 45<hr> 46</div> 47 48<h3 class="section">31.2 How to Report Bugs</h3> 49 50<p><a name="index-bug-reports-2468"></a><a name="index-g_t_0040value_007bGDBN_007d-bugs_002c-reporting-2469"></a> 51A number of companies and individuals offer support for <span class="sc">gnu</span> products. 52If you obtained <span class="sc">gdb</span> from a support organization, we recommend you 53contact that organization first. 54 55 <p>You can find contact information for many support companies and 56individuals in the file <samp><span class="file">etc/SERVICE</span></samp> in the <span class="sc">gnu</span> Emacs 57distribution. 58<!-- should add a web page ref... --> 59 60 <p>In any event, we also recommend that you submit bug reports for 61<span class="sc">gdb</span> to <a href="https://sourcery.mentor.com/GNUToolchain/">https://sourcery.mentor.com/GNUToolchain/</a>. 62 63 <p>The fundamental principle of reporting bugs usefully is this: 64<strong>report all the facts</strong>. If you are not sure whether to state a 65fact or leave it out, state it! 66 67 <p>Often people omit facts because they think they know what causes the 68problem and assume that some details do not matter. Thus, you might 69assume that the name of the variable you use in an example does not matter. 70Well, probably it does not, but one cannot be sure. Perhaps the bug is a 71stray memory reference which happens to fetch from the location where that 72name is stored in memory; perhaps, if the name were different, the contents 73of that location would fool the debugger into doing the right thing despite 74the bug. Play it safe and give a specific, complete example. That is the 75easiest thing for you to do, and the most helpful. 76 77 <p>Keep in mind that the purpose of a bug report is to enable us to fix the 78bug. It may be that the bug has been reported previously, but neither 79you nor we can know that unless your bug report is complete and 80self-contained. 81 82 <p>Sometimes people give a few sketchy facts and ask, “Does this ring a 83bell?” Those bug reports are useless, and we urge everyone to 84<em>refuse to respond to them</em> except to chide the sender to report 85bugs properly. 86 87 <p>To enable us to fix the bug, you should include all these things: 88 89 <ul> 90<li>The version of <span class="sc">gdb</span>. <span class="sc">gdb</span> announces it if you start 91with no arguments; you can also print it at any time using <code>show 92version</code>. 93 94 <p>Without this, we will not know whether there is any point in looking for 95the bug in the current version of <span class="sc">gdb</span>. 96 97 <li>The type of machine you are using, and the operating system name and 98version number. 99 100 <li>The details of the <span class="sc">gdb</span> build-time configuration. 101<span class="sc">gdb</span> shows these details if you invoke it with the 102<samp><span class="option">--configuration</span></samp> command-line option, or if you type 103<code>show configuration</code> at <span class="sc">gdb</span>'s prompt. 104 105 <li>What compiler (and its version) was used to compile <span class="sc">gdb</span>—e.g. 106“gcc–2.8.1”. 107 108 <li>What compiler (and its version) was used to compile the program you are 109debugging—e.g. “gcc–2.8.1”, or “HP92453-01 A.10.32.03 HP 110C Compiler”. For <span class="sc">gcc</span>, you can say <kbd>gcc --version</kbd> 111to get this information; for other compilers, see the documentation for 112those compilers. 113 114 <li>The command arguments you gave the compiler to compile your example and 115observe the bug. For example, did you use ‘<samp><span class="samp">-O</span></samp>’? To guarantee 116you will not omit something important, list them all. A copy of the 117Makefile (or the output from make) is sufficient. 118 119 <p>If we were to try to guess the arguments, we would probably guess wrong 120and then we might not encounter the bug. 121 122 <li>A complete input script, and all necessary source files, that will 123reproduce the bug. 124 125 <li>A description of what behavior you observe that you believe is 126incorrect. For example, “It gets a fatal signal.” 127 128 <p>Of course, if the bug is that <span class="sc">gdb</span> gets a fatal signal, then we 129will certainly notice it. But if the bug is incorrect output, we might 130not notice unless it is glaringly wrong. You might as well not give us 131a chance to make a mistake. 132 133 <p>Even if the problem you experience is a fatal signal, you should still 134say so explicitly. Suppose something strange is going on, such as, your 135copy of <span class="sc">gdb</span> is out of synch, or you have encountered a bug in 136the C library on your system. (This has happened!) Your copy might 137crash and ours would not. If you told us to expect a crash, then when 138ours fails to crash, we would know that the bug was not happening for 139us. If you had not told us to expect a crash, then we would not be able 140to draw any conclusion from our observations. 141 142 <p><a name="index-script-2470"></a><a name="index-recording-a-session-script-2471"></a>To collect all this information, you can use a session recording program 143such as <samp><span class="command">script</span></samp>, which is available on many Unix systems. 144Just run your <span class="sc">gdb</span> session inside <samp><span class="command">script</span></samp> and then 145include the <samp><span class="file">typescript</span></samp> file with your bug report. 146 147 <p>Another way to record a <span class="sc">gdb</span> session is to run <span class="sc">gdb</span> 148inside Emacs and then save the entire buffer to a file. 149 150 <li>If you wish to suggest changes to the <span class="sc">gdb</span> source, send us context 151diffs. If you even discuss something in the <span class="sc">gdb</span> source, refer to 152it by context, not by line number. 153 154 <p>The line numbers in our development sources will not match those in your 155sources. Your line numbers would convey no useful information to us. 156 157 </ul> 158 159 <p>Here are some things that are not necessary: 160 161 <ul> 162<li>A description of the envelope of the bug. 163 164 <p>Often people who encounter a bug spend a lot of time investigating 165which changes to the input file will make the bug go away and which 166changes will not affect it. 167 168 <p>This is often time consuming and not very useful, because the way we 169will find the bug is by running a single example under the debugger 170with breakpoints, not by pure deduction from a series of examples. 171We recommend that you save your time for something else. 172 173 <p>Of course, if you can find a simpler example to report <em>instead</em> 174of the original one, that is a convenience for us. Errors in the 175output will be easier to spot, running under the debugger will take 176less time, and so on. 177 178 <p>However, simplification is not vital; if you do not want to do this, 179report the bug anyway and send us the entire test case you used. 180 181 <li>A patch for the bug. 182 183 <p>A patch for the bug does help us if it is a good one. But do not omit 184the necessary information, such as the test case, on the assumption that 185a patch is all we need. We might see problems with your patch and decide 186to fix the problem another way, or we might not understand it at all. 187 188 <p>Sometimes with a program as complicated as <span class="sc">gdb</span> it is very hard to 189construct an example that will make the program follow a certain path 190through the code. If you do not send us the example, we will not be able 191to construct one, so we will not be able to verify that the bug is fixed. 192 193 <p>And if we cannot understand what bug you are trying to fix, or why your 194patch should be an improvement, we will not install it. A test case will 195help us to understand. 196 197 <li>A guess about what the bug is or what it depends on. 198 199 <p>Such guesses are usually wrong. Even we cannot guess right about such 200things without first using the debugger to find the facts. 201</ul> 202 203<!-- The readline documentation is distributed with the readline code --> 204<!-- and consists of the two following files: --> 205<!-- rluser.texi --> 206<!-- hsuser.texi --> 207<!-- Use -I with makeinfo to point to the appropriate directory, --> 208<!-- environment var TEXINPUTS with TeX. --> 209<!-- %**start of header (This is for running Texinfo on a region.) --> 210<!-- %**end of header (This is for running Texinfo on a region.) --> 211<!-- If you are including this manual as an appendix, then set the --> 212<!-- variable readline-appendix. --> 213 </body></html> 214 215