It might happen that we have a stale PID file, e.g. after a crash,
but some other process has taken the freed PID already.

Release 6.0.17

See merge request !1762

It's just removing an assertion, and it does make sense to me.
Also expose kr_rule_local_data_ins() in Lua, like other similar functions.

Otherwise we get use-after-free when attempting to close the cache
after this failure causes the process to shut down.

In particular, I was now interested in `cache-gc`
and incorrectly assumed that it's merged with `cache`
(the C code didn't help, as they appear merged on that level).

With clang they'd cause lots of complaints:
  warning: '_Static_assert' with no message is a C23 extension [-Wc23-extensions]

Also simplify the related code a little.
I don't think this has any practical impact.

The code clearly assumes it isn't, and I checked that it never is called
that way (and it would crash anyway).

Affects just clang, apparently.  This is just a copy from knot-dns changes,
doing a bit more than this resolver commit title says.  See:
knot-dns@ec4a2567
knot-dns@509d9d82

It seemed to bring more complexity than benefit.
In many parts this meant revert to code before a few commits.

It's slightly tricky that qry or req may be NULL in some cases,
but I believe I've caught all of them by conditions, and moreover
they're cases where it doesn't make sense to update kr_cache_top_*

Move the function up unchanged and use it on two places
which have the exact lines as the function.
Also fix its description.

Just by dropping some padding in the header.
Also drop a long outdated part of comment on this.

kru.h would be a bit complicated to adapt, so let's avoid it.
I don't think uint32_t as return price will be an issue,
though we might... e.g. add a static_assert() into top.c

Lukáš Ondráček authored Jul 16, 2025 and Vladimír Čunát committed Dec 01, 2025

As the resolver fixes the state now, and loss of data is to be expected
on cache size change, vcunat downgraded the log severity of this.