mingw/info/gdb/Bug-Reporting.html

   1 <html lang="en">
   2 <head>
   3 <title>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.3">
   7 <link href="http://www.gnu.org/software/texinfo/" rel="generator-home">
   8 </head>
   9 <body>
  10 <div class="node">
  11 <p>
  12 Node:<a name="Bug%20Reporting">Bug Reporting</a>,
  13 Previous:<a rel="previous" accesskey="p" href="Bug-Criteria.html#Bug%20Criteria">Bug Criteria</a>,
  14 Up:<a rel="up" accesskey="u" href="GDB-Bugs.html#GDB%20Bugs">GDB Bugs</a>
  15 <hr><br>
  16 </div>
  17
  18 <h3 class="section">How to report bugs</h3>
  19
  20    <p>A number of companies and individuals offer support for <small>GNU</small> products.
  21 If you obtained GDB from a support organization, we recommend you
  22 contact that organization first.
  23
  24    <p>You can find contact information for many support companies and
  25 individuals in the file <code>etc/SERVICE</code> in the <small>GNU</small> Emacs
  26 distribution.
  27
  28    <p>In any event, we also recommend that you submit bug reports for
  29 GDB.  The prefered method is to submit them directly using
  30 <a href="http://www.gnu.org/software/gdb/bugs/">GDB's Bugs web page</a>.  Alternatively, the <a href="mailto:bug-gdb@gnu.org">e-mail gateway</a> can
  31 be used.
  32
  33    <p><strong>Do not send bug reports to </strong><code>info-gdb</code><strong>, or to
  34 </strong><code>help-gdb</code><strong>, or to any newsgroups.</strong>  Most users of GDB do
  35 not want to receive bug reports.  Those that do have arranged to receive
  36 <code>bug-gdb</code>.
  37
  38    <p>The mailing list <code>bug-gdb</code> has a newsgroup <code>gnu.gdb.bug</code> which
  39 serves as a repeater.  The mailing list and the newsgroup carry exactly
  40 the same messages.  Often people think of posting bug reports to the
  41 newsgroup instead of mailing them.  This appears to work, but it has one
  42 problem which can be crucial: a newsgroup posting often lacks a mail
  43 path back to the sender.  Thus, if we need to ask for more information,
  44 we may be unable to reach you.  For this reason, it is better to send
  45 bug reports to the mailing list.
  46
  47    <p>The fundamental principle of reporting bugs usefully is this:
  48 <strong>report all the facts</strong>.  If you are not sure whether to state a
  49 fact or leave it out, state it!
  50
  51    <p>Often people omit facts because they think they know what causes the
  52 problem and assume that some details do not matter.  Thus, you might
  53 assume that the name of the variable you use in an example does not matter.
  54 Well, probably it does not, but one cannot be sure.  Perhaps the bug is a
  55 stray memory reference which happens to fetch from the location where that
  56 name is stored in memory; perhaps, if the name were different, the contents
  57 of that location would fool the debugger into doing the right thing despite
  58 the bug.  Play it safe and give a specific, complete example.  That is the
  59 easiest thing for you to do, and the most helpful.
  60
  61    <p>Keep in mind that the purpose of a bug report is to enable us to fix the
  62 bug.  It may be that the bug has been reported previously, but neither
  63 you nor we can know that unless your bug report is complete and
  64 self-contained.
  65
  66    <p>Sometimes people give a few sketchy facts and ask, "Does this ring a
  67 bell?"  Those bug reports are useless, and we urge everyone to
  68 <em>refuse to respond to them</em> except to chide the sender to report
  69 bugs properly.
  70
  71    <p>To enable us to fix the bug, you should include all these things:
  72
  73      <ul>
  74 <li>The version of GDB.  GDB announces it if you start
  75 with no arguments; you can also print it at any time using <code>show
  76 version</code>.
  77
  78      <p>Without this, we will not know whether there is any point in looking for
  79 the bug in the current version of GDB.
  80
  81      </p><li>The type of machine you are using, and the operating system name and
  82 version number.
  83
  84      <li>What compiler (and its version) was used to compile GDB--e.g.
  85 "gcc-2.8.1".
  86
  87      <li>What compiler (and its version) was used to compile the program you are
  88 debugging--e.g.  "gcc-2.8.1", or "HP92453-01 A.10.32.03 HP
  89 C Compiler".  For GCC, you can say <code>gcc --version</code> to get this
  90 information; for other compilers, see the documentation for those
  91 compilers.
  92
  93      <li>The command arguments you gave the compiler to compile your example and
  94 observe the bug.  For example, did you use <code>-O</code>?  To guarantee
  95 you will not omit something important, list them all.  A copy of the
  96 Makefile (or the output from make) is sufficient.
  97
  98      <p>If we were to try to guess the arguments, we would probably guess wrong
  99 and then we might not encounter the bug.
 100
 101      </p><li>A complete input script, and all necessary source files, that will
 102 reproduce the bug.
 103
 104      <li>A description of what behavior you observe that you believe is
 105 incorrect.  For example, "It gets a fatal signal."
 106
 107      <p>Of course, if the bug is that GDB gets a fatal signal, then we
 108 will certainly notice it.  But if the bug is incorrect output, we might
 109 not notice unless it is glaringly wrong.  You might as well not give us
 110 a chance to make a mistake.
 111
 112      <p>Even if the problem you experience is a fatal signal, you should still
 113 say so explicitly.  Suppose something strange is going on, such as, your
 114 copy of GDB is out of synch, or you have encountered a bug in
 115 the C library on your system.  (This has happened!)  Your copy might
 116 crash and ours would not.  If you told us to expect a crash, then when
 117 ours fails to crash, we would know that the bug was not happening for
 118 us.  If you had not told us to expect a crash, then we would not be able
 119 to draw any conclusion from our observations.
 120
 121      </p><li>If you wish to suggest changes to the GDB source, send us context
 122 diffs.  If you even discuss something in the GDB source, refer to
 123 it by context, not by line number.
 124
 125      <p>The line numbers in our development sources will not match those in your
 126 sources.  Your line numbers would convey no useful information to us.
 127
 128    </ul>
 129
 130    <p>Here are some things that are not necessary:
 131
 132      <ul>
 133 <li>A description of the envelope of the bug.
 134
 135      <p>Often people who encounter a bug spend a lot of time investigating
 136 which changes to the input file will make the bug go away and which
 137 changes will not affect it.
 138
 139      <p>This is often time consuming and not very useful, because the way we
 140 will find the bug is by running a single example under the debugger
 141 with breakpoints, not by pure deduction from a series of examples.
 142 We recommend that you save your time for something else.
 143
 144      <p>Of course, if you can find a simpler example to report <em>instead</em>
 145 of the original one, that is a convenience for us.  Errors in the
 146 output will be easier to spot, running under the debugger will take
 147 less time, and so on.
 148
 149      <p>However, simplification is not vital; if you do not want to do this,
 150 report the bug anyway and send us the entire test case you used.
 151
 152      </p><li>A patch for the bug.
 153
 154      <p>A patch for the bug does help us if it is a good one.  But do not omit
 155 the necessary information, such as the test case, on the assumption that
 156 a patch is all we need.  We might see problems with your patch and decide
 157 to fix the problem another way, or we might not understand it at all.
 158
 159      <p>Sometimes with a program as complicated as GDB it is very hard to
 160 construct an example that will make the program follow a certain path
 161 through the code.  If you do not send us the example, we will not be able
 162 to construct one, so we will not be able to verify that the bug is fixed.
 163
 164      <p>And if we cannot understand what bug you are trying to fix, or why your
 165 patch should be an improvement, we will not install it.  A test case will
 166 help us to understand.
 167
 168      </p><li>A guess about what the bug is or what it depends on.
 169
 170      <p>Such guesses are usually wrong.  Even we cannot guess right about such
 171 things without first using the debugger to find the facts.
 172 </ul>
 173
 174    </body></html>
 175