81
If the bug leads to a tool linked to libvirt crash, then the best
82
is to provide a backtrace along with the scenario used to get the
83
crash, the simplest is to run the program under gdb, reproduce the
84
steps leading to the crash and then issue a gdb "bt" command to
85
get the stack trace, attach it to the bug. Note that for the
86
data to be really useful libvirt debug informations must be present
87
for example by installing libvirt debuginfo package on Fedora or
88
Red Hat Enterprise Linux (with debuginfo-install libvirt) prior
91
It may also happen that the libvirt daemon itself crashes or get stuck,
92
in the first case run it (as root) under gdb, and reproduce the sequence
93
leading to the crash, similary to a normal program provide the
94
"bt" backtrace information to where gdb will have stopped.<br/>
95
But if libvirtd get stuck, for example seems to stop processing
96
commands, try to attach to the faulty daemon and issue a gdb command
97
"thread apply all bt" to show all the threads backtraces, as in:</p>
98
<pre> # ps -o etime,pid `pgrep libvirt`
99
... note the process id from the output
100
# gdb /usr/sbin/libvirtd
101
.... some informations about gdb and loading debug data
102
(gdb) attach $the_damon_process_id
104
(gdb) thread apply all bt
105
.... informations to attach to the bug
81
110
If requesting a new feature attach any available patch to the ticket
82
111
and also email the patch to the libvirt mailing list for discussion