The log filters have supported the use of a "+" before the source match
string to request that a stack trace be emitted for every log message:
commit 548563956e
Author: Daniel P. Berrange <berrange@redhat.com>
Date: Wed May 9 15:18:56 2012 +0100
Allow stack traces to be included with log messages
Sometimes it is useful to see the callpath for log messages.
This change enhances the log filter syntax so that stack traces
can be show by setting '1:+NAME' instead of '1:NAME'.
With the huge & ever increasing number of logging statements per file,
this will be incredibly verbose and have a major performance penalty.
This makes the feature impractical to use widely and as such it is not
worth the code maint cost.
Removing this seldom used feature allows us to drop the 'execinfo'
module in gnulib which provides the backtrace() function which doesn't
exist on non-Linux.
Users who want to get stack traces of parts of libvirt can use GDB,
or systemtap for live tracing with minimal perf impact.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Use G_GNUC_UNUSED from GLib instead of ATTRIBUTE_UNUSED.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
g_strerror is offers the safety/correctness benefits of strerror_r, with
the API design convenience of strerror.
Use of virStrerror should be eliminated through the codebase in favour
of g_strerror.
commandhelper.c is a special case as its a tiny single threaded test
program, not linked to glib, so it just uses traditional strerror().
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Introduced by ff376c6283.
Previously, init_syms() was called from stat() mock and its
friends. This is crucial because checkPath() might call
printFile() which in turn calls real_fopen(). But if stat() or
one of its friends is the first function called then because of
lacking init_syms() call no real_* is initialized.
The other thing is that we really want the recorded action to be
"stat" instead of __FUNCTION__ because there's no good in
recording that it was __xstat64 who touched some file.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Quite a few of the tests have a need to mock the stat() / lstat()
functions and they are taking somewhat different & inconsistent
approaches none of which are actually fully correct. This is shown
by fact that 'make check' fails on 32-bit hosts. Investigation
revealed that the code was calling into the native C library impl,
not getting intercepted by our mocks.
The POSIX stat() function might resolve to any number of different
symbols in the C library.
The may be an additional stat64() function exposed by the headers
too.
On 64-bit hosts the stat & stat64 functions are identical, always
refering to the 64-bit ABI.
On 32-bit hosts they refer to the 32-bit & 64-bit ABIs respectively.
Libvirt uses _FILE_OFFSET_BITS=64 on 32-bit hosts, which causes the
C library to transparently rewrite stat() calls to be stat64() calls.
Libvirt will never see the 32-bit ABI from the traditional stat()
call. We cannot assume this rewriting is done using a macro. It might
be, but on GLibC it is done with a magic __asm__ statement to apply
the rewrite at link time instead of at preprocessing.
In GLibC there may be two additional functions exposed by the headers,
__xstat() and __xstat64(). When these exist, stat() and stat64() are
transparently rewritten to call __xstat() and __xstat64() respectively.
The former symbols will not actally exist in the library at all, only
the header. The leading "__" indicates the symbols are a private impl
detail of the C library that applications should not care about.
Unfortunately, because we are trying to mock replace the C library,
we need to know about this internal impl detail.
With all this in mind the list of functions we have to mock will depend
on several factors
- If _FILE_OFFSET_BITS is set, then we are on a 32-bit host, and we
only need to mock stat64 and __xstat64. The other stat / __xstat
functions exist, but we'll never call them so they can be ignored
for mocking.
- If _FILE_OFFSET_BITS is not set, then we are on a 64-bit host and
we should mock stat, stat64, __xstat & __xstat64. Either may be
called by app code.
- If __xstat & __xstat64 exist, then stat & stat64 will not exist
as symbols in the library, so the latter should not be mocked.
The same all applies to lstat()
These rules are complex enough that we don't want to duplicate them
across every mock file, so this centralizes all the logic in a helper
file virmockstathelper.c that should be #included when needed. The
code merely need to provide a filename rewriting callback called
virMockStatRedirect(). Optionally VIR_MOCK_STAT_HOOK can be defined
as a macro if further processing is needed inline.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
According to the official documentation for autoconf[1], the
correct names for these variables are abs_top_{src,build}dir
rather than abs_top{src,build}dir; in fact, we're already
using the correct names in various places, so let's just make
everything nice and consistent.
[1] https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Preset-Output-Variables.html
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
In many files there are header comments that contain an Author:
statement, supposedly reflecting who originally wrote the code.
In a large collaborative project like libvirt, any non-trivial
file will have been modified by a large number of different
contributors. IOW, the Author: comments are quickly out of date,
omitting people who have made significant contribitions.
In some places Author: lines have been added despite the person
merely being responsible for creating the file by moving existing
code out of another file. IOW, the Author: lines give an incorrect
record of authorship.
With this all in mind, the comments are useless as a means to identify
who to talk to about code in a particular file. Contributors will always
be better off using 'git log' and 'git blame' if they need to find the
author of a particular bit of code.
This commit thus deletes all Author: comments from the source and adds
a rule to prevent them reappearing.
The Copyright headers are similarly misleading and inaccurate, however,
we cannot delete these as they have legal meaning, despite being largely
inaccurate. In addition only the copyright holder is permitted to change
their respective copyright statement.
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
As advertised in the previous commit, we need the list of
accessed files to also contain action that caused the $path to
appear on the list. Not only this enables us to fine tune our
white list rules it also helps us to see why $path is reported.
For instance:
/run/user/1000/libvirt/libvirt-sock: connect: qemuxml2argvtest: QEMU XML-2-ARGV net-vhostuser-multiq
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
The aim of this mock is to track if a test doesn't touch anything
in live system. Well, connect() which definitely falls into that
category isn't tracked yet.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Clang complains about it:
error: second argument to 'va_arg' is of promotable type
'mode_t' (aka 'unsigned short'); this va_arg has undefined
behavior because arguments will be promoted to 'int'
[-Werror,-Wvarargs]
mode = va_arg(ap, mode_t);
^~~~~~
Work around the issue by passing int to va_arg() and casting
its return value to mode_t afterwards.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The latter is impossible to mock on platforms that use the
gnulib implementation, such as FreeBSD, while the former
doesn't suffer from this limitation.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
There is a lot to explain, but I try to make it as short as
possible. I'd start by pasting some parts of sys/stat.h:
extern int stat (const char *__restrict __file,
struct stat *__restrict __buf) __THROW __nonnull ((1, 2));
extern int __REDIRECT_NTH (stat, (const char *__restrict __file,
struct stat *__restrict __buf), stat64)
__nonnull ((1, 2));
__extern_inline int
__NTH (stat (const char *__path, struct stat *__statbuf))
{
return __xstat (_STAT_VER, __path, __statbuf);
}
Only one of these is effective at once, due to some usage of
the mess we are dealing with in here. So, basically, while
compiling or linking stat() in our code can be transformed into
some other func. Or a dragon.
Now, if you read stat(2) manpage, esp. "C library/kernel
differences" section, you'll learn that glibc uses some tricks
for older applications to work. I haven't gotten around actual
code that does this, but based on my observations, if 'stat'
symbol is found, glibc assumes it's dealing with ancient
application. Unfortunately, it can be just ours stat coming from
our mock. Therefore, calling stat() from a test will end up in
our mock. But since glibc is not exposing the symbol anymore, our
call of real_stat() will SIGSEGV immediately as the pointer to
function is NULL. Therefore, we should expose only those symbols
we know glibc has.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
It wasn't as great idea as I thought. Thing around stat() are
more complicated than that. Therefore we need to revert
86d1705a8a plus drop use of the macro as introduced in
later patches.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
All the accesses to files outside our build or source directories
are now identified and appended into a file for later processing.
The location of the file that contains all the records can be
controlled via VIR_TEST_FILE_ACCESS env variable and defaults to
abs_builddir "/test_file_access.txt".
The script that will process the access file is to be added in
next commit.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
The intent is that this library is going to be called every time
to check if we are not touching anything outside srcdir or
builddir.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>