GitLab

saves a second dynamic allocation (and more importantly, one that couldn't be freed)

See 26483ea2

an attempt to clean up memory; ForwardQuery objects are supposed to delete themselves when they are no longer needed, but due to the direct calls in tests this often does not happen.

To keep internals in recursive_query to a minimum, I did add something to the API; ForwardQuery is now a public class, a pointer of which is returned by RecursiveQuery::forward. Tests that mess around can then delete the query themselves, and the way these are handled does not have to be changed.

Ideally, we should however not need unscoped allocated memory in the first place; we either need to use a centrally managed pool of objects to (re)use, or we need to change the entire design that needs these objects in the first place.

However, these are both non-trivial, and probably better suited in the main resolver work that has been planned.

Valgrind complains (probably rightfully so) that memory is leaking in death-tests. This has been reported upstream, but is not addressed yet, and may not be in the near future, if at all (one response was don't use EXPECT_DEATH).

So I added a checker function, *if* valgrind headers are available, that returns true if the tests are run under valgrind. Death tests are now ignored if so.

Note that we should be very careful about using this; and only use it for things we are sure valgrind can't help, since it is possible to do things differently when using valgrind, which kind of defeats its purpose

Conflicts:
	ChangeLog
	src/lib/dhcp/cfgmgr.h
	src/lib/dhcp/tests/cfgmgr_unittest.cc

Conflicts:
	ChangeLog
	src/lib/dhcp/tests/Makefile.am

committing at my discretion.

Sunstudio is unhappy with plain NULL inside EXPECT_EQ and thinks it is
int. This makes it think otherwise.

This should fix compilation issue on sunstudio.

Planned for merge #2268

this works around a bit awkward installation setup where there's a link
from "python3" to "python3.x" but not from "python3-config" to the
corresponding "python3.x-config".  That happens for recent versions of
Homebrew.

And make it slightly stronger (it now checks something that should be
mostly obvious too, but who knows, with software).

Instead of releasing it directly. While the internal release was more
convenient, it didn't allow for swapping things fast under a mutex and
then spending the time releasing it unlocked.

It is supposed to be mostly private. Use it internally only.