[libvirt] [PATCH] Augment bug reporting documentation
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@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
On Wed, Nov 10, 2010 at 11:01:15AM +0100, Daniel Veillard wrote:
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>
You don't need to specify the /usr/sbin/libvirtd binary name on the command line to GDB if you're about to use 'attach', because GDB will find it automatically from the PID, but ACK anyway Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
On Wed, Nov 10, 2010 at 11:34:23AM +0000, Daniel P. Berrange wrote:
On Wed, Nov 10, 2010 at 11:01:15AM +0100, Daniel Veillard wrote:
With some instruction on how to attach useful gdb backtraces [...] + <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>
You don't need to specify the /usr/sbin/libvirtd binary name on the command line to GDB if you're about to use 'attach', because GDB will find it automatically from the PID, but ACK anyway
okay, just that I always do it that way, and since that's the only example of gdb usage on that page, being a bit more complete should not hurt :-) pushed ! Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
On 11/10/2010 05:18 AM, Daniel Veillard wrote:
On Wed, Nov 10, 2010 at 11:34:23AM +0000, Daniel P. Berrange wrote:
On Wed, Nov 10, 2010 at 11:01:15AM +0100, Daniel Veillard wrote:
With some instruction on how to attach useful gdb backtraces [...] + <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>
You don't need to specify the /usr/sbin/libvirtd binary name on the command line to GDB if you're about to use 'attach', because GDB will find it automatically from the PID, but ACK anyway
okay, just that I always do it that way, and since that's the only example of gdb usage on that page, being a bit more complete should not hurt :-)
Personally, I use gdb /proc/nnn/exe nnn when I know the process I want to debug, but not its location. Then I don't have to do an apply step inside gdb. But what you pushed is fine :) -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
participants (3)
-
Daniel P. Berrange -
Daniel Veillard -
Eric Blake