diff options
Diffstat (limited to 'docs/htmldocs/Bugs.html')
| -rw-r--r-- | docs/htmldocs/Bugs.html | 238 |
1 files changed, 238 insertions, 0 deletions
diff --git a/docs/htmldocs/Bugs.html b/docs/htmldocs/Bugs.html new file mode 100644 index 0000000000..0f7fb7bd60 --- /dev/null +++ b/docs/htmldocs/Bugs.html @@ -0,0 +1,238 @@ +<HTML +><HEAD +><TITLE +>Reporting Bugs</TITLE +><META +NAME="GENERATOR" +CONTENT="Modular DocBook HTML Stylesheet Version 1.57"></HEAD +><BODY +CLASS="ARTICLE" +BGCOLOR="#FFFFFF" +TEXT="#000000" +LINK="#0000FF" +VLINK="#840084" +ALINK="#0000FF" +><DIV +CLASS="ARTICLE" +><DIV +CLASS="TITLEPAGE" +><H1 +CLASS="TITLE" +><A +NAME="BUGREPORT" +>Reporting Bugs</A +></H1 +><HR></DIV +><DIV +CLASS="SECT1" +><H1 +CLASS="SECT1" +><A +NAME="AEN3" +>Introduction</A +></H1 +><P +>The email address for bug reports is samba@samba.org</P +><P +>Please take the time to read this file before you submit a bug +report. Also, please see if it has changed between releases, as we +may be changing the bug reporting mechanism at some time.</P +><P +>Please also do as much as you can yourself to help track down the +bug. Samba is maintained by a dedicated group of people who volunteer +their time, skills and efforts. We receive far more mail about it than +we can possibly answer, so you have a much higher chance of an answer +and a fix if you send us a "developer friendly" bug report that lets +us fix it fast. </P +><P +>Do not assume that if you post the bug to the comp.protocols.smb +newsgroup or the mailing list that we will read it. If you suspect that your +problem is not a bug but a configuration problem then it is better to send +it to the Samba mailing list, as there are (at last count) 5000 other users on +that list that may be able to help you.</P +><P +>You may also like to look though the recent mailing list archives, +which are conveniently accessible on the Samba web pages +at http://samba.org/samba/ </P +></DIV +><DIV +CLASS="SECT1" +><HR><H1 +CLASS="SECT1" +><A +NAME="AEN10" +>General info</A +></H1 +><P +>Before submitting a bug report check your config for silly +errors. Look in your log files for obvious messages that tell you that +you've misconfigured something and run testparm to test your config +file for correct syntax.</P +><P +>Have you run through the <A +HREF="Diagnosis.html" +TARGET="_top" +>diagnosis</A +>? +This is very important.</P +><P +>If you include part of a log file with your bug report then be sure to +annotate it with exactly what you were doing on the client at the +time, and exactly what the results were.</P +></DIV +><DIV +CLASS="SECT1" +><HR><H1 +CLASS="SECT1" +><A +NAME="AEN16" +>Debug levels</A +></H1 +><P +>If the bug has anything to do with Samba behaving incorrectly as a +server (like refusing to open a file) then the log files will probably +be very useful. Depending on the problem a log level of between 3 and +10 showing the problem may be appropriate. A higher level givesmore +detail, but may use too much disk space.</P +><P +>To set the debug level use <B +CLASS="COMMAND" +>log level =</B +> in your +<TT +CLASS="FILENAME" +>smb.conf</TT +>. You may also find it useful to set the log +level higher for just one machine and keep separate logs for each machine. +To do this use:</P +><P +><PRE +CLASS="PROGRAMLISTING" +>log level = 10 +log file = /usr/local/samba/lib/log.%m +include = /usr/local/samba/lib/smb.conf.%m</PRE +></P +><P +>then create a file +<TT +CLASS="FILENAME" +>/usr/local/samba/lib/smb.conf.machine</TT +> where +"machine" is the name of the client you wish to debug. In that file +put any smb.conf commands you want, for example +<B +CLASS="COMMAND" +>log level=</B +> may be useful. This also allows you to +experiment with different security systems, protocol levels etc on just +one machine.</P +><P +>The <TT +CLASS="FILENAME" +>smb.conf</TT +> entry <B +CLASS="COMMAND" +>log level =</B +> +is synonymous with the entry <B +CLASS="COMMAND" +>debuglevel =</B +> that has been +used in older versions of Samba and is being retained for backwards +compatibility of smb.conf files.</P +><P +>As the <B +CLASS="COMMAND" +>log level =</B +> value is increased you will record +a significantly increasing level of debugging information. For most +debugging operations you may not need a setting higher than 3. Nearly +all bugs can be tracked at a setting of 10, but be prepared for a VERY +large volume of log data.</P +></DIV +><DIV +CLASS="SECT1" +><HR><H1 +CLASS="SECT1" +><A +NAME="AEN33" +>Internal errors</A +></H1 +><P +>If you get a "INTERNAL ERROR" message in your log files it means that +Samba got an unexpected signal while running. It is probably a +segmentation fault and almost certainly means a bug in Samba (unless +you have faulty hardware or system software)</P +><P +>If the message came from smbd then it will probably be accompanied by +a message which details the last SMB message received by smbd. This +info is often very useful in tracking down the problem so please +include it in your bug report.</P +><P +>You should also detail how to reproduce the problem, if +possible. Please make this reasonably detailed.</P +><P +>You may also find that a core file appeared in a "corefiles" +subdirectory of the directory where you keep your samba log +files. This file is the most useful tool for tracking down the bug. To +use it you do this:</P +><P +><B +CLASS="COMMAND" +>gdb smbd core</B +></P +><P +>adding appropriate paths to smbd and core so gdb can find them. If you +don't have gdb then try "dbx". Then within the debugger use the +command "where" to give a stack trace of where the problem +occurred. Include this in your mail.</P +><P +>If you known any assembly language then do a "disass" of the routine +where the problem occurred (if its in a library routine then +disassemble the routine that called it) and try to work out exactly +where the problem is by looking at the surrounding code. Even if you +don't know assembly then incuding this info in the bug report can be +useful. </P +></DIV +><DIV +CLASS="SECT1" +><HR><H1 +CLASS="SECT1" +><A +NAME="AEN43" +>Attaching to a running process</A +></H1 +><P +>Unfortunately some unixes (in particular some recent linux kernels) +refuse to dump a core file if the task has changed uid (which smbd +does often). To debug with this sort of system you could try to attach +to the running process using "gdb smbd PID" where you get PID from +smbstatus. Then use "c" to continue and try to cause the core dump +using the client. The debugger should catch the fault and tell you +where it occurred.</P +></DIV +><DIV +CLASS="SECT1" +><HR><H1 +CLASS="SECT1" +><A +NAME="AEN46" +>Patches</A +></H1 +><P +>The best sort of bug report is one that includes a fix! If you send us +patches please use <B +CLASS="COMMAND" +>diff -u</B +> format if your version of +diff supports it, otherwise use <B +CLASS="COMMAND" +>diff -c4</B +>. Make sure +your do the diff against a clean version of the source and let me know +exactly what version you used. </P +></DIV +></DIV +></BODY +></HTML +>
\ No newline at end of file |