summaryrefslogtreecommitdiff
path: root/docs/docbook/projdoc/Bugs.sgml
diff options
context:
space:
mode:
authorJelmer Vernooij <jelmer@samba.org>2003-04-05 14:08:20 +0000
committerJelmer Vernooij <jelmer@samba.org>2003-04-05 14:08:20 +0000
commitedb56d184679d276d011af857f7d1ab0c6817f0a (patch)
treeece338f9ee97d89fe68e0396ab632c7de3624686 /docs/docbook/projdoc/Bugs.sgml
parent2c1f725820584f279607db48e0003d6e7f67321e (diff)
downloadsamba-edb56d184679d276d011af857f7d1ab0c6817f0a.tar.gz
samba-edb56d184679d276d011af857f7d1ab0c6817f0a.tar.bz2
samba-edb56d184679d276d011af857f7d1ab0c6817f0a.zip
Fix typos / layout
(This used to be commit fb20589e7c043ab1306051e80ca3f7476b1c6c58)
Diffstat (limited to 'docs/docbook/projdoc/Bugs.sgml')
-rw-r--r--docs/docbook/projdoc/Bugs.sgml24
1 files changed, 12 insertions, 12 deletions
diff --git a/docs/docbook/projdoc/Bugs.sgml b/docs/docbook/projdoc/Bugs.sgml
index 4e4f7b9084..9c6be75c8d 100644
--- a/docs/docbook/projdoc/Bugs.sgml
+++ b/docs/docbook/projdoc/Bugs.sgml
@@ -100,8 +100,8 @@ include = /usr/local/samba/lib/smb.conf.%m
<para>
then create a file
-<filename>/usr/local/samba/lib/smb.conf.machine</filename> where
-"machine" is the name of the client you wish to debug. In that file
+<filename>/usr/local/samba/lib/smb.conf.<replaceable>machine</replaceable></filename> where
+<replaceable>machine</replaceable> is the name of the client you wish to debug. In that file
put any smb.conf commands you want, for example
<command>log level=</command> may be useful. This also allows you to
experiment with different security systems, protocol levels etc on just
@@ -112,7 +112,7 @@ one machine.
The <filename>smb.conf</filename> entry <command>log level =</command>
is synonymous with the entry <command>debuglevel =</command> that has been
used in older versions of Samba and is being retained for backwards
-compatibility of smb.conf files.
+compatibility of <filename>smb.conf</filename> files.
</para>
<para>
@@ -132,7 +132,7 @@ large volume of log data.
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)
+you have faulty hardware or system software).
</para>
<para>
@@ -148,7 +148,7 @@ possible. Please make this reasonably detailed.
</para>
<para>
-You may also find that a core file appeared in a "corefiles"
+You may also find that a core file appeared in a <filename>corefiles</filename>
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:
@@ -158,13 +158,13 @@ use it you do this:
<para>
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
+don't have gdb then try <userinput>dbx</userinput>. Then within the debugger use the
+command <userinput>where</userinput> to give a stack trace of where the problem
occurred. Include this in your mail.
</para>
<para>
-If you known any assembly language then do a "disass" of the routine
+If you known any assembly language then do a <userinput>disass</userinput> 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
@@ -180,8 +180,8 @@ 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 <userinput>gdb smbd <replaceable>PID</replaceable></userinput> where you get <replaceable>PID</replaceable> from
+<application>smbstatus</application>. Then use <userinput>c</userinput> to continue and try to cause the core dump
using the client. The debugger should catch the fault and tell you
where it occurred.
</para>
@@ -193,8 +193,8 @@ where it occurred.
<para>
The best sort of bug report is one that includes a fix! If you send us
-patches please use <command>diff -u</command> format if your version of
-diff supports it, otherwise use <command>diff -c4</command>. Make sure
+patches please use <userinput>diff -u</userinput> format if your version of
+diff supports it, otherwise use <userinput>diff -c4</userinput>. Make sure
your do the diff against a clean version of the source and let me know
exactly what version you used.
</para>