* tlist: Add heap based implementation of timer list
Previous timer was sorted list implementation of priority queue
and very slow when number of timers increased. This is mostly
not a problem because usually only few timers are used.
But for application where bigger number of timers are needed
it may become problem.
Solution is to use binary heap based priority queue which is much
faster.
API is unchanged, just timerlist_destroy is added which should be called
to free heap array. This function also destroys mutex (omitted when
mutex was added).
* tests: Fix check loop mt test
test_th was accesed both by main thread and loop_timer thread resulting in
failure. Fix is to access test_tht in loop_timer thread.
Speed test is adding only 10000 items so it is reasonable
fast even with sorted linked list implementation.
Signed-off-by: Jan Friesse <jfriesse@redhat.com>
Compared to the outer world, libqb brings rather unintuitive approach
to priorities within a native event loop (qbloop.h) -- it doesn't do
an exhaustive high-to-low priorities in a batched (clean-the-level)
manner, but rather linearly adds a possibility to pick the handling
task from the higher priority level as opposed to lower priority ones.
This has the advantage of limiting the chances of starvation and
deadlock opportunities in the incorrectly constructed SW, on the other
hand, it means that libqb is not fulfilling the architected intentions
regarding what deserves a priority truthfully, so these priorities are
worth just a hint rather than urgency-based separation.
And consequently, a discovery of these deadlocks etc. is deferred to
the (as Murphy's laws have it) least convenient moment, e.g., when
said native event loop is exchanged for other (this time priority
trully abiding, like GLib) implementation, while retaining the same
basic notion and high-level handling of priorities on libqb
side, in IPC server (service handling) context.
Hence, demonstration of such a degenerate blocking is not trivial,
and we must defer such other event loop implementation. After this
hassle, we are rewarded with a practical proof said "high-level
handling [...] in IPC server (service handling) context" contains
a bug (which we are going to subsequently fix) -- this is contrasted
with libqb's native loop implementation that works just fine even
prior that fix.
Signed-off-by: Jan Pokorný <jpokorny@redhat.com>
build test binaries at "make" or "make all" instead of "make check".
this is necessary if it´s not possible to run make check during make rpm.
Signed-off-by: Fabio M. Di Nitto <fdinitto@redhat.com>
* doc: qbarray.h: fix garbled Doxygen markup
* build: follow-up for and fine-tuning of a rushed 6d62b64 commit
(It made a service as-was, but being afforded more time, this would
have accompanied that commit right away, for better understanding,
brevity and uniformity.)
* build: prune superfluous Makefile declarations within tests directory
There was a significant redundancy wrt. build flags and EXTRA_DIST
assignment (the latter become redundant as of f6e4042 at latest)
spread all over the place (vivat copy&paste). Also, in one instance,
CPPFLAGS (used) was confused with CFLAGS (meant).
* maint: check abi: fix two issues with abi-compliance-checker/libstdc++
1. ABICC >= 2 needs to be passed -cxx-incompatible switch because C is
no longer a default for this tool (used to be vice versa),
plus current version will stop choking on C vs. C++ (our C code with
C++ compatibility wrapping being viewed from C++ perspective for the
purpose of dumping the declared symbols, which somewhat conflicts
with internal masking of the C++ keywords being used as valid C
identifiers [yet some instances must not be masked here, see
https://github.com/lvc/abi-compliance-checker/issues/64) only
if _also_ something like this is applied:
https://github.com/lvc/abi-compliance-checker/pull/70
2. since 20246f5, libqb.so no longer poses a symlink to the actual
version-qualified shared library, but rather a standalone linker
script, which confuses ABICC, so blacklist that file for the scanning
purposes explicitly, together with referring to the library through
it's basic version qualification (which alone, sadly, is not
sufficient as ABICC proceeds to scan whole containing directory
despite particular file is specified)
* maint: check abi: switch to abi-dumper for creating "ABI dumps"
Beside avoiding issues with abi-compliance-checker in the role of ABI
dumps producer (see the preceding commit), it also seems to generate
more accurate picture (maybe because it expressly requires compiling
with debugging information requested).
* Low: qblist.h: fix incompatibility with C++ & check it regularly
* tests: check_list.c: start zeroing in on the gaps in tests' coverage
* tests: print_ver: make preprocessor emit "note" rather than warning
IIRC, Chrissie asked about this around inclusion of the test at
hand, and it seemed there was no way but to emit a warning to get
something output at all. Now it turns wrong, and moreover, we
make the code not fixed on GCC specific pragmas, with a bit of
luck, "#pragma message" approach is adopted more widely by compilers.
Signed-off-by: Jan Pokorný <jpokorny@redhat.com>
* Replace ck_assert_uint_eq() with ck_assert_int_eq()
it's not available in check 0.9
* Proper check for C++ compiler (from Fabio)
* add (c) to copyright dates
* tests: Improve test isolation
Make all the IPC tests run with a common date/pid stamp name, so that
the final resource.test only fails if it finds one of OUR files left
lying around and not those from another test.
Falls back to old IPC naming style if we can't create the file.
Signed-off-by: Christine Caulfield <ccaulfie@redhat.com>
Reviewed-by: Jan Friesse <jfriesse@redhat.com>
These are for quick manual sanity checking, assuming the target audience
-- maintainers -- are clear on the context of use and the purpose
(perhaps with the help of static files for comparison and/or additional
checking harness, usually available through "make check", but not to be
confused with regular unit + broader tests). These test are meant to be
compiled on demand only, not during the standard building routine, for
which a trick leveraging GNUmakefile-Makefile precedence with GNU make
was devised (GNU make/gmake already required by configure script for
other reasons [some pattern-based matching not available with FreeBSD's
default "make", IIRC], so this introduces no new build dependency).
The respective new tests are meant to simulate logging variants in two
different library consumption models:
a. regular: linking against system-wide library
b. developmental: consuming library from a local sub-checkout tree,
using libtool conventions and hence attaching the
library through libqb.la intermediate library
descriptor of libtool
and between up to three possibly affected logging system participants
(discrete compilation units):
1. libqb itself will emit log messages in boundary conditions or
for tracing purposes
2. client program that consumes libqb's logging API directly
3. ditto, but the client program furthermore links with a library
(referred to as "interlib") that itself exercises the logging
API (it's also linked with libqb) -- through induction, this
should cover whole class of N interlib cases
Especially the latter perspective makes for a test matrix to possibly
(hopefully) demonstrate a fix allowing to cope with the changed
behaviour of ld from binutils 2.29+ wrt. boundaries denoting symbols for
a (custom) orphan section that are no longer externally visible. Such
commit is in the pipeline...
Developmental consumption model (a.) is now also tested automatically
in Travis CI runs and as a part of %check within upstream-suggested
libqb.spec for RPM packaging, whereas the regular one (b.) serves as
a building block for new log_test_mock.sh runner of said test matrix
-- it iterates through all the possible permutations of linker-imposed
implicit visibility of mentioned symbols between various affected
link participants all making use of logging (see 1. - 3. above) so as
to demonstrate A/ the impact of the problem (see table below), and
subsequently B/ that the fix is effective in all these situations
(updated table will be provided as well) once it lands. This script
also allows convoluting the test matrix further, notably with on-demand
defusing the self-checks based on QB_LOG_INIT_DATA macro, which is
of significance as demonstrated below (and will become even more
important with upcoming patches in this series).
* * *
Current state for such matrix, in which participants 1. - 3. map like:
1. ~ libqb(Y)
2. ~ "direct"
3. ~ libX(Y) [a.k.a. interlib]
and where "X(Y)" denotes "X linked with linker Y":
X(a) .. ld.bfd < 2.29
X(b) .. ld.bfd = 2.29 (and only 2.29),
goes like this:
+=========+=========+=========+=========+=========+=========+=========+
#client(x)# libqb(a) usage # libqb(b) usage #
# vvv #---------+---------+---------+---------+---------+---------+
# V # direct | libX(a) : libX(b) # direct | libX(a) : libX(b) #
+=========+=========+=========+=========+=========+=========+=========+
# x = a # OK | OK : BAD[*2] # BAD[*1] | BAD[*D] : BAD[*3] #
# x = b # BAD[*A] | BAD[*B] : BAD[*C] # BAD[*1] | BAD[*C] : BAD[*3] #
+=========+=========+=========+=========+=========+=========+=========+
whereas if we swap 2.29 for 2.29.1, i.e., X(b) .. ld.bfd = 2.29.1, we
can observe a somewhat simpler story (DEP ~ "depends"):
+=========+=========+=========+=========+=========+=========+=========+
#client(x)# libqb(a) usage # libqb(b) usage #
# vvv #---------+---------+---------+---------+---------+---------+
# V # direct | libX(a) : libX(b) # direct | libX(a) : libX(b) #
+=========+=========+=========+=========+=========+=========+=========+
# x = a # OK | OK : DEP[*J] # BAD[*1] | BAD[*1] : BAD[*L] #
# x = b # DEP[*I] | DEP[*I] : DEP[*K] # BAD[*1] | BAD[*1] : BAD[*L] #
+=========+=========+=========+=========+=========+=========+=========+
* * *
[*1] client logging not working
[*2] interlib logging not working
[*3] both client and interlib logging not working
[*A] boils down to [*1], unless QB_LOG_INIT_DATA used on client side,
which fails on 'implicit callsite section is populated' assertion
[*B] boils down to [*1], unless QB_LOG_INIT_DATA used on interlib side,
which fails on 'implicit callsite section is populated' assertion
[*C] boils down to [*3], unless QB_LOG_INIT_DATA used on interlib side,
which fails on 'implicit callsite section is populated' assertion
[*D] boils down to [*3], unless QB_LOG_INIT_DATA used on interlib side,
which makes it boil down just to [*1] (hypothesis: mere internal
self-reference to the section's boundary symbols makes them
overcome some kind of symbol garbage collection at the linkage
stage, so they are exposed even they wouldn't be otherwise as
demonstrated with the initial, plain case of [*3])
[*I] boils down to [*1], unless QB_LOG_INIT_DATA used on client side,
which makes it, likely through self-reference keepalive (see
below) work OK
[*J] boils down to [*2], unless QB_LOG_INIT_DATA used on interlib side,
which makes it, likely through self-reference keepalive (see
below) work OK
[*K] boils down to [*3], unless QB_LOG_INIT_DATA used on both client
and interlib side, which makes it, likely through self-reference
keepalive (see below) work OK (it's expected that this a mere
composite of situations [*I] and [*J] with consequences as stated)
[*L] boils down to [*3], unless QB_LOG_INIT_DATA used on interlib side
(sufficient?), which makes it, likely through self-reference
keepalive (see below) boil down just to [*1]
* * *
Note: as observed with [*D] case (libqb linked with ld.bfd < 2.29
whereas interlib and its client linked with ld.bfd = 2.29), the exact
availability of a working logging doesn't depend solely on the linkers
in question, but generally (further investigation out of scope) the
conclusion is that when 2.29 ld.bfd is involved somewhere in the chain
of logging-related discrete compilation units, also (self-)referencing
of the section's boundary denoting symbols is a deciding factor whether
particular logging source will be honored. This may be a result of
some internal linkage garbage collection mechanisms involved.
Anyway, it is supposed that the fix to broken-by-linkage logging can be
proclaimed complete once all combinations pass barring QB_LOG_INIT_DATA
usage (incurring the mentioned active referential use of the symbols),
along with a spin using it everywhere for good measure.
For another level of the analysis depth, one can further play with
combinations of -n{sc,cl,il} options (explained upon -h switch) to
log_test_mock.sh (taking an oracle, this is added mostly to justify
the upcoming self-check test change because linker-script-based
workaround for newer linkers will cause the section boundary symbols
to be present regardless if that section is utilized, leading to
a self-inflicted breakage due to these empty section symbols suddenly
winning in the symbol resolution mechanism).
Signed-off-by: Jan Pokorný <jpokorny@redhat.com>
The intention behind enabling the syslog tests on demand (642f74d) was
to tread cautiously as libtool used to alert that something controversial
is going on:
$ ./autogen.sh && ./configure --enable-syslog-tests && make check
> ...
> *** Warning: Linking the executable log.test against the loadable module
> *** _syslog_override.so is not portable!
> ...
owing to the fact that _syslog_override.so is being linked (through
libtool) with LDFLAGS=-module.
In fact, the issue did go away with a fix to the "make install" process
(ebcff54) for which _syslog_override.so* files were being picked
undesirably prior to the fix, which manifested itself also on
"make rpm" (hence the respective commit message):
> RPM build errors:
> Installed (but unpackaged) file(s) found:
> /usr/lib64/_syslog_override.so
> /usr/lib64/_syslog_override.so.0
> /usr/lib64/_syslog_override.so.0.0.0
The explanation for the secondary positive effect on the mentioned
libtool's warning going away is rather simple:
"lib" prefix switches the expectations about the result as a library
(also due to "libdir" destination) rather than as an executable object.
Change like that ensures the result is what libtool's manual calls
"dynamic module that can be opened by lt_dlopen" rather than "runtime
library that cannot" in the context of Mac OS X, which was likely the
cause of the portability warning.
(https://www.gnu.org/software/libtool/manual/libtool.html#FOOT10)
And because the tests themselves are run through the libtool wrapper
scripts capable of relinking and other magic
What libtool manual has to say on this topic:
> Note that libtool modules don’t need to have a "lib" prefix. However,
> Automake 1.4 or higher is required to build such modules.
referring to version released 15+ years back, which is assumed anyway.
(https://www.gnu.org/software/libtool/manual/libtool.html#Modules-for-libltdl)
* * *
That being said, there's now no longer a reason to have "syslog-tests"
enablement conditionalized (no longer supposed intrusive), hence enable
them unconditionally along the other libcheck-based tests
-- whenever libcheck is detected.
This changeset also drops any trace of --enable-syslog-tests switch
in various places using that (spec file, Travis CI configuration)
making for a complete vaporizatio of this choice.
This reduces overlinking of qb-blackbox. Being a seldom used executable,
the gains are mostly theoretical, but at least this silences warnings
from some QA tools.
Unfortunately, debug messages of GNU make are emitted to stdout, which
spoils the extracted output we rely on. So prevent it (as well as
any other extraneous option) by force.
(discovered during git -> automatic COPR builds integration)
There are not many ways to test alternate code paths having failure of
some function from standard library as a precondition.
For a starter, we need to test failing unlink{,at} functions in a
controlled manner to mimic client and server path of the IPC connection
having different privileges to validate the previous commit. But the
test suite cannot assume it has root privileges (so as to add artificial
user system-wide, which is a pretty stupid idea on its own), cannot
generally use stuff like chroot/namespacing (not to speak about
synergies of the former like docker). So what's left is to make our
own playground, or better yet, use existing playground but just to
modify the rules of the game a bit when it's desired -- a variation
of old good LD_PRELOAD trick.
Note that this concept was already used in syslog tests (see commit
642f74d) and is now further extended using dlsym(RTLD_NEXT, "symbol")
to resolve the standard library symbol being shadowed by our little
"module". This hence yields a customized wrapping we use to either
inject a call failure or to increase an invocation counter so as to
assure something has indeed been called. As the mechanisms used are
not supposed to be available everywhere, the build system is
conditionalized respectively.
Back to our test when unlink{,at} fails, with the help of the described
mechanism, it was actually easy to massage test_ipc_server_fail_shm
into test_ipcc_truncate_when_unlink_fails_shm desired addition, which
is also featured in this commit, together with a modification to
resources.test script so that it expects particular number of empty
file leftovers (see previous commit).
It's expected that the module for failure injections will keep growing
so as to enable better overall coverage of the code (on the platforms
where this provision is available).
Mainly as a light-weight alternative to full-blown autoconf/pkg-config
machineries, whereby one can:
* workaround functionality not present in libqb up to 1.0 (inclusive)
- note that this versioning schema is being introduced *after*
1.0.0 release so one cannot tell that version from any older,
but will be able to safely identify any later one (1.0.1+)
and act accordingly
- example:
#if !defined(QB_VER_MAJOR) || ((QB_VER_MAJOR == 1) && (QB_VER_MINOR < 1))
#warning "Feature X not supported"
int do_foo(int arg) { };
#else
int
do_foo(int arg)
{
/* use feature X of libqb */
}
#endif
* make its program report libqb API version it was built with by
emitting QB_VER_STR symbolic string (see tests/print_ver.c for example)
Also added is a print_ver test program to:
* emit how original unparsed version is parsed to particular components
defined in qbconfig.h (QB_VER_{MAJOR,MINOR,PATCH} symbolic integer
constants and QB_VER_REST symbolic string) when being compiled
* emit mentioned QB_VER_STR symbolic string joining the components
back to a single string, plus the components themselves
Resolves: https://github.com/ClusterLabs/libqb/issues/186
Although this is not as rigorously correct as the previous arrangement
(introduced with 80834ea), i.e., from the perspective of
$(abs_top_builddir)/tests/Makefile (generated from from
$(top_srcdir)/tests/Makefile.am), for which $(top_builddir)
is literally "..":
- qbconfig.h is generated from $(top_srcdir)/include/qb/qbconfig.h.in
into $(top_builddir)/include/qb directory, and consumed from here
- rest of these header files are consumed directly from
$(top_srcdir)/include/qb directory
this new simplified variant:
- avoids code duplication (DRY)
- works thanks to VPATH in $(abs_top_builddir)/tests/Makefile
pointing to $(top_srcdir)/tests, which means that unsatisfied
dependencies on "$(top_builddir)/include/qb/%.h" (resolved to
"../include/qb/%.h") will be subsequently sought as
"$(top_srcdir)/tests/../include/qb/%.h", which has the same effect
as previous explicit "$(top_srcdir)/include/qb/%.h" specification
(note that such automatic VPATH provision is supported by automake
"since beginning" so no backward incompatibility is expected)
This reduces repeated code significantly, and allows for easier
supervision of what's being grouped to the suites + possibly what
timeouts apply.
Note that some artificial test case identifiers (in check_array.c,
check_log.c, check_loop.c, check_rb.c, check_utils.c) got changed
so they now follow 1:1 the test (function) name that is being run
for the case at hand without the "test_" prefix (strict convention).
Exception to this are test_ipc_disp_* tests in check_ipc.c that got,
conversely, changed to test_ipc_dispatch_* to follow the test case
identifiers.
Original "qb_log_ctl" interface had to be extended for passing read-only
strings (new parameter), resulting in new "qb_log_ctl2" function, which
is what qb_log_ctl calls into with the new parameter set to NULL.
This ensures backward compatibility.
A new QB_LOG_CONF_IDENT configuration directive for the mentioned
interface is added with a goal to set new internal identifier
that is, notably, used for syslog sink. This allows for switching
the identification without a need to reinitialize logging subsystem,
akin to changing target logging facility.
Also a brand new concept of testing syslog sink in particular is
introduced (finally). During initial trial&error stage, it used
LD_PRELOAD hack but it seems that libtool is sophisticated enough
that no such extra intervention is needed and the desired symbol
resolution Just Works (tm). However, the technique is highly
non-portable (there is even a warning about that from libtool,
which is partially on purpose as the _syslog_override.so should
rather be explicit it is by no mean a regular library) and hence
the syslog tests have to be enabled with explicit
./configure --enable-syslog-tests
rather than possibly break on untested platforms (far too many).
The concept can be extended upon, but initially, just the new
feature is being tested.
Post-review: thanks Chrissie for a suggestion how to deal with
extract-arg-and-forget in a less intrusive way (no defines).
On my system I get:
qb store] Duration: 8.289 OPs/sec: 1206381.250
snprintf] Duration: 16.712 OPs/sec: 598368.000
Signed-off-by: Angus Salkeld <asalkeld@redhat.com>
LIB_RT is unnecessary around. AC_CHECK_LIBS will do the right thing
similar for the other libs that are all exported via LIBS
Signed-off-by: Fabio M. Di Nitto <fdinitto@redhat.com>
So this this test is timing sensitive and can easily fail on slow
build farm machines. So I have enabled it on the --enable-slow-tests
configure option and put this into ./check as the default.
Signed-off-by: Angus Salkeld <asalkeld@redhat.com>
This is just a re-work of Steve's sample patch.
You set the number of splits and whether they overwrite using
qb_util_stopwatch_split_ctl().
Signed-off-by: Angus Salkeld <asalkeld@redhat.com>
