Chapter 35. Reporting Bugs

Chapter 35. Reporting Bugs
Prev	Part V. Troubleshooting	Next

John H. Terpstra

Samba Team

<jht@samba.org>

Jelmer R. Vernooij

The Samba Team

<jelmer@samba.org>

Andrew Tridgell

Samba Team

<tridge@samba.org>

27 June 1997

Table of Contents

Introduction
General Information
Debug Levels
Internal Errors
Attaching to a Running Process
Patches

Introduction

Please report bugs using Samba's -Bugzilla facilities and -take the time to read this file before you submit a bug -report. Also, check to see if it has changed between releases, as we -may be changing the bug reporting mechanism at some point. -

-Please 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 than -we can possibly answer, so you have a much higher chance of a response -and a fix if you send us a “developer friendly” bug report that lets -us fix it fast. -

-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, it is better to send -it to the Samba mailing list, as there are thousands of other users on -that list who 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 -at http://samba.org/samba/. -

General Information

-Before submitting a bug report, check your config for silly -errors. Look in your log files for obvious messages that tell -you've misconfigured something. Run testparm to check your config -file for correct syntax. -

- Have you looked through ? This is extremely 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. -

Debug Levels

-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 quite 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 the 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, add the following lines to your main smb.conf file: -

log level = 10

log file = /usr/local/samba/lib/log.%m

include = /usr/local/samba/lib/smb.conf.%m

-and 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 and so on, on just -one machine. -

-The smb.conf entry log level -is synonymous with the parameter debuglevel that has -been used in older versions of Samba and is being retained for backward -compatibility of smb.conf files. -

-As the log level value is increased, you will record -a significantly greater 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 large volume of log data. -

Internal Errors

-If you get the message “INTERNAL ERROR” 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, it will probably be accompanied by -a message that details the last SMB message received by smbd. This -information is often 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 -do not have gdb, try dbx. Then within the debugger, -use the command where to give a stack trace of where the -problem occurred. Include this in your report. -

-If you know any assembly language, 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 -do not know assembly, including this information in the bug report can be -useful. -

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. -

Patches

- - -The best sort of bug report is one that includes a fix! If you send us -patches, please use diff -u format if your version of -diff supports it, otherwise use diff -c4. Make sure -you do the diff against a clean version of the source and let me know -exactly what version you used. -

Prev	Up	Next
Chapter 34. Analyzing and Solving Samba Problems	Home	Part VI. Appendixes