+++ This bug was initially created as a clone of Bug #676788 +++ Description of problem: Run "guestfish --remote" commands "set-trace 1" and "list-filesystems" before "run" or "add" command will lead to error "guestfish: remote: looks like the server is not running". Version-Release number of selected component (if applicable): libguestfs-1.7.17-12.el6 How reproducible: 100% Steps to Reproduce: 1. # eval `guestfish --listen` 2. # guestfish --remote -- -add /data/images/RHEL-Server-5.5-32-hvm.raw 3. # guestfish --remote -- -set-trace 1 4. # guestfish --remote -- -list-filesystems libguestfs: trace: list_filesystems libguestfs: trace: list_devices libguestfs: error: list_devices: call launch before using this function (in guestfish, don't forget to use the 'run' command) libguestfs: trace: list_devices = NULL (error) libguestfs: trace: list_filesystems = ["guestfish: protocol error: could not decode reply from server 5. # guestfish --remote -- -run guestfish: remote: looks like the server is not running Actual results: guestfish remote server down after reporting error, "guestfish --listen" process lost. In guestfish interactive shell there's no similar problem, shell still work after reporting error. Expected results: guestfish remote server should still be alive after reporting error. Additional info: 1. if no "set-trace" command executed before "list-filesystems", guestfish server doesn't down. 2. if execute "run" command before "list-filesystems", guestfish server doesn't down. --- Additional comment from pm-rhel on 2011-02-11 04:12:35 EST --- Since this issue was entered in bugzilla, the release flag has been set to ? to ensure that it is properly evaluated for this release.
Stack trace: #0 guestfs_list_filesystems (g=<value optimized out>) at actions.c:2038 2038 for (i = 0; r[i]; ++i) { (gdb) bt #0 guestfs_list_filesystems (g=<value optimized out>) at actions.c:2038 #1 0x000000000041c765 in run_list_filesystems ( cmd=0x2059b20 "list-filesystems", argc=<value optimized out>, argv=<value optimized out>) at cmds.c:4048 #2 0x0000000000424d68 in issue_command (cmd=0x2059b20 "list-filesystems", argv=0x2059ae0, pipecmd=0x0, rc_exit_on_error_flag=0) at fish.c:1019 #3 0x0000000000428cbf in rc_listen () at rc.c:287 #4 0x000000000040b2c7 in main (argc=2, argv=0x7fff282ddf08) at fish.c:483 Note that r == NULL in frame #0.
This is nothing to do with remote, and all to do with the trace patch. Simple reproducer: $ guestfish -a /dev/null -x list-filesystems libguestfs: trace: add_drive_opts "/dev/null" libguestfs: trace: add_drive_opts = 0 libguestfs: trace: list_filesystems libguestfs: trace: list_devices libguestfs: error: list_devices: call launch before using this function (in guestfish, don't forget to use the 'run' command) libguestfs: trace: list_devices = NULL (error) libguestfs: trace: list_filesystems = ["Segmentation fault (core dumped)
Created attachment 482719 [details] Fix trace segfault for non-daemon functions (UNTESTED) I'm hitting a problem in gcc 4.6.0 trying to get libguestfs to compile. The attachment is therefore an UNTESTED patch to fix this problem.
That patch is a bit broken. A second version was posted upstream here: https://www.redhat.com/archives/libguestfs/2011-March/msg00026.html
Pushed upstream in commit 7c721e4fd674c409b3eee60fe237d480afa1c5e2.
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: The guestfish set-trace command was not prepared to handle all possible error conditions. This resulted in a segmentation fault when attempting to handle several conditions. The command now handles trace errors separately, so the segmentation fault no longer occurs. Note that this bug was reported and corrected during development. It was not seen in production systems in the field.
Deleted Technical Notes Contents. Old Contents: The guestfish set-trace command was not prepared to handle all possible error conditions. This resulted in a segmentation fault when attempting to handle several conditions. The command now handles trace errors separately, so the segmentation fault no longer occurs. Note that this bug was reported and corrected during development. It was not seen in production systems in the field.