Error: RESOURCE_LEAK:
/builddir/build/BUILD/libguestfs-1.16.5/daemon/debug.c:469: open_fn: Calling opening function "open".
/builddir/build/BUILD/libguestfs-1.16.5/daemon/debug.c:469: var_assign: Assigning: "fd" = handle returned from "open("/proc/sys/kernel/core_pattern", 1)".
/builddir/build/BUILD/libguestfs-1.16.5/daemon/debug.c:474: noescape: Variable "fd" is not closed or saved in function "write".
/builddir/build/BUILD/libguestfs-1.16.5/daemon/debug.c:476: leaked_handle: Handle variable "fd" going out of scope leaks the handle.
(cherry picked from commit 3b3d9ca4e1)
When given an invalid debug command, libguestfs responds with the
error message:
libguestfs: error: debug: use 'debug help' to list the supported commands
However this command does not work, as debug requires two
arguments. This change updates the message to prompt the user to use
'debug help 0'.
In the case where both ends cancel at the same time (eg. both ends
realize there are errors before or during the transfer), previously we
skipped sending back an error from the daemon, on the spurious basis
that the library would not need it (the library is cancelling because
of its own error).
However this is wrong: we should always send back an error message
from the daemon in order to preserve synchronization of the protocol.
A simple test case is:
$ guestfish -N fs -m /dev/sda1 upload nosuchfile /
libguestfs: error: open: nosuchfile: No such file or directory
libguestfs: error: unexpected procedure number (66/282)
(Notice two things: there are errors at both ends, and the
loss of synchronization).
After applying this commit, the loss of synchronization does not occur
and we just see the library error:
$ guestfish -N fs -m /dev/sda1 upload nosuchfile /
libguestfs: error: open: nosuchfile: No such file or directory
The choice of displaying the library or the daemon error is fairly
arbitrary in this case -- it would be valid to display either or even
to combine them into one error. Displaying the library error only
makes the code considerably simpler.
This commit also (re-)enables a test for this case.
The debug command is useful for internal testing, and so should
be enabled by default in all builds.
Note that it is still *not* part of the stable ABI.
This adds a new debug command, core_pattern, which writes a new pattern for
coredump files to the appliance kernel, and sets the daemon's hard and soft core
limits to infinity.
Allow arbitrary files to be uploaded into the appliance, but
only when --enable-debug-command is enabled. This lets you
run shell scripts, like this:
><fs> debug-upload -<<EOF /tmp/script.sh 0700
#!/bin/sh -
# ...
EOF
><fs> debug sh "/tmp/script.sh"
The RPC stubs already prefix the command name to error messages.
The daemon doesn't have to do this. As a (small) benefit this also
makes the daemon slightly smaller.
Code in the daemon such as:
if (argv[0] == NULL) {
reply_with_error ("passed an empty list");
return NULL;
}
now results in error messages like this:
><fs> command ""
libguestfs: error: command: passed an empty list
(whereas previously you would have seen ..command: command:..)
Nearly every file-related function in daemons/*.c is affected:
Remove this pair of statements from each affected do_* function:
- NEED_ROOT (return -1);
- ABS_PATH (dir, return -1);
and change the type of the corresponding parameter to "const char *".
* src/generator.ml: Emit NEED_ROOT just once, even when there are two or
more Pathname args.
* daemon/debug.c (MAYBE_UNUSED): Define.
(do_debug): Mark parameters as unused only when they really
are unused. Spotted by Richard Jones.
SCALAR(0xdd8370)
prefer sizeof *VAR sizeof TYPE (no semantic change)
