summaryrefslogtreecommitdiff
path: root/tests/test-logging.c
AgeCommit message (Collapse)AuthorFilesLines
2016-08-19test-logging: don't hard-code paths in /tmpSascha Silbe1-7/+41
Since f6880b7f [qemu-log: support simple pid substitution for logs], test-logging creates files with hard-coded names in /tmp. In the best case, this prevents multiple developers from running "make check" on the same machine. In the worst case, it allows for symlink attacks, enabling an attacker to overwrite files that are writable to the developer running "make check". Instead of hard-coding the paths, create a temporary directory using g_dir_make_tmp() and clean it up afterwards. Fixes: f6880b7f ("qemu-log: support simple pid substitution for logs") Signed-off-by: Sascha Silbe <silbe@linux.vnet.ibm.com> Message-id: 1471545963-11720-3-git-send-email-silbe@linux.vnet.ibm.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2016-07-04log: Permit -dfilter 0..0xffffffffffffffffMarkus Armbruster1-2/+3
Works fine since the previous commit fixed the underlying range data type. Of course it filters out nothing, but so does 0..1,2..0xffffffffffffffff, and we don't bother rejecting that either. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-07-04log: Clean up misuse of Range for -dfilterMarkus Armbruster1-0/+10
Range encodes an integer interval [a,b] as { begin = a, end = b + 1 }, where a \in [0,2^64-1] and b \in [1,2^64]. Thus, zero end is to be interpreted as 2^64. The implementation of -dfilter (commit 3514552) uses Range differently: it encodes [a,b] as { begin = a, end = b }. The code works, but it contradicts the specification of Range in range.h. Switch to the specified representation. Since it can't represent [0,UINT64_MAX], we have to reject that now. Add a test for it. While we're rejecting anyway: observe that we reject -dfilter LOB..UPB where LOB > UPB when UPB is zero, but happily create an empty Range when it isn't. Reject it then, too, and add a test for it. While there, add a positive test for the problematic upper bound UINT64_MAX. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-06-20log: Fix qemu_set_log_filename() error handlingMarkus Armbruster1-33/+8
When qemu_set_log_filename() detects an invalid file name, it reports an error, closes the log file (if any), and starts logging to stderr (unless daemonized or nothing is being logged). This is wrong. Asking for an invalid log file on the command line should be fatal. Asking for one in the monitor should fail without messing up an existing logfile. Fix by converting qemu_set_log_filename() to Error. Pass it &error_fatal, except for hmp_logfile report errors. This also permits testing without a subprocess, so do that. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <1466011636-6112-4-git-send-email-armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2016-06-20log: Fix qemu_set_dfilter_ranges() error reportingMarkus Armbruster1-33/+16
g_error() is not an acceptable way to report errors to the user: $ qemu-system-x86_64 -dfilter 1000+0 ** (process:17187): ERROR **: Failed to parse range in: 1000+0 Trace/breakpoint trap (core dumped) g_assert() isn't, either: $ qemu-system-x86_64 -dfilter 1000x+64 ** ERROR:/work/armbru/qemu/util/log.c:180:qemu_set_dfilter_ranges: assertion failed: (e == range_op) Aborted (core dumped) Convert qemu_set_dfilter_ranges() to Error. Rework its deeply nested control flow. Touch up the error messages. Call it with &error_fatal. This also permits testing without a subprocess, so do that. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <1466011636-6112-3-git-send-email-armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2016-06-07tests: Remove unnecessary glib.h includesPeter Maydell1-1/+0
Remove glib.h includes, as it is provided by osdep.h. This commit was created with scripts/clean-includes. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Eric Blake <eblake@redhat.com> Tested-by: Eric Blake <eblake@redhat.com> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2016-03-22qemu-log: support simple pid substitution for logsAlex Bennée1-1/+35
When debugging stuff that occurs over several forks it would be useful not to keep overwriting the one logfile you've set-up. This allows a simple %d to be included once in the logfile parameter which is substituted with getpid(). As the test cases involve checking user output they need g_test_trap_subprocess() support. As a result they are currently skipped on Travis builds due to the older glib involved. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Leandro Dorileo <l@dorileo.org> Reviewed-by: Aurelien Jarno <aurelien@aurel32.net> Reviewed-by: Richard Henderson <rth@twiddle.net> Message-Id: <1458052224-9316-10-git-send-email-alex.bennee@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-03-22qemu-log: new option -dfilter to limit outputAlex Bennée1-0/+107
When debugging big programs or system emulation sometimes you want both the verbosity of cpu,exec et all but don't want to generate lots of logs for unneeded stuff. This patch adds a new option -dfilter which allows you to specify interesting address ranges in the form: -dfilter 0x8000..0x8fff,0xffffffc000080000+0x200,... Then logging code can use the new qemu_log_in_addr_range() function to decide if it will output logging information for the given range. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <1458052224-9316-7-git-send-email-alex.bennee@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>