Augment bug reporting documentation

With some instruction on how to attach useful gdb backtraces
This commit is contained in:
Daniel Veillard 2010-11-10 13:16:37 +01:00
parent 9c7c4a4fc5
commit dc844b9078

View File

@ -77,6 +77,35 @@
<li>For QEMU/KVM, the domain logfile from /var/log/libvirt/qemu</li> <li>For QEMU/KVM, the domain logfile from /var/log/libvirt/qemu</li>
</ul> </ul>
<p>
If the bug leads to a tool linked to libvirt crash, then the best
is to provide a backtrace along with the scenario used to get the
crash, the simplest is to run the program under gdb, reproduce the
steps leading to the crash and then issue a gdb "bt" command to
get the stack trace, attach it to the bug. Note that for the
data to be really useful libvirt debug informations must be present
for example by installing libvirt debuginfo package on Fedora or
Red Hat Enterprise Linux (with debuginfo-install libvirt) prior
to running gdb.</p>
<p>
It may also happen that the libvirt daemon itself crashes or get stuck,
in the first case run it (as root) under gdb, and reproduce the sequence
leading to the crash, similary to a normal program provide the
"bt" backtrace information to where gdb will have stopped.<br/>
But if libvirtd get stuck, for example seems to stop processing
commands, try to attach to the faulty daemon and issue a gdb command
"thread apply all bt" to show all the threads backtraces, as in:</p>
<pre> # ps -o etime,pid `pgrep libvirt`
... note the process id from the output
# gdb /usr/sbin/libvirtd
.... some informations about gdb and loading debug data
(gdb) attach $the_damon_process_id
....
(gdb) thread apply all bt
.... informations to attach to the bug
(gdb)
</pre>
<p> <p>
If requesting a new feature attach any available patch to the ticket If requesting a new feature attach any available patch to the ticket
and also email the patch to the libvirt mailing list for discussion and also email the patch to the libvirt mailing list for discussion