[BACK]Return to report.html CVS log [TXT][DIR] Up to [local] / www

Diff for /www/report.html between version 1.39 and 1.40

version 1.39, 2015/12/23 20:07:18 version 1.40, 2016/02/24 18:54:29
Line 4 
Line 4 
 <title>OpenBSD problem reports</title>  <title>OpenBSD problem reports</title>
 <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">  <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
 <meta name="description" content="OpenBSD problem report page">  <meta name="description" content="OpenBSD problem report page">
 <meta name="copyright" content="This document copyright 1998-2004 by OpenBSD.">  <meta name="copyright" content="This document copyright 1998-2016 by OpenBSD.">
 <link rel="canonical" href="http://www.openbsd.org/report.html">  <link rel="canonical" href="http://www.openbsd.org/report.html">
 </head>  </head>
   
Line 16 
Line 16 
   
 <h3><font color="#0000e0">Released versions problem reports</font></h3>  <h3><font color="#0000e0">Released versions problem reports</font></h3>
   
 Before reporting bugs/problems with released versions,  Before reporting bugs/problems with released versions, go through this
 go through this checklist:  checklist:
   
 <ol>  <ol>
 <li>First check for <a href="errata.html">patches and notes regarding the   <li>First, check for <a href="errata.html">patches and notes regarding the
         release.</a>       release</a>.
 <li>Next find out if there is a <a href="orders.html">newer release   <li>Next, find out if there is a <a href="orders.html">newer release</a>
         available.</a>       available.
 <li>The last thing to check is for <a href="plus.html">changes made between   <li>Finally, check for <a href="plus.html">changes made between OpenBSD
         OpenBSD versions.</a>       versions</a>.
 </ol>  </ol>
   
 <p>  <p>
 If nothing looks like it addresses your problem, then please become acquainted  If nothing looks like it addresses your problem, then please become acquainted
 with  with <a href="http://www.openbsd.org/cgi-bin/man.cgi?query=sendbug">
 <a href="http://www.openbsd.org/cgi-bin/man.cgi?query=sendbug&amp;sektion=1&amp;format=html">  sendbug(1)</a> before submitting a bug report.
 sendbug(1)</a>  
 before submitting a bug report.  
 <p>  
 Read further down for the <a href="#bugtypes">types of bug reports</a> desired.  
   
 <h3><font color="#0000e0">Current version problem reports</font></h3>  <h3><font color="#0000e0">Current version problem reports</font></h3>
   
 If your problem is with the <i>current</i> source tree rather than a <i>release</i> or  If your problem is with the <i>-current</i> source tree rather than
 <i>stable</i> tree,  <i>-release</i> or <i>-stable</i>,
   
 <ol>  <ol>
 <li>Test the problem at least twice, with source updated a few days apart.   <li>Test the problem at least twice, with source updated a few days apart.
 <li>Do not report source tree compilation problems, unless they persist.   <li>Do not report source tree compilation problems, unless they persist.
         They are almost always your mistake or they are being worked on       They are almost always your mistake, or they are being worked on as you
         as you encounter them.  People working on the project are       encounter them.
         doing <u>make build</u> at least once per day, and usually several times       People working on the project are doing <a href="faq/faq5.html">
         per day with different architectures.       make build</a> at least once per day, and usually several times
 <li>Remember that the <a href="anoncvs.html">anoncvs</a>       per day with different architectures.
         servers are updated significantly behind the actual working source tree.   <li>Remember that the <a href="anoncvs.html">AnonCVS</a> servers are
 <li>Check for <a href="plus.html">changes made between OpenBSD versions</a>       updated a few hours behind the actual working source tree.
         to see if the problem has been addressed.   <li>Check for <a href="plus.html">changes made between OpenBSD versions</a>
 <li>Much care is made in creating snapshots.  Sometimes mistakes are made,       to see if the problem has been addressed.
         and our apologies are extended.  Reading/writing the mailing lists   <li>Much care is made in creating snapshots.
         is more appropriate than sending in a bug report.       Sometimes mistakes are made, and our apologies are extended.
        Reading or writing to the mailing lists is more appropriate than sending
        in a bug report.
 </ol>  </ol>
 <br>  
   
 <h3><font color="#0000e0">How to create a problem report</font></h3>  <h3><font color="#0000e0">How to create a problem report</font></h3>
   
 <b>Always provide as much information as possible</b>.  <b>Always provide as much information as possible</b>.
 Try to pin-point the exact problem.  Try to pinpoint the exact problem.
 Give clear instructions on how to reproduce the problem.  Give clear instructions on how to reproduce the problem.
 Try to describe the problem with as much accuracy and  Try to describe it with as much accuracy and non-confusing terminology
 non-confusing terminology as possible,  as possible, especially if it is not easy to reproduce.
 especially if it is not easy to reproduce.  Describing problems by saying "it crashes" or "I get strange interrupt issues
 Describing problems like "it crashes" or "I get strange interrupt  on this one box that I built" are of no use.
 issues on this one box that I built", are of no use.  Communicate with others (on the mailing lists or any other forum where
 Communicate with others (on the mailing lists,  knowledgeable users congregate) to confirm that the problem is new and
 or any other forum where knowledgeable users congregate)  preferably repeatable.
 to confirm that the problem is new and preferably repeatable.  Please try to make sure it is not a local problem created by using broken
 Please try to make sure it is not a local problem  or unsupported hardware, or by using unsupported build options or software.
 created by broken/unsupported hardware,  
 or by using unsupported build options or software.  
   
 <p>Please don't start fixing problems that  <p>
 require significant work until you are sure you understand them, especially  Please don't start fixing problems that require significant work until you
 during our release periods when we must not change major sections of code.  are sure you understand them, especially during our release periods when we
 If you are going to write significant amounts of code, check various  must not change major sections of code.
 forums to make sure that someone else is not working on the problem  If you are going to write significant amounts of code, mention it on the
   mailing lists to make sure no one else is already working on the problem
 (saving duplication of effort).  (saving duplication of effort).
   
 <p>  <p>
 The following items should be contained in every bug report:  The following items should be contained in every bug report:
   
 <ol>  <ol>
    <li>The exact sequence of steps from startup necessary to reproduce   <li>The exact sequence of steps from startup necessary to reproduce
      the problem. This should be self-contained; it is not enough to send in       the problem.
      a bare command without the arguments and other data you supplied to it.       This should be self-contained; it is not enough to send in a bare
        command without the arguments and other data you supplied to it.
      If a bug requires a particular sequence of events, please list those.       If a bug requires a particular sequence of events, please list those.
      You are encouraged to minimize the size of your example, but this is       You are encouraged to minimize the size of your example, but this is
      not absolutely necessary. If the bug is reproducible, we'll find it       not absolutely necessary.
      either way.       If the bug is reproducible, we'll find it either way.
 <p>  <p>
    <li>The output you got. Please do not say that it "didn't work" or   <li>The output you got.
      "failed". If there is an error message, show it, even if you don't       Please do not just say that it "didn't work" or "failed."
      understand it. If OpenBSD panics with a particular error, say which.       If there is an error message, show it, even if you don't understand it.
      If nothing at all happens, say so. Even if the result       If OpenBSD panics with a particular error, say which.
      of your test case is a program crash or otherwise obvious it might not       If nothing at all happens, say so.
      happen in our testing. The easiest thing is to copy the output from       Even if the result of your test case is a program crash or otherwise
      the terminal, if possible.       obvious, it might not happen in our testing.
        The easiest thing is to copy the output from the terminal, if possible.
 <p>  <p>
        Note: In case of fatal errors, the error message provided might not
           Note: In case of fatal errors, the error message provided       contain all the information available.
           might not contain all the information available.       In that case, also look at the output in the system log files, such
           In that case, also look at the output in the system log files,       as those stored in /var/log.
           such as those stored in /var/log.  Also, if you are dealing with       Also, if you are dealing with an application that has its own log files,
           an application that has its own log files, such as httpd, check       such as httpd, check for errors where it keeps its logs.
           for errors where it keeps its logs (in the case of httpd, this  
           is /var/www/logs).  
   
 <p>  <p>
    <li>The OpenBSD kernel output.  You can get this with the dmesg command,   <li>The OpenBSD kernel output.
         but it is possible that your dmesg output does not contain all the       You can get this with the dmesg command, but it is possible that your
         information that is captured in /var/run/dmesg.boot.  If this is the       dmesg output does not contain all the information that is captured in
         case, include information from both.  <b>Please include this       <tt>/var/run/dmesg.boot</tt>.
         in all bug reports.</b>       If this is the case, include information from both.
        <b>Please include this in all bug reports.</b>
 <p>  <p>
    <li> If you run third-party software which has to do with your bug, say so,   <li>If you run third party software which has to do with your bug, say so,
      including any subversion that software may have. If you are talking about       including what version.
      a CVS or FTP snapshot, mention that, including its date and time.       If you are talking about a snapshot, mention that, including its date
        and time.
 <p>  <p>
    <li>A traceback from your kernel panic.  If your kernel panic'ed, and you   <li>A traceback from your kernel panic.
     are at a <tt><a href="http://www.openbsd.org/cgi-bin/man.cgi?query=ddb&amp;sektion=4&amp;format=html">ddb</a>&gt;</tt>       If your kernel panicked and you are at a
     prompt, then please provide the panic message, as well as the output of       <a href="http://www.openbsd.org/cgi-bin/man.cgi?query=ddb">ddb</a>
     the <tt>trace</tt> and <tt>ps</tt> commands in your bug report as       prompt, please provide the panic message, as well as the output of
     advised. If the machine hangs, try enabling <tt>sysctl ddb.console=1</tt>       the <tt>trace</tt> and <tt>ps</tt> commands in your bug report as
     prior to the hang and getting in DDB via Ctl+Alt+Esc on the keyboard       advised.
     (must be outside of X), or sending BREAK if using a serial console.<br>       If the machine hangs, try enabling <tt>sysctl ddb.console=1</tt>
     If, for some reason, the panic message is not visible, you can get it       prior to the hang and getting in DDB via Ctl+Alt+Esc on the keyboard
     again with the <tt>show panic</tt> command.<br>       (must be outside of X), or sending BREAK if using a serial console.
     <b>This is essential whenever possible. Panic reports without panic message,       If, for some reason, the panic message is not visible, you can get it
     traceback and ps output are useless.</b><br>       again with the <tt>show panic</tt> command.
     The output of <tt>show registers</tt> might be of interest as well.       <b>This is essential whenever possible.
     You might then want to reboot with <tt>boot dump</tt> so that a kernel       Panic reports without the panic message, traceback and ps output are
     image could be saved by <a href="http://www.openbsd.org/cgi-bin/man.cgi?query=savecore&amp;sektion=8&amp;format=html">savecore(8)</a>       useless</b>.
     for further post-mortem debugging as described in the       The output of <tt>show registers</tt> might be of interest as well.
  <a href="http://www.openbsd.org/cgi-bin/man.cgi?query=crash&amp;sektion=8&amp;format=html">crash(8)</a>       You might then want to reboot with <tt>boot dump</tt> so that a kernel
     manpage.       image could be saved by
        <a href="http://www.openbsd.org/cgi-bin/man.cgi?query=savecore">
        savecore(8)</a> for further post-mortem debugging, as described in the
        <a href="http://www.openbsd.org/cgi-bin/man.cgi?query=crash">crash(8)</a>
        man page.
 <p>  <p>
    <li>If you're reporting a problem with the X Window System  on an     <li>If you're reporting a problem with the X Window System on an
    architecture that uses the X.Org server, please include the full     architecture that uses the X.Org server, please include the full
    <tt>/var/log/Xorg.0.log</tt> file in your report in addition     <tt>/var/log/Xorg.0.log</tt> file in your report in addition
    to the dmesg.boot information.     to the <tt>dmesg.boot</tt> information.
   
 </ol>  </ol>
   
 <p>  <p>
 Do not be afraid if your bug report becomes rather lengthy. That is a fact  Do not be afraid if your bug report becomes rather lengthy.
 of life. It's better to report everything the first time than us having to  That is a fact of life.
 squeeze the facts out of you. On the other hand, if your input files are  It's better to report everything the first time than us having to squeeze
 huge, it is fair to ask first whether somebody is interested in looking into  the facts out of you.
 it.  On the other hand, if your input files are huge, it is fair to ask first
   whether somebody is interested in looking into it.
   
 <a name="bugtypes"></a>  <a name="bugtypes"></a>
 <h3><font color="#0000e0">Sending in bug reports</font></h3>  <h3><font color="#0000e0">Sending in bug reports</font></h3>
   
   If possible, use the
   <a href="http://www.openbsd.org/cgi-bin/man.cgi?query=sendbug">sendbug(1)</a>
   command to help generate your bug report.
   It will automatically include some useful information about your hardware
   that helps diagnose many issues.
   This tool requires that your system can properly send email.
   If you cannot use sendbug on a functional OpenBSD machine, please send your
   bug report to <a href="mailto:bugs@openbsd.org">bugs@openbsd.org</a>.
   
 <p>  <p>
 If possible, use the <a href="http://www.openbsd.org/cgi-bin/man.cgi?query=sendbug&amp;sektion=1&amp;format=html">sendbug(1)</a> command to get the bug into our tracking system.  
 Sendbug requires that your system can properly send Internet email.  If you  
 cannot use sendbug on a functional OpenBSD machine, please send your bug report  
 to <a href="mailto:bugs@openbsd.org">bugs@openbsd.org</a>.  
 <p>  
 Perhaps what you are sending in is a feature request, not necessarily a bug.  Perhaps what you are sending in is a feature request, not necessarily a bug.
 New features are accepted, especially with code that implements  New features are accepted, especially with code that implements your suggested
 your suggested new feature.  new feature.
 If someone else writes code for your new feature, the chances are that  
 it will be misunderstood and created so that you will not recognize it.  
   
 <p>  <p>
 For debugging some problems, we must have the hardware that has the  For debugging some problems, we must have the hardware that has the problem.
 problem.  Please remember that the OpenBSD project's resources are limited.  Please remember that the OpenBSD project's resources are limited.
 <a href="want.html">You could donate some hardware.</a>  You could <a href="want.html">donate some hardware</a>.
   
 <p>  
 Types of bug reports in order of desirability:  
 <ol>  
 <li>Repeatable problems with source fixes are the best.  
 <li>Repeatable problems that are not specific to your hardware/software  
      layout.  
 <li>Repeatable problems specific to your software layout.  
 <li>Repeatable problems specific to your hardware layout.  
 <li>Non-repeatable problems -- or problems you do not wish to repeat.  
 </ol>  
   
 </body>  </body>
 </html>  </html>
Legend:
Removed from v.1.39  
changed lines
  Added in v.1.40