BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2024-03-22T08:14:06Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2188Bug in message.c:673: ENSURE(isc_mempool_getallocated(msg->namepool) == 0) fa...2024-03-22T08:14:06ZFstarkBug in message.c:673: ENSURE(isc_mempool_getallocated(msg->namepool) == 0) failed<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please do *NOT* report it here, but send an
email to [...<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please do *NOT* report it here, but send an
email to [security-officer@isc.org](security-officer@isc.org).
-->
### Summary
message.c:673: ENSURE(isc_mempool_getallocated(msg->namepool) == 0) failed, back trace
```
test@test:~/bind9/collect$ ./dns_message_parse_fuzzer id\:000000\,sig\:06\,src\:002736+001626\,time\:192782276\,op\:splice\,rep\:128
INFO: Seed: 1666455395
INFO: Loaded 1 modules (61310 inline 8-bit counters): 61310 [0x100d2b0, 0x101c22e),
INFO: Loaded 1 PC tables (61310 PCs): 61310 [0x101c230,0x110ba10),
./dns_message_parse_fuzzer: Running 1 inputs 1 time(s) each.
Running: id:000000,sig:06,src:002736+001626,time:192782276,op:splice,rep:128
message.c:673: ENSURE(isc_mempool_getallocated(msg->namepool) == 0) failed, back trace
./dns_message_parse_fuzzer() [0xab474a]
./dns_message_parse_fuzzer() [0xab43d0]
./dns_message_parse_fuzzer() [0xab422a]
./dns_message_parse_fuzzer() [0x566c5f]
./dns_message_parse_fuzzer() [0x566da7]
./dns_message_parse_fuzzer() [0x551bc4]
./dns_message_parse_fuzzer() [0x550f98]
./dns_message_parse_fuzzer() [0x45a0c2]
./dns_message_parse_fuzzer() [0x445843]
./dns_message_parse_fuzzer() [0x44b89f]
./dns_message_parse_fuzzer() [0x473213]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7) [0x7f0090f5eb97]
./dns_message_parse_fuzzer() [0x41fed9]
==23768== ERROR: libFuzzer: deadly signal
#0 0x527611 in __sanitizer_print_stack_trace /src/llvm-project/compiler-rt/lib/asan/asan_stack.cpp:86:3
#1 0x472a38 in fuzzer::PrintStackTrace() /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerUtil.cpp:210:5
#2 0x458b63 in fuzzer::Fuzzer::CrashCallback() /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:232:3
#3 0x7f009196489f (/lib/x86_64-linux-gnu/libpthread.so.0+0x1289f)
#4 0x7f0090f7bf46 in __libc_signal_restore_set /build/glibc-2ORdQG/glibc-2.27/signal/../sysdeps/unix/sysv/linux/nptl-signals.h:80
#5 0x7f0090f7bf46 in gsignal /build/glibc-2ORdQG/glibc-2.27/signal/../sysdeps/unix/sysv/linux/raise.c:48
#6 0x7f0090f7d8b0 in abort /build/glibc-2ORdQG/glibc-2.27/stdlib/abort.c:79
#7 0xab4233 in isc_assertion_failed /src/bind9/lib/isc/assertions.c:47:2
#8 0x566c5e in msgreset /src/bind9/lib/dns/message.c:673:2
#9 0x566da6 in dns_message_destroy /src/bind9/lib/dns/message.c:801:2
#10 0x551bc3 in render_message /src/bind9/fuzz/dns_message_parse.c:131:2
#11 0x550f97 in LLVMFuzzerTestOneInput /src/bind9/fuzz/dns_message_parse.c:162:11
#12 0x45a0c1 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:558:15
#13 0x445842 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:296:6
#14 0x44b89e in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:796:9
#15 0x473212 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:19:10
#16 0x7f0090f5eb96 in __libc_start_main /build/glibc-2ORdQG/glibc-2.27/csu/../csu/libc-start.c:310
#17 0x41fed8 in _start (/home/test/bind9/collect/dns_message_parse_fuzzer+0x41fed8)
NOTE: libFuzzer has rudimentary signal handlers.
Combine libFuzzer with AddressSanitizer or similar for better crash reports.
SUMMARY: libFuzzer: deadly signal
```
### BIND version used
master-git
### Steps to reproduce
./fuzzer POC
[bind9.zip](/uploads/58bf9e655b37622954937535b1e69bd6/bind9.zip)
### What is the current *bug* behavior?
crash
### Relevant logs and/or screenshots
File in zip
### Possible fixes
(If you can, link to the line of code that might be responsible for the
problem.)October 2020 (9.11.24, 9.11.24-S1, 9.16.8, 9.16.8-S1, 9.17.6)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2518IPv4 Flamethrower quit abruptly on FreeBSD 122024-01-22T16:23:03ZMichal NowakIPv4 Flamethrower quit abruptly on FreeBSD 12IPv4 Flamethrower quit abruptly in [stress:recursive:freebsd12:amd64](https://gitlab.isc.org/isc-private/bind9/-/jobs/1517463) CI job over the `v9_11_sub` branch:
```
2021-02-23:03:31:55 INFO: starting TCP generators
2021-02-23:03:31:55 ...IPv4 Flamethrower quit abruptly in [stress:recursive:freebsd12:amd64](https://gitlab.isc.org/isc-private/bind9/-/jobs/1517463) CI job over the `v9_11_sub` branch:
```
2021-02-23:03:31:55 INFO: starting TCP generators
2021-02-23:03:31:55 INFO: starting generator #3 (tcp) on 10.53.0.3 in /var/tmp/gitlab_runner/builds/YdCaoq4b/0/isc-private/bind9/output/generator3
2021-02-23:03:31:55 INFO: (using query file /var/tmp/gitlab_runner/builds/YdCaoq4b/0/isc-private/bind9/output/query_datafile)
2021-02-23:03:31:55 INFO: starting generator #4 (tcp) on [fd92:7065:b8e:ffff::3] in /var/tmp/gitlab_runner/builds/YdCaoq4b/0/isc-private/bind9/output/generator4
2021-02-23:03:31:55 INFO: (using query file /var/tmp/gitlab_runner/builds/YdCaoq4b/0/isc-private/bind9/output/query_datafile)
2021-02-23:03:31:55 INFO: checking processes, 1 hours 0 minutes left
2021-02-23:03:32:56 INFO: checking processes, 59 minutes left
2021-02-23:03:32:56 ERROR: process with PID file /var/tmp/gitlab_runner/builds/YdCaoq4b/0/isc-private/bind9/output/generator3/generator.pid (pid = 60111) is no longer running
```
`generator3/generator.log` does hot have the usual final summary when it exits correctly:
```
--class: "IN"
--dnssec: true
--help: false
--qps-flow: null
--targets: null
--version: false
-F: "inet"
-M: "GET"
-P: "tcp"
-Q: "10000"
-R: false
-T: "A"
-b: null
-c: "10"
-d: "1"
-f: "/var/tmp/gitlab_runner/builds/YdCaoq4b/0/isc-private/bind9/output/query_datafile"
-g: "file"
-l: "0"
-n: "0"
-o: null
-p: "5300"
-q: "10"
-r: "test.com"
-t: "3"
-v: "99"
GENOPTS: []
TARGET: "10.53.0.3"
file: push "091195.test.example.."
file: push "099598.test.example.."
file: push "011761.test.example.."
file: push "097867.test.example.."
file: push "025447.test.example.."
file: push "037011.test.example.."
file: push "050838.test.example.."
file: push "022788.test.example.."
file: push "093318.test.example.."
file: push "076772.test.example.."
0 key/value generator arguments
binding to 0.0.0.0
flaming target(s) [10.53.0.3] on port 5300 with 30 concurrent generators, each sending 100 queries every 1000ms on protocol tcp
query generator [file] contains 105000 record(s)
rate limit @ 10000 QPS (333.333 QPS per concurrent sender)
0.00130632s: send: 0, avg send: 0, recv: 0, avg recv: 0, min/avg/max resp: 0/nan/0ms, in flight: 0, timeouts: 0
1.01032s: send: 3000, avg send: 3000, recv: 2200, avg recv: 2200, min/avg/max resp: 39.3282/225.582/593.608ms, in flight: 822, timeouts: 0
```
There's no core dump file in the artifact archive.
According to logs `named` instances appear to be working at the time when generator #3 quit.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/338unchecked dns_name_dup calls.2023-10-31T09:45:54ZMark Andrewsunchecked dns_name_dup calls.There are a number of dns_name_dup calls where the result is not checked. These all need to be checked.There are a number of dns_name_dup calls where the result is not checked. These all need to be checked.https://gitlab.isc.org/isc-projects/bind9/-/issues/46Integrate clang-tidy with GitLab CI2023-10-04T10:46:21ZOndřej SurýIntegrate clang-tidy with GitLab CIclang-tidy is a great tool for various source code checks. We should integrate running clang-tidy as part of our CI workflow.clang-tidy is a great tool for various source code checks. We should integrate running clang-tidy as part of our CI workflow.March 2020 (9.11.17, 9.16.1, 9.17.0)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3893Make Debian 12 "bookworm" the base image2023-09-04T06:53:43ZMichal NowakMake Debian 12 "bookworm" the base imageWhen a new Debian stable image is released, it is posed to become our next CI base image. This is a good time to clean up accumulated workarounds from the current base image and BIND 9 CI. Debian 12 "bookworm" is expected to stabilize in...When a new Debian stable image is released, it is posed to become our next CI base image. This is a good time to clean up accumulated workarounds from the current base image and BIND 9 CI. Debian 12 "bookworm" is expected to stabilize in mid-2023.
## Images
- [x] Drop custom Unbound installation in favor of the `unbound` Debian package (https://gitlab.isc.org/isc-projects/images/-/merge_requests/222#note_354221)
- [x] ~~Drop an upstream patch that prevents PyLint from reporting "no-member" errors for scripts using dnspython~~
- [x] Drop custom `cmocka` build if the distributed version is older than 1.1.3 (it is for all current Debian versions)
- [x] Drop `ABI_CHECK` - with BIND 9.11 EOL, we don't need those tools anymore
- [ ] Bump reference BIND 9 for respdiff as BIND 9.11 likely won't build with GCC 12
## BIND 9
- [ ] _Bring your own issues_September 2023 (9.16.44, 9.16.44-S1, 9.18.19, 9.18.19-S1, 9.19.17)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3933Add GCC static analyzer to CI2023-07-18T06:09:17ZMichal NowakAdd GCC static analyzer to CIAdd Fedora CI job with GCC static analyzer (`-fanalyzer`).
Blocking issues:
- isc-projects/bind9#3929
- isc-projects/bind9#3930
- isc-projects/bind9#3931
- isc-projects/bind9#3932Add Fedora CI job with GCC static analyzer (`-fanalyzer`).
Blocking issues:
- isc-projects/bind9#3929
- isc-projects/bind9#3930
- isc-projects/bind9#3931
- isc-projects/bind9#3932Not plannedMichal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3978Support using pytest to execute the system tests2023-06-14T10:14:58ZTom KrizekSupport using pytest to execute the system testsAdd an option to execute the entire system test suite with pytest. This should co-exist along with the legacy runner which will be removed at a later point.
For reasons, benefits and timeline, refer to the meta issue [#3810](https://git...Add an option to execute the entire system test suite with pytest. This should co-exist along with the legacy runner which will be removed at a later point.
For reasons, benefits and timeline, refer to the meta issue [#3810](https://gitlab.isc.org/isc-projects/bind9/-/issues/3810).June 2023 (9.16.42, 9.16.42-S1, 9.18.16, 9.18.16-S1, 9.19.14)Tom KrizekTom Krizekhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2663Add memory context size-specific stats to stats channel when configured with ...2023-01-24T11:19:41ZBrian ConryAdd memory context size-specific stats to stats channel when configured with --enable-developerTo aid in some investigative/optimization efforts. This will add a lot of data to the stats channel output and isn't something that would be of use to a typical operator.To aid in some investigative/optimization efforts. This will add a lot of data to the stats channel output and isn't something that would be of use to a typical operator.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2219BIND 9.11 built with --disable-atomic seems to be leaking memory on FreeBSD2022-12-26T07:03:18ZMichał KępieńBIND 9.11 built with --disable-atomic seems to be leaking memory on FreeBSD![bind-9.11-freebsd-authoritative-12h](/uploads/18d80662f773ad077866e73eb6731f61/bind-9.11-freebsd-authoritative-12h.png)
The problem does not seem to exist in atomics-enabled builds or on
Linux. Perhaps a missing `isc_mutex_destroy()`...![bind-9.11-freebsd-authoritative-12h](/uploads/18d80662f773ad077866e73eb6731f61/bind-9.11-freebsd-authoritative-12h.png)
The problem does not seem to exist in atomics-enabled builds or on
Linux. Perhaps a missing `isc_mutex_destroy()` call somewhere?
The graph above was prepared for an "authoritative" mode ["stress"
test][1] run. The leak is also triggered in "recursive" mode, though to
a smaller extent.
[1]: https://gitlab.isc.org/isc-private/bind-qa/-/tree/master/bind9/stressBIND 9.17 Backburnerhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3651update danger to check for Approved2022-12-06T10:48:19ZEvan Huntupdate danger to check for ApprovedWe've started using Approve rather than LGTM to mark merge requests as ready to merge, but danger will still report:
```
elif "LGTM (Merge OK)" not in mr_labels:
warn(
"This merge request is currently in review. "
"I...We've started using Approve rather than LGTM to mark merge requests as ready to merge, but danger will still report:
```
elif "LGTM (Merge OK)" not in mr_labels:
warn(
"This merge request is currently in review. "
"It should not be merged until it is marked with the *LGTM* label."
)
```
I'd fix it myself, but I'm so unfamiliar with the gitlab API, I don't even know how Mr. Labels got set in the first place.December 2022 (9.16.36, 9.16.36-S1, 9.18.10, 9.19.8)Tom KrizekTom Krizekhttps://gitlab.isc.org/isc-projects/bind9/-/issues/147Add Windows to GitLab CI2022-11-10T14:18:14ZOndřej SurýAdd Windows to GitLab CIOctober 2019 (9.11.12, 9.14.7, 9.15.5)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3054"External" memory leaks are not detected by GitLab CI2022-10-05T07:14:03ZMichał Kępień"External" memory leaks are not detected by GitLab CIIf `named`'s memory use grows over time, but that growth is reflected in
the "in use" statistics of libisc memory contexts, tracking down the
source of such growth is a matter of time. However, not all memory that
`named` uses is contai...If `named`'s memory use grows over time, but that growth is reflected in
the "in use" statistics of libisc memory contexts, tracking down the
source of such growth is a matter of time. However, not all memory that
`named` uses is contained in libisc memory contexts: every linked shared
library might also perform its own memory allocations. If those are not
cleaned up properly, core dump examination is no good for tracking them
down unless the "needle" (i.e. what we are looking for) is known
beforehand, which is rarely the case.
The most notable example of this type of problem are memory leaks which
are specific to FreeBSD - these are usually caused by the fact that
libthr (the POSIX Threads implementation FreeBSD currently uses)
allocates memory on the heap for most of its objects upon their
creation. If such an object is a part of an often-recycled data
structure used by `named` (e.g. a socket), missing destructors can lead
to memory exhaustion issues over time, but only on specific operating
systems. This has already happened at least twice so far.
Finding a method of detecting "external" memory leaks in GitLab CI
should prevent such problems from reoccurring in the future.
See #3051August 2022 (9.16.32, 9.16.32-S1, 9.18.6, 9.19.4)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2371Add stress testing with RPZ2022-06-28T18:44:28ZMichal NowakAdd stress testing with RPZhttps://gitlab.isc.org/isc-private/bind-qa/-/issues/11 added RPZ to the stress test, https://gitlab.isc.org/isc-private/bind-qa/-/merge_requests/27 prepared stress test for GitLab CI. I recently run the code locally and it worked fine.
...https://gitlab.isc.org/isc-private/bind-qa/-/issues/11 added RPZ to the stress test, https://gitlab.isc.org/isc-private/bind-qa/-/merge_requests/27 prepared stress test for GitLab CI. I recently run the code locally and it worked fine.
The missing piece is to add stress test RPZ to the `performance` stage in CI. For that to happen, following items need to be addressed:
- [x] isc-private/devops#130 Let AWS stress test machines access 149.20.57.31
- [x] https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4526 Add RPZ stress test job for all supported platforms and maintained branches, seeJuly 2022 (9.16.31, 9.16.31-S1, 9.18.5, 9.19.3)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/bind9/-/issues/42scan-build: Branch condition evaluates to a garbage value in bin/dnssec/dnsse...2022-06-17T16:42:28ZOndřej Surýscan-build: Branch condition evaluates to a garbage value in bin/dnssec/dnssec-signzone.cllvm 5.0.0 scan-build reports Logic error in bin/dnssec/dnssec-signzone.c in `hashlist_free` function.
Install full llvm (on Mac OS X: `brew install llvm --with-toolchain`)
Unpack the zip [scan-build-2017-12-18-110416-46298-1.zip](/upl...llvm 5.0.0 scan-build reports Logic error in bin/dnssec/dnssec-signzone.c in `hashlist_free` function.
Install full llvm (on Mac OS X: `brew install llvm --with-toolchain`)
Unpack the zip [scan-build-2017-12-18-110416-46298-1.zip](/uploads/4d79cc3e65e3e30453dff492a830a443/scan-build-2017-12-18-110416-46298-1.zip) and run:
`scan-view scan-build-2017-12-18-110416-46298-1` (on Mac OS X `/usr/local/opt/llvm/scan-view scan-build-2017-12-18-110416-46298-1`)BIND-9.13.0https://gitlab.isc.org/isc-projects/bind9/-/issues/3371Check for __attribute__((fallthrough)) support is sometimes incorrect2022-05-30T09:49:33ZJoshua RootCheck for __attribute__((fallthrough)) support is sometimes incorrect### Description
Clang added support for the gcc-style fallthrough attribute (i.e. `__attribute__((fallthrough))`) in version 10. However, `__has_attribute(fallthrough)` will return 1 in C mode in older versions, even though they only su...### Description
Clang added support for the gcc-style fallthrough attribute (i.e. `__attribute__((fallthrough))`) in version 10. However, `__has_attribute(fallthrough)` will return 1 in C mode in older versions, even though they only support the C++11 fallthrough attribute. At best, the unsupported attribute is simply ignored; at worst, it causes errors like this:
```
In file included from rdata.c:604:
In file included from ./code.h:66:
./rdata/generic/opt_41.c:236:4: error: expected expression
FALLTHROUGH;
^
../../lib/isc/include/isc/util.h:65:21: note: expanded from macro 'FALLTHROUGH'
#define FALLTHROUGH __attribute__((fallthrough))
^
```
### Request
The C2x fallthrough attribute has the advantages of being supported in the broadest range of clang versions (added in version 9) and being easy to check for support. Therefore, I think it would be best to use it if possible, and fall back to not using an attribute for clang versions that don't have it. This patch implements that:
```patch
--- lib/isc/include/isc/util.h.orig 2022-05-09 19:32:19.000000000 +1000
+++ lib/isc/include/isc/util.h 2022-05-20 02:36:59.000000000 +1000
@@ -35,6 +35,10 @@
#define __has_attribute(x) 0
#endif /* if !defined(__has_attribute) */
+#if !defined(__has_c_attribute)
+#define __has_c_attribute(x) 0
+#endif /* if !defined(__has_c_attribute) */
+
#if !defined(__has_feature)
#define __has_feature(x) 0
#endif /* if !defined(__has_feature) */
@@ -61,7 +65,9 @@
#define ISC_NONSTRING
#endif /* __GNUC__ */
-#if __GNUC__ >= 7 || __has_attribute(fallthrough)
+#if __has_c_attribute(fallthrough)
+#define FALLTHROUGH [[fallthrough]]
+#elif !defined(__clang__) && (__GNUC__ >= 7 || __has_attribute(fallthrough))
#define FALLTHROUGH __attribute__((fallthrough))
#else
/* clang-format off */
```
### Links / references
https://github.com/llvm/llvm-project/commit/1e0affb6e564b7361b0aadb38805f26deff4ecfcJune 2022 (9.16.30, 9.16.30-S1, 9.18.4, 9.19.2)https://gitlab.isc.org/isc-projects/bind9/-/issues/3297Address PyLint 2.13.7 warnings2022-04-22T10:35:27ZMichał KępieńAddress PyLint 2.13.7 warningsPyLint 2.13.7 reports some new warnings for various Python bits in the
repository:
- ~"v9.19", ~"v9.18"
```
************* Module conftest
bin/tests/system/doth/conftest.py:34:28: E0601: Using variable 'stderr' before assi...PyLint 2.13.7 reports some new warnings for various Python bits in the
repository:
- ~"v9.19", ~"v9.18"
```
************* Module conftest
bin/tests/system/doth/conftest.py:34:28: E0601: Using variable 'stderr' before assignment (used-before-assignment)
```
This is a blocker, but it is trivial to fix.
- ~"v9.16"
```
************* Module setup
bin/python/setup.py:12:0: W0402: Uses of a deprecated module 'distutils.core' (deprecated-module)
```
This is strictly speaking *not* a blocker because this warning is
only raised for Python 3.10+ (see [PEP 632][1]) while Debian
"bullseye", which we use PyLint on, only has Python 3.9. That being
said, we might as well fix this problem today and be done with it.
The exact way of addressing the PyLint warning will be discussed in
a relevant merge request.
Blocks #3260
[1]: https://peps.python.org/pep-0632/May 2022 (9.16.29, 9.16.29-S1, 9.18.3, 9.19.1)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3123v9.16 test failure in Perflab: uv_udp_init_ex() errors out2022-02-02T08:12:15ZPetr Špačekpspacek@isc.orgv9.16 test failure in Perflab: uv_udp_init_ex() errors outVersion
=======
~"Affects v9.16" : Since isc-projects/bind9!5717 was merged.
Symptom
=======
Perflab test config LTT/v9_16/recursive/NXD-medium/dnsgen started failing.
`named` errors out before the test even starts with message:
```
ud...Version
=======
~"Affects v9.16" : Since isc-projects/bind9!5717 was merged.
Symptom
=======
Perflab test config LTT/v9_16/recursive/NXD-medium/dnsgen started failing.
`named` errors out before the test even starts with message:
```
udp.c:226: fatal error: RUNTIME_CHECK(r == 0) failed
```
Example of an affected run:
https://perflab.isc.org/#/run/test/61f911b58d88f33170df08b6/
Additional info
===============
Surprisingly, other test configurations do not seem to be affected, not even on v9_16 branch.
In any case, this is very suspicious and needs investigation ASAP before we tag %"February 2022 (9.16.26, 9.16.26-S1)". It stopped working during this monthly cycle so if it is a bug then it is a regression.February 2022 (9.16.26, 9.16.26-S1)https://gitlab.isc.org/isc-projects/bind9/-/issues/2885Pylint "no-member" check fails on Bullseye2022-01-11T15:15:06ZMichal NowakPylint "no-member" check fails on BullseyeJob [#1947023](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1947023) failed for 24813ab4f5946fe7502ed35bbbdbb3fef236479d on Debian 11 Bullseye with:
```
$ PYTHONPATH="$PYTHONPATH:$CI_PROJECT_DIR/bin/python"
$ pylint --rcfile $CI_PROJ...Job [#1947023](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1947023) failed for 24813ab4f5946fe7502ed35bbbdbb3fef236479d on Debian 11 Bullseye with:
```
$ PYTHONPATH="$PYTHONPATH:$CI_PROJECT_DIR/bin/python"
$ pylint --rcfile $CI_PROJECT_DIR/.pylintrc $(git ls-files '*.py' | grep -vE '(ans\.py|dangerfile\.py)')
************* Module tests-checkds
bin/tests/system/checkds/tests-checkds.py:98:27: E1101: Module 'dns.rcode' has no 'NOERROR' member (no-member)
bin/tests/system/checkds/tests-checkds.py:101:50: E1101: Module 'dns.rdataclass' has no 'IN' member (no-member)
bin/tests/system/checkds/tests-checkds.py:102:24: E1101: Module 'dns.rdatatype' has no 'DS' member (no-member)
bin/tests/system/checkds/tests-checkds.py:102:42: E1101: Module 'dns.rdatatype' has no 'NONE' member (no-member)
bin/tests/system/checkds/tests-checkds.py:143:33: E1101: Module 'dns.rcode' has no 'NOERROR' member (no-member)
bin/tests/system/checkds/tests-checkds.py:161:29: E1101: Module 'dns.rcode' has no 'NOERROR' member (no-member)
************* Module helper
bin/tests/system/statschannel/helper.py:98:26: E1101: Module 'dns.rcode' has no 'NOERROR' member (no-member)
bin/tests/system/statschannel/helper.py:106:26: E1101: Module 'dns.rcode' has no 'NOERROR' member (no-member)
************* Module tests-tcp
bin/tests/system/timeouts/tests-tcp.py:149:33: E1101: Module 'dns.message' has no 'ANSWER' member (no-member)
bin/tests/system/timeouts/tests-tcp.py:150:33: E1101: Module 'dns.rdataclass' has no 'IN' member (no-member)
bin/tests/system/timeouts/tests-tcp.py:150:52: E1101: Module 'dns.rdatatype' has no 'SOA' member (no-member)
bin/tests/system/timeouts/tests-tcp.py:157:37: E1101: Module 'dns.message' has no 'ANSWER' member (no-member)
bin/tests/system/timeouts/tests-tcp.py:158:37: E1101: Module 'dns.rdataclass' has no 'IN' member (no-member)
bin/tests/system/timeouts/tests-tcp.py:158:56: E1101: Module 'dns.rdatatype' has no 'SOA' member (no-member)
-----------------------------------
Your code has been rated at 9.40/10
```
This needs to be fixed for the base image being switched to Bullseye.January 2022 (9.16.25, 9.16.25-S1, 9.17.22)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2886cppcheck fails on Bullseye2022-01-11T14:25:35ZMichal Nowakcppcheck fails on BullseyeJob [#1947020](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1947020) failed for 24813ab4f5946fe7502ed35bbbdbb3fef236479d on Debian 11 Bullseye with the following warnings:
| lib/dns/ttl.c || | | | ...Job [#1947020](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1947020) failed for 24813ab4f5946fe7502ed35bbbdbb3fef236479d on Debian 11 Bullseye with the following warnings:
| lib/dns/ttl.c || | | |
|---------------|-------------|-----|---------|---------------------------------------------------------------------------------------|
| 76 | zerodivcond | 369 | warning | Either the condition 'weeks!=0' is redundant or there is division by zero at line 76. |
| 77 | zerodivcond | 369 | warning | Either the condition 'weeks!=0' is redundant or there is division by zero at line 77. |
| 78 | zerodivcond | 369 | warning | Either the condition 'weeks!=0' is redundant or there is division by zero at line 78. |
| 80 | zerodivcond | 369 | warning | Either the condition 'weeks!=0' is redundant or there is division by zero at line 80. |
| 82 | zerodivcond | 369 | warning | Either the condition 'weeks!=0' is redundant or there is division by zero at line 82. |
The `cppcheck` tool should be the same, something else changed in Bullseye.
This needs to be fixed for the base image being switched to Bullseye.
[Cppcheck_-_HTML_report_-_BIND_9__24813ab4__Cppcheck_Report.html](/uploads/d2e514933310f66ffeb02f9df9c2367b/Cppcheck_-_HTML_report_-_BIND_9__24813ab4__Cppcheck_Report.html)January 2022 (9.16.25, 9.16.25-S1, 9.17.22)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2698Issues with cppcheck 2.4.1, 2.52022-01-11T14:25:31ZMichał KępieńIssues with cppcheck 2.4.1, 2.5cppcheck 2.4.1 is now available, but, while it fixes one of the issues
with cppcheck 2.3, it also introduces a new set of false positives we
would have to deal with. IMHO we should skip updating to this version
for the time being.
---
...cppcheck 2.4.1 is now available, but, while it fixes one of the issues
with cppcheck 2.3, it also introduces a new set of false positives we
would have to deal with. IMHO we should skip updating to this version
for the time being.
---
cppcheck 2.4.1 triggers the following type of false positives:
```
lib/isc/netaddr.c:274:8: warning: The address of local variable 'in' might be accessed at non-zero index. [objectIndex]
if (p[i] != 0xFF) {
^
lib/isc/netaddr.c:263:30: note: Address of variable taken here.
p = (const unsigned char *)&s->type.in;
^
lib/isc/netaddr.c:274:8: note: The address of local variable 'in' might be accessed at non-zero index.
if (p[i] != 0xFF) {
^
```
The affected files are:
- `bin/dnssec/dnssec-cds.c`
- `lib/dns/ecs.c`
- `lib/dns/resolver.c`
- `lib/isc/netaddr.c`
- `lib/ns/client.c`
It seems that cppcheck gets confused about data sizes when structure
pointers are explicitly cast.
Multiple upstream reports about similar issues are already opened:
- https://trac.cppcheck.net/ticket/10133
- https://trac.cppcheck.net/ticket/10213
- https://trac.cppcheck.net/ticket/10154
- https://trac.cppcheck.net/ticket/10156
None of the above problems have yet been resolved in cppcheck's `main`
branch, therefore I did not bother to create yet another upstream issue
for this. I suggest we wait and see what happens in future cppcheck
releases.
---
[Upstream commit c267d85640523c045c7d43ba7ce9c0f305423c5d][1] triggers
the following type of false positives:
```
lib/isc/base64.c:119:10: warning: Either the condition 'ctx->digits==4' is redundant or the array 'ctx->val[4]' is accessed at index 4, which is out of bounds. [arrayIndexOutOfBoundsCond]
ctx->val[ctx->digits++] = (int)(s - base64);
^
lib/isc/base64.c:120:18: note: Assuming that condition 'ctx->digits==4' is not redundant
if (ctx->digits == 4) {
^
lib/isc/base64.c:119:10: note: Array index out of bounds
ctx->val[ctx->digits++] = (int)(s - base64);
^
```
The affected files are:
- `lib/isc/base64.c`
- `lib/isc/base32.c`
- `lib/isc/hex.c`
I [reported this upstream][2] because it is still not addressed in
cppcheck's development branch.
[1]: https://github.com/danmar/cppcheck/commit/c267d85640523c045c7d43ba7ce9c0f305423c5d
[2]: https://sourceforge.net/p/cppcheck/discussion/general/thread/128272da00/January 2022 (9.16.25, 9.16.25-S1, 9.17.22)Michał KępieńMichał Kępień