From 4a090ba06a54f5da179ac02bb307cc03d08831bf Mon Sep 17 00:00:00 2001 From: Gerald Carter Date: Wed, 16 Jul 2003 05:34:56 +0000 Subject: trying to get HEAD building again. If you want the code prior to this merge, checkout HEAD_PRE_3_0_0_BETA_3_MERGE (This used to be commit adb98e7b7cd0f025b52c570e4034eebf4047b1ad) --- docs/docbook/projdoc/Bugs.xml | 56 ++++++++++++++++++++++--------------------- 1 file changed, 29 insertions(+), 27 deletions(-) (limited to 'docs/docbook/projdoc/Bugs.xml') diff --git a/docs/docbook/projdoc/Bugs.xml b/docs/docbook/projdoc/Bugs.xml index d782920457..b2b8d5c67e 100644 --- a/docs/docbook/projdoc/Bugs.xml +++ b/docs/docbook/projdoc/Bugs.xml @@ -2,11 +2,7 @@ &author.jelmer; - - - Samba Team - - + Someone; Tridge or Karl Auer perhaps? 27 June 1997 @@ -15,7 +11,8 @@ Introduction -Please report bugs using bugzilla. +Please report bugs using + bugzilla. Please take the time to read this file before you submit a bug @@ -78,12 +75,12 @@ 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 givesmore +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 +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 use: @@ -100,24 +97,25 @@ 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 +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 debuglevel = that has been -used in older versions of Samba and is being retained for backwards +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 backwards compatibility of &smb.conf; files. -As the log level = value is increased you will record +As the log level 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. +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. @@ -126,8 +124,8 @@ large volume of log data. Internal errors -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 +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). @@ -151,21 +149,24 @@ files. This file is the most useful tool for tracking down the bug. To use it you do this: -gdb smbd core + + $ 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. +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 report. -If you know any assembly language then do a disass of the routine +If you know 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 +don't know assembly, including this info in the bug report can be useful. @@ -177,8 +178,10 @@ useful. 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 +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. @@ -198,4 +201,3 @@ exactly what version you used. - -- cgit