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(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/