With some instruction on how to attach useful gdb backtraces
Daniel
diff --git a/docs/bugs.html.in b/docs/bugs.html.in
index 201705b..560dfa4 100644
--- a/docs/bugs.html.in
+++ b/docs/bugs.html.in
@@ -78,6 +78,35 @@
</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>
If requesting a new feature attach any available patch to the ticket
and also email the patch to the libvirt mailing list for discussion
</p>
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list