BUGS.txt needs an upgrade
slitt at troubleshooters.com
Sat Dec 11 01:37:14 GMT 1999
Should there be a section in your SUGGESTED REPORT FORMAT for the patch
itself? Should there also be a section telling what diff command was used,
and against what version/distribution? Do you think the SUGGESTED REPORT
FORMAT serves as sufficient documentation for the patch?
At 01:52 AM 12/10/1999 +1100, David Collier-Brown wrote:
> The message returned by the (now obsolete) samba-bugs at samba.org
>mailing address needs some work, and BUGS.txt is out of date. I'll
>suggest you add BUGS.txt to the reply, and consider the following
>as an update of the contents.
>David Collier-Brown, | Always do right. This will gratify some people
>185 Ellerslie Ave., | and astonish the rest. -- Mark Twain
>Willowdale, Ontario | //www.oreilly.com/catalog/samba/author.html
>Work: (905) 415-2849 Home: (416) 223-8968 Email: davecb at canada.sun.com
>!== BUGS.txt for Samba release 2.0.6 11 Nov 1999
>Contributor: Samba Team
>Updated: 9 December 1999
>Subject: This file describes how to report Samba bugs.
>>> Bugs are now reported via the samba at samba.org mailing list. <<
>Please take the time to read this file before you submit a bug report
>to the list. Also, please see if it has changed between releases, as
>we have changed the bug reporting mechanisms on occasion.
>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. The last section of this file shows a useful format
>for a bug report.
>If you suspect that your problem is not a bug but a configuration
>then it is best to send to to either the Samba mailing list or
>comp.protocols.smb, as there are (at last count) 5000 other users on
>the list that may be able to help you.
>You may also like to look though the recent mailing list archives,
>which are conveniently accessible on the Samba web pages
>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.
>Have you run through DIAGNOSIS.txt? This is very important.
>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.
>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 gives more
>detail, but may use too much disk space.
>To set the debug level use "log level =" in your smb.conf. 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:
>log level = 10
>log file = /usr/local/samba/lib/log.%m
>include = /usr/local/samba/lib/smb.conf.%m
>then create a file "/usr/local/samba/lib/smb.conf.machine" where
>"machine" is the name of the client you wish to debug. In that file
>put any smb.conf commands you want, for example "log level=" may be
>useful. This also allows you to experiment with different security
>systems, protocol levels etc on just one machine.
>The smb.conf entry "log level =" is synonymous with the entry
>"debug level =" that has been used in older versions of Samba and
>is being retained for backwards compatibility of smb.conf files.
>As the "log level =" value is increased you will record a
>increasing level of debugging information. For most debugging
>you may not need a setting higher than 3. Nearly all bugs can be
>at a setting of 10, but be prepared for a VERY large volume of log
>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)
>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.
>You should also detail how to reproduce the problem, if
>possible. Please make this reasonably detailed.
>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:
>gdb smbd core
>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.
>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 including this info in the bug report can be
>ATTACHING TO A RUNNING PROCESS
>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.
>The best sort of bug report is one that includes a fix! These can be
>submitted via the http://samba.org/samba-patches/ page. Make sure
>your do the diff against a clean version of the source and let me know
>exactly what version you used.
>SUGGESTED REPORT FORMAT
> Machine Arch: _________ OS: __________
> OS Version:________ Kernel:___
> Compiler: _____________
> Libc Version: ________
> Samba Version: ___________
> Network Layout:
> (where applicable):
> What else is on machine :
> (services, etc)
> (what you did and what happened)
> (samba logs, plus packet captures and truss/strace
> output where applicable.
> Annotate your logs with what you were doing on the client
> at the time, and exactly what the results were.
> Please avoid using attachments, or any form of encoding
> in your email. Just send plain ascii.)
More information about the samba-technical