aboutsummaryrefslogtreecommitdiff
path: root/libctf/testsuite/libctf-regression/open-error-free.c
AgeCommit message (Collapse)AuthorFilesLines
2024-06-19libctf: fix testsuite bugs revealed by -WallNick Alcock1-1/+1
Most of these are harmless, but some of the type confusions and especially a missing ctf_strerror() on an error path were actual bugs that could have resulted in test failures crashing rather than printing an error message. libctf/ * testsuite/libctf-lookup/enumerator-iteration.c: Fix type confusion, signedness confusion and a missing ctf_errmsg(). * testsuite/libctf-regression/libctf-repeat-cu-main.c: Return 0 from the test function. * testsuite/libctf-regression/open-error-free.c: Fix signedness confusion. * testsuite/libctf-regression/zrewrite.c: Remove unused label.
2024-06-18libctf: suppress spurious failure of malloc-counting tests under valgrindNick Alcock1-0/+13
The libctf-regression/open-error-free.c test works by interposing malloc and counting mallocs and frees across libctf operations. This only works under suitably-interposable mallocs on systems supporting dlsym (RTLD_NEXT, ...), so its operation is restricted to glibc systems for now, but also it interacts badly with valgrind, which interposes malloc itself. Detect a running valgrind and skip the test. Add new facilities allowing libctf lookup tests to declare themselves unsupported, by printing "UNSUPPORTED: " and then some meaningful message instead of their normal output. libctf/ * configure.ac: Check for <valgrind/valgrind.h>. * config.h.in: Regenerate. * configure: Likewise. * testsuite/lib/ctf-lib.exp (run_lookup_test): Add support for UNSUPPORTED tests. * testsuite/libctf-regression/open-error-free.c: When running under valgrind, this test is unsupported.
2024-05-23libctf testsuite compilation failureAlan Modra1-1/+1
* testsuite/libctf-regression/open-error-free.c (main): Correct format length modifier.
2024-05-17libctf: fix leak of entire dict when dict opening failsNick Alcock1-0/+185
Ever since commit 1fa7a0c24e78e7f ("libctf: sort out potential refcount loops") ctf_dict_close has only freed anything if the refcount on entry to the function is precisely 1. >1 obviously just decrements the refcount, but the linker machinery can sometimes cause freeing to recurse from a dict to another dict and then back to the first dict again, so we interpret a refcount of 0 as an indication that this is a recursive call and we should just return, because a caller is already freeing this dict. Unfortunately there is one situation in which this is not true: the bad: codepath in ctf_bufopen entered when opening fails. Because the refcount is bumped only at the very end of ctf_bufopen, any failure causes ctf_dict_close to be entered with a refcount of zero, and it frees nothing and we leak the entire dict. The solution is to bump the refcount to 1 right before freeing... but this codepath is clearly delicate enough that we need to properly validate it, so we add a test that uses malloc interposition to count allocations and frees, creates a dict, writes it out, intentionally corrupts it (by setting a bunch of bytes after the header to a value high enough that it is definitely not a valid CTF type kind), then tries to open it again and counts the malloc/free pairs to make sure they're matched. (Test run only on *-linux-gnu, because malloc interposition is not a thing you can rely upon working everywhere, and this test is not arch-dependent so if it passes on one arch it can be assumed to pass on all of them.) libctf/ * ctf-open.c (ctf_bufopen): Bump the refcount on failure. * testsuite/libctf-regression/open-error-free.*: New test.