ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2020-10-16T12:09:23Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/1471set default log check verbosity from the environment2020-10-16T12:09:23ZFrancis Dupontset default log check verbosity from the environmentThe src/lib/testutils/log_utils.h allows the check logs in unit tests and offer a logCheckVerbose method to set the verbosity flags i.e. to display real and expected logs. Unfortunately in practice to use it you have to edit the file and...The src/lib/testutils/log_utils.h allows the check logs in unit tests and offer a logCheckVerbose method to set the verbosity flags i.e. to display real and expected logs. Unfortunately in practice to use it you have to edit the file and rebuild. I propose to make its default (currently false so not verbose) depending in an environment variable e.g. KEA_LOG_CHECK_VERBOSE.
Idea from https://gitlab.isc.org/isc-projects/kea/-/merge_requests/972#note_169904kea1.9.1Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/bind9/-/issues/2218Ensure use of "echo_i" where possible in system tests2020-10-30T10:23:25ZMichal NowakEnsure use of "echo_i" where possible in system testsInstead of using `echo_i`, some tests print output via `echo "I:...`, which in many instances misses test name, e.g. `tsiggss`:
```
S:tsiggss:2020-10-15T10:16:58+0200
T:tsiggss:1:A
A:tsiggss:System test tsiggss
I:tsiggss:PORTS:12408,1240...Instead of using `echo_i`, some tests print output via `echo "I:...`, which in many instances misses test name, e.g. `tsiggss`:
```
S:tsiggss:2020-10-15T10:16:58+0200
T:tsiggss:1:A
A:tsiggss:System test tsiggss
I:tsiggss:PORTS:12408,12409,12410,12411,12412,12413,12414,12415,12416,12417
I:tsiggss:starting servers
I:testing updates to testdc1 as administrator (1)
```
I am not sure which branch was that but recently I saw a file with all `*.log` files merged (and sorted?) and it wasn't clear to which a "failed" info line belong.November 2020 (9.11.25, 9.11.25-S1, 9.16.9, 9.16.9-S1, 9.17.7)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/kea/-/issues/1470Trying to config-set or config-test responds with "Missing mandatory 'Control...2020-10-14T19:55:04Zdlewis-shTrying to config-set or config-test responds with "Missing mandatory 'Control-agent' parameter"The docs say nothing of this 'Control-agent' parameter, and I am just trying to update the Dhcp4 config with and API call with the following payload:
```
{
"command": "config-test",
"arguments": {
"Dhcp4": {
...The docs say nothing of this 'Control-agent' parameter, and I am just trying to update the Dhcp4 config with and API call with the following payload:
```
{
"command": "config-test",
"arguments": {
"Dhcp4": {
:
}
}
}
```https://gitlab.isc.org/isc-projects/bind9/-/issues/2217TLS offloading with DOH2021-02-03T16:10:01ZVicky Riskvicky@isc.orgTLS offloading with DOHApparently the https library we are using for DOH supports http. At least one user would like to be able to use a TLS proxy.
some reasons:
* certificate rotation - e.g. Apache or nginx proxy can use ACME to automate all the certificate...Apparently the https library we are using for DOH supports http. At least one user would like to be able to use a TLS proxy.
some reasons:
* certificate rotation - e.g. Apache or nginx proxy can use ACME to automate all the certificate dance
* client authentication - TLS client certs + augmenting HTTP headers with proxied-for information
* logging at HTTP level
* offload the TLS processing on a dedicated system to reduce the impact of TLS on the BIND server and to centralize the certificate mgmt
- [ ] Please test this to see if it works
- [ ] Please document that this is supported in the ARM
ref: https://support.isc.org/Ticket/ModifyLinks.html?id=16797February 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/stork/-/issues/427developer documentation is needed for system tests2020-10-19T08:36:32ZMichal Nowikowskideveloper documentation is needed for system tests0.13Michal NowikowskiMichal Nowikowskihttps://gitlab.isc.org/isc-projects/bind9/-/issues/2215DNS_ZONEFLAG_NOIXFR is misnamed2020-10-30T10:31:56ZBrian ConryDNS_ZONEFLAG_NOIXFR is misnamedAll of the other zone flags are prefixed `DNS_ZONEFLG` instead of `DNS_ZONEFLAG`All of the other zone flags are prefixed `DNS_ZONEFLG` instead of `DNS_ZONEFLAG`November 2020 (9.11.25, 9.11.25-S1, 9.16.9, 9.16.9-S1, 9.17.7)https://gitlab.isc.org/isc-projects/kea/-/issues/1469missing upgrade_X.A_to_Y.B from Makefile (install and distclean)2020-11-27T10:30:56ZRazvan Becheriumissing upgrade_X.A_to_Y.B from Makefile (install and distclean)missing upgrade_X.A_to_Y.B from Makefilemissing upgrade_X.A_to_Y.B from Makefilekea1.9.1Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/1468Failing compilation of unit tests due to using namespace isc::db::test2020-10-13T16:07:38ZMarcin SiodelskiFailing compilation of unit tests due to using namespace isc::db::testThe compilation error is as follows:
```
20:49:49.208 cfg_db_access_unittest.cc:31:26: error: ‘test’ is not a namespace-name
20:49:49.208 using namespace isc::db::test;
20:49:49.208 ^~~~
20:49:49.208 cfg_d...The compilation error is as follows:
```
20:49:49.208 cfg_db_access_unittest.cc:31:26: error: ‘test’ is not a namespace-name
20:49:49.208 using namespace isc::db::test;
20:49:49.208 ^~~~
20:49:49.208 cfg_db_access_unittest.cc:31:30: error: expected namespace-name before ‘;’ token
20:49:49.208 using namespace isc::db::test;
20:49:49.208 ^
20:49:49.208 Makefile:1116: recipe for target 'libdhcpsrv_unittests-cfg_db_access_unittest.o' failed
```
It is related to the conditional inclusion of the header files providing this namespace. When MYSQL, Postgres etc are not in use the header files are not included and therefore the namespace is missing.kea1.9.1Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/stork/-/issues/426Sanity checks for 0.12.0 respin 22022-02-02T09:51:30ZWlodzimierz WencelSanity checks for 0.12.0 respin 2Please do sanity checks according to steps below:
1. Please, get the tarball and check it, run tests.<br>
tarball: https://gitlab.isc.org/isc-projects/stork/-/jobs/1217539/artifacts/browse
2. Start demo locally (rake docker_up) ...Please do sanity checks according to steps below:
1. Please, get the tarball and check it, run tests.<br>
tarball: https://gitlab.isc.org/isc-projects/stork/-/jobs/1217539/artifacts/browse
2. Start demo locally (rake docker_up) and follow the steps from https://gitlab.isc.org/isc-projects/stork/-/wikis/Demo
3. Install server and agent locally e.g. in VMs from binary packages:<br>
debs: https://gitlab.isc.org/isc-projects/stork/-/jobs/1217540/artifacts/browse<br>
rpms: https://gitlab.isc.org/isc-projects/stork/-/jobs/1217541/artifacts/browse0.12https://gitlab.isc.org/isc-projects/bind9/-/issues/2211tsan error previous_closest_nsec(dns_rbt_findnode) vs subtractrdataset2020-11-12T14:04:00ZMark Andrewstsan error previous_closest_nsec(dns_rbt_findnode) vs subtractrdatasetJob [#1217843](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1217843) failed for 834f0f5a1a55a6e8cd08dde6a481332a43cf8c0c:
```
WARNING: ThreadSanitizer: data race
Read of size 8 at 0x000000000001 by thread T1 (mutexes: read M1, re...Job [#1217843](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1217843) failed for 834f0f5a1a55a6e8cd08dde6a481332a43cf8c0c:
```
WARNING: ThreadSanitizer: data race
Read of size 8 at 0x000000000001 by thread T1 (mutexes: read M1, read M2):
#0 dns_rbt_findnode lib/dns/rbt.c:1708
#1 previous_closest_nsec lib/dns/rbtdb.c:3760
#2 find_closest_nsec lib/dns/rbtdb.c:3942
#3 zone_find lib/dns/rbtdb.c:4091
#4 dns_db_findext lib/dns/db.c:536
#5 query_lookup lib/ns/query.c:5582
#6 ns__query_start lib/ns/query.c:5505
#7 query_setup lib/ns/query.c:5229
#8 ns_query_start lib/ns/query.c:11380
#9 ns__client_request lib/ns/client.c:2166
#10 processbuffer netmgr/tcpdns.c:230
#11 dnslisten_readcb netmgr/tcpdns.c:309
#12 read_cb netmgr/tcp.c:832
#13 <null> <null>
#14 <null> <null>
Previous write of size 8 at 0x000000000001 by thread T2 (mutexes: write M3):
#0 subtractrdataset lib/dns/rbtdb.c:7133
#1 dns_db_subtractrdataset lib/dns/db.c:742
#2 diff_apply lib/dns/diff.c:368
#3 dns_diff_apply lib/dns/diff.c:459
#4 do_one_tuple lib/dns/update.c:247
#5 update_one_rr lib/dns/update.c:275
#6 delete_if_action lib/dns/update.c:689
#7 foreach_rr lib/dns/update.c:471
#8 delete_if lib/dns/update.c:716
#9 dns_update_signaturesinc lib/dns/update.c:1948
#10 receive_secure_serial lib/dns/zone.c:15637
#11 dispatch lib/isc/task.c:1152
#12 run lib/isc/task.c:1344
#13 <null> <null>
Location is heap block of size 130 at 0x000000000028 allocated by thread T3:
#0 malloc <null>
#1 default_memalloc lib/isc/mem.c:713
#2 mem_get lib/isc/mem.c:622
#3 mem_allocateunlocked lib/isc/mem.c:1268
#4 isc___mem_allocate lib/isc/mem.c:1288
#5 isc__mem_allocate lib/isc/mem.c:2453
#6 isc___mem_get lib/isc/mem.c:1037
#7 isc__mem_get lib/isc/mem.c:2432
#8 create_node lib/dns/rbt.c:2239
#9 dns_rbt_addnode lib/dns/rbt.c:1202
#10 dns_rbtdb_create lib/dns/rbtdb.c:8668
#11 dns_db_create lib/dns/db.c:118
#12 receive_secure_db lib/dns/zone.c:16154
#13 dispatch lib/isc/task.c:1152
#14 run lib/isc/task.c:1344
#15 <null> <null>
Mutex M1 (0x000000000040) created at:
#0 pthread_rwlock_init <null>
#1 isc_rwlock_init lib/isc/rwlock.c:39
#2 dns_rbtdb_create lib/dns/rbtdb.c:8527
#3 dns_db_create lib/dns/db.c:118
#4 receive_secure_db lib/dns/zone.c:16154
#5 dispatch lib/isc/task.c:1152
#6 run lib/isc/task.c:1344
#7 <null> <null>
Mutex M2 (0x000000000044) created at:
#0 pthread_rwlock_init <null>
#1 isc_rwlock_init lib/isc/rwlock.c:39
#2 dns_rbtdb_create lib/dns/rbtdb.c:8600
#3 dns_db_create lib/dns/db.c:118
#4 receive_secure_db lib/dns/zone.c:16154
#5 dispatch lib/isc/task.c:1152
#6 run lib/isc/task.c:1344
#7 <null> <null>
Mutex M3 (0x000000000046) created at:
#0 pthread_rwlock_init <null>
#1 isc_rwlock_init lib/isc/rwlock.c:39
#2 dns_rbtdb_create lib/dns/rbtdb.c:8600
#3 dns_db_create lib/dns/db.c:118
#4 receive_secure_db lib/dns/zone.c:16154
#5 dispatch lib/isc/task.c:1152
#6 run lib/isc/task.c:1344
#7 <null> <null>
Thread T1 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create pthreads/thread.c:73
#2 isc_nm_start netmgr/netmgr.c:232
#3 create_managers bin/named/main.c:909
#4 setup bin/named/main.c:1223
#5 main bin/named/main.c:1523
Thread T2 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create pthreads/thread.c:73
#2 isc_taskmgr_create lib/isc/task.c:1434
#3 create_managers bin/named/main.c:915
#4 setup bin/named/main.c:1223
#5 main bin/named/main.c:1523
Thread T3 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create pthreads/thread.c:73
#2 isc_taskmgr_create lib/isc/task.c:1434
#3 create_managers bin/named/main.c:915
#4 setup bin/named/main.c:1223
#5 main bin/named/main.c:1523
SUMMARY: ThreadSanitizer: data race lib/dns/rbt.c:1708 in dns_rbt_findnode
```November 2020 (9.11.25, 9.11.25-S1, 9.16.9, 9.16.9-S1, 9.17.7)https://gitlab.isc.org/isc-projects/kea/-/issues/1467Jumbled up errors when generating parsers with multiple make jobs2020-10-30T14:57:40ZAndrei Pavelandrei@isc.orgJumbled up errors when generating parsers with multiple make jobsErrors don't make much sense if you would attempt to solve them individually:
```
dhcp4_parser.h:2642: error: unterminated #else
2642 | #if 201103L <= YY_CPLUSPLUS
|
In file included from ../../../src/bin/dhcp4/parser_context.h:1...Errors don't make much sense if you would attempt to solve them individually:
```
dhcp4_parser.h:2642: error: unterminated #else
2642 | #if 201103L <= YY_CPLUSPLUS
|
In file included from ../../../src/bin/dhcp4/parser_context.h:12,
from parser_context.cc:9:
../../../src/bin/dhcp4/dhcp4_parser.h:45: error: unterminated #ifndef
45 | #ifndef YY_PARSER4_DHCP4_PARSER_H_INCLUDED
|
In file included from parser_context.cc:9:
../../../src/bin/dhcp4/parser_context.h:22:1: error: expected unqualified-id before ‘namespace’
22 | namespace isc {
```
and it goes on further.
What happens is that while generating the parsers, the Kea source files are also compiled. Kea source files depend on parser generated files. Bison doesn't write the entire file at once, it gradually fills it with content. So the parser generated files are fed into the compiler before they are complete. Even if the write to file was atomic, it would still mean that the parser files are potentially too old which would still be incorrect and maybe even pass compilation and result in underterministic behavior.
This is a lack of ordering issue between the parser generated files and the Kea source files.kea1.9.2Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/stork/-/issues/425Spurious directory created when running rake install_server2020-10-12T14:50:15ZMarcin SiodelskiSpurious directory created when running rake install_serverAs pointed out in the following comment: https://gitlab.isc.org/isc-projects/stork/-/issues/395#note_160894
there is empty directory created when running `rake install_server`.
The original report:
Extra directory. I did install stork...As pointed out in the following comment: https://gitlab.isc.org/isc-projects/stork/-/issues/395#note_160894
there is empty directory created when running `rake install_server`.
The original report:
Extra directory. I did install stork the following way:
```
rake install_server DESTDIR=/home/thomson/stork-0.11
```
The contents was installed properly, but there was an extra directory created: `/home/thomson/stork-0.11/home/thomson/devel/stork-0.11.0/tools/node-v12.16.2-linux-x64`
The dir is empty, though. There's a bug somewhere in the install scripts.0.12Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/stork/-/issues/424stork-db-migrate should report its version with the version flag2021-09-06T10:02:29ZMarcin Siodelskistork-db-migrate should report its version with the version flagAs suggested in one of the comments here: https://gitlab.isc.org/isc-projects/stork/-/issues/395#note_160894, the `stork-db-migrate` script should support `--version` switch and report its version. This switch is supported by other daemons.As suggested in one of the comments here: https://gitlab.isc.org/isc-projects/stork/-/issues/395#note_160894, the `stork-db-migrate` script should support `--version` switch and report its version. This switch is supported by other daemons.https://gitlab.isc.org/isc-projects/stork/-/issues/423rake build_agent fails on Debian 9 because retry-on-http-error is not supported2020-10-30T10:29:55ZMarcin Siodelskirake build_agent fails on Debian 9 because retry-on-http-error is not supportedAs stated in this comment: https://gitlab.isc.org/isc-projects/stork/-/issues/395#note_160896, the `--retry-on-http-error` flag is not supported by the `wget` versions < 1.19. We do use this flag when running `rake build_agent` task. We ...As stated in this comment: https://gitlab.isc.org/isc-projects/stork/-/issues/395#note_160896, the `--retry-on-http-error` flag is not supported by the `wget` versions < 1.19. We do use this flag when running `rake build_agent` task. We should consider checking the wget version and use it only when wget version is 1.19 or later.0.13Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/1466Add _config_defines.sh files to .gitignore2021-09-30T13:43:27ZAndrei Pavelandrei@isc.orgAdd _config_defines.sh files to .gitignore![image](/uploads/c1edfff90d65db61c17666432f0d2116/image.png)
I can't stand untracked files. How else than with .gitignore do you deal with it now?![image](/uploads/c1edfff90d65db61c17666432f0d2116/image.png)
I can't stand untracked files. How else than with .gitignore do you deal with it now?Kea1.9-backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/1464File descriptor holes breaking findLastSocketFd2020-10-14T08:49:32ZFrancis DupontFile descriptor holes breaking findLastSocketFdDuring #1428 review (https://gitlab.isc.org/isc-projects/kea/-/merge_requests/952#note_168595) I got a new unit test failure from a hole in the sequence of file descriptors which breaks the findLastSocketFd logic.
To avoid this problem ...During #1428 review (https://gitlab.isc.org/isc-projects/kea/-/merge_requests/952#note_168595) I got a new unit test failure from a hole in the sequence of file descriptors which breaks the findLastSocketFd logic.
To avoid this problem I propose a RAII tool which fills such holes. The RAII should avoid a file descriptor leak.kea1.9.1Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/bind9/-/issues/2210BIND 9.11.19 dead lock2021-05-26T20:44:51Znanwn147929@alibaba-inc.comBIND 9.11.19 dead lock<!--
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
Seems that BIND has a deadlock. and I don't find any related race condition issues, maybe it is a new issue?
### BIND version used
```
BIND 9.11.19-RedHat-9.11.10-20200601113814.alios7 (Extended Support Version) <id:905ec64>
running on Linux x86_64 3.10.0-327.ali2012.alios7.x86_64 #1 SMP Mon Oct 9 14:09:14 CST 2017
built by make with '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--program-prefix=' '--disable-dependency-tracking' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-libtool' '--localstatedir=/var' '--enable-threads' '--enable-epoll' '--with-tuning=large' '--enable-ipv6' '--with-pic' '--disable-static' '--disable-openssl-version-check' '--with-python=/home/tops/bin/python2.7' '--with-python-install-dir=/home/tops' '--with-docbook-xsl=/usr/share/sgml/docbook/xsl-stylesheets' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS= -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic' 'LDFLAGS=-Wl,-z,relro ' 'CPPFLAGS= -DDIG_SIGCHASE' 'PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'
compiled by GCC 4.8.5 20150623 (Red Hat 4.8.5-4)
compiled with OpenSSL version: OpenSSL 1.0.1e 11 Feb 2013
linked to OpenSSL version: OpenSSL 1.0.1e-fips 11 Feb 2013
compiled with libxml2 version: 2.9.1
linked to libxml2 version: 20901
compiled with zlib version: 1.2.7
linked to zlib version: 1.2.7
threads support is enabled
default paths:
named configuration: /etc/named.conf
rndc configuration: /etc/rndc.conf
DNSSEC root key: /etc/bind.keys
nsupdate session key: /var/run/named/session.key
named PID file: /var/run/named/named.pid
named lock file: /var/run/named/named.lock
```
### Steps to reproduce
Not clear.
### What is the current *bug* behavior?
BIND is hung.
### What is the expected *correct* behavior?
(What you should see instead.)
### Relevant configuration files
```
logging {
channel "default_debug" {
file "data/named.run";
severity dynamic;
};
};
options {
bindkeys-file "/etc/named.iscdlv.key";
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
listen-on port 53 {
127.0.0.1/32;
};
listen-on-v6 port 53 {
::1/128;
};
memstatistics-file "/var/named/data/named_mem_stats.txt";
statistics-file "/var/named/data/named_stats.txt";
dnssec-enable yes;
dnssec-lookaside auto;
dnssec-validation yes;
recursion yes;
allow-query {
"localhost";
};
};
zone "." IN {
type hint;
file "named.ca";
};
zone "localhost.localdomain" IN {
type master;
file "named.localhost";
allow-update {
"none";
};
};
zone "localhost" IN {
type master;
file "named.localhost";
allow-update {
"none";
};
};
zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" IN {
type master;
file "named.loopback";
allow-update {
"none";
};
};
zone "1.0.0.127.in-addr.arpa" IN {
type master;
file "named.loopback";
allow-update {
"none";
};
};
zone "0.in-addr.arpa" IN {
type master;
file "named.empty";
allow-update {
"none";
};
};
```
### Relevant logs and/or screenshots
Pstack result as followed:
```
Thread 19 (Thread 0x7f8a3d2fa700 (LWP 20008)):
#0 0x00007f8a3ee2f995 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib64/libpthread.so.0
#1 0x00007f8a3fafd4af in dispatch (manager=0x7f8a41514eb0) at task.c:1103
#2 run (uap=0x7f8a41514eb0) at task.c:1331
#3 0x00007f8a3ee2be25 in start_thread () from /usr/lib64/libpthread.so.0
#4 0x00007f8a3e7ebbad in clone () from /usr/lib64/libc.so.6
Thread 18 (Thread 0x7f8a3caf9700 (LWP 20009)):
#0 0x00007f8a3ee2f995 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib64/libpthread.so.0
#1 0x00007f8a3fafd4af in dispatch (manager=0x7f8a41514eb0) at task.c:1103
#2 run (uap=0x7f8a41514eb0) at task.c:1331
#3 0x00007f8a3ee2be25 in start_thread () from /usr/lib64/libpthread.so.0
#4 0x00007f8a3e7ebbad in clone () from /usr/lib64/libc.so.6
Thread 17 (Thread 0x7f8a3c2f8700 (LWP 20010)):
#0 0x00007f8a3ee3251d in __lll_lock_wait () from /usr/lib64/libpthread.so.0
#1 0x00007f8a3ee2de51 in _L_lock_1022 () from /usr/lib64/libpthread.so.0
#2 0x00007f8a3ee2ddf2 in pthread_mutex_lock () from /usr/lib64/libpthread.so.0
#3 0x00007f8a40e20cd5 in empty_bucket (res=0x7f87d17a14b8) at resolver.c:8910
#4 0x00007f8a40e26c51 in fctx_doshutdown (task=<optimized out>, event=<optimized out>) at resolver.c:4144
#5 0x00007f8a3fafd6bb in dispatch (manager=0x7f8a41514eb0) at task.c:1157
#6 run (uap=0x7f8a41514eb0) at task.c:1331
#7 0x00007f8a3ee2be25 in start_thread () from /usr/lib64/libpthread.so.0
#8 0x00007f8a3e7ebbad in clone () from /usr/lib64/libc.so.6
Thread 16 (Thread 0x7f8a3baf7700 (LWP 20011)):
#0 0x00007f8a3ee2f995 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib64/libpthread.so.0
#1 0x00007f8a3fafd4af in dispatch (manager=0x7f8a41514eb0) at task.c:1103
#2 run (uap=0x7f8a41514eb0) at task.c:1331
#3 0x00007f8a3ee2be25 in start_thread () from /usr/lib64/libpthread.so.0
#4 0x00007f8a3e7ebbad in clone () from /usr/lib64/libc.so.6
Thread 15 (Thread 0x7f8a3b2f6700 (LWP 20012)):
#0 0x00007f8a3ee2f995 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib64/libpthread.so.0
#1 0x00007f8a3fafd4af in dispatch (manager=0x7f8a41514eb0) at task.c:1103
#2 run (uap=0x7f8a41514eb0) at task.c:1331
#3 0x00007f8a3ee2be25 in start_thread () from /usr/lib64/libpthread.so.0
#4 0x00007f8a3e7ebbad in clone () from /usr/lib64/libc.so.6
Thread 14 (Thread 0x7f8a3aaf5700 (LWP 20013)):
#0 0x00007f8a3ee2f995 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib64/libpthread.so.0
#1 0x00007f8a3fafd4af in dispatch (manager=0x7f8a41514eb0) at task.c:1103
#2 run (uap=0x7f8a41514eb0) at task.c:1331
#3 0x00007f8a3ee2be25 in start_thread () from /usr/lib64/libpthread.so.0
#4 0x00007f8a3e7ebbad in clone () from /usr/lib64/libc.so.6
Thread 13 (Thread 0x7f8a3a2f4700 (LWP 20014)):
#0 0x00007f8a3ee2f995 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib64/libpthread.so.0
#1 0x00007f8a3fafd4af in dispatch (manager=0x7f8a41514eb0) at task.c:1103
#2 run (uap=0x7f8a41514eb0) at task.c:1331
#3 0x00007f8a3ee2be25 in start_thread () from /usr/lib64/libpthread.so.0
#4 0x00007f8a3e7ebbad in clone () from /usr/lib64/libc.so.6
Thread 12 (Thread 0x7f8a39af3700 (LWP 20015)):
#0 0x00007f8a3ee2f995 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib64/libpthread.so.0
#1 0x00007f8a3fafd4af in dispatch (manager=0x7f8a41514eb0) at task.c:1103
#2 run (uap=0x7f8a41514eb0) at task.c:1331
#3 0x00007f8a3ee2be25 in start_thread () from /usr/lib64/libpthread.so.0
#4 0x00007f8a3e7ebbad in clone () from /usr/lib64/libc.so.6
Thread 11 (Thread 0x7f8a392f2700 (LWP 20016)):
#0 0x00007f8a3ee2f995 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib64/libpthread.so.0
#1 0x00007f8a3fafcc33 in isc__task_beginexclusive (task0=<optimized out>) at task.c:1757
#2 0x000000000046850b in load_configuration ()
#3 0x000000000046c1d5 in loadconfig ()
#4 0x000000000046c42e in ns_server_reconfigcommand ()
#5 0x00000000004373bd in ns_control_docommand ()
#6 0x000000000043a483 in control_recvmessage ()
#7 0x00007f8a3fafd6bb in dispatch (manager=0x7f8a41514eb0) at task.c:1157
#8 run (uap=0x7f8a41514eb0) at task.c:1331
#9 0x00007f8a3ee2be25 in start_thread () from /usr/lib64/libpthread.so.0
#10 0x00007f8a3e7ebbad in clone () from /usr/lib64/libc.so.6
Thread 10 (Thread 0x7f8a38af1700 (LWP 20017)):
#0 0x00007f8a3ee2f995 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib64/libpthread.so.0
#1 0x00007f8a3fafd4af in dispatch (manager=0x7f8a41514eb0) at task.c:1103
#2 run (uap=0x7f8a41514eb0) at task.c:1331
#3 0x00007f8a3ee2be25 in start_thread () from /usr/lib64/libpthread.so.0
#4 0x00007f8a3e7ebbad in clone () from /usr/lib64/libc.so.6
Thread 9 (Thread 0x7f8a382f0700 (LWP 20018)):
#0 0x00007f8a3ee2f995 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib64/libpthread.so.0
#1 0x00007f8a3fafd4af in dispatch (manager=0x7f8a41514eb0) at task.c:1103
#2 run (uap=0x7f8a41514eb0) at task.c:1331
#3 0x00007f8a3ee2be25 in start_thread () from /usr/lib64/libpthread.so.0
#4 0x00007f8a3e7ebbad in clone () from /usr/lib64/libc.so.6
Thread 8 (Thread 0x7f8a37aef700 (LWP 20019)):
#0 0x00007f8a3ee3251d in __lll_lock_wait () from /usr/lib64/libpthread.so.0
#1 0x00007f8a3ee2de51 in _L_lock_1022 () from /usr/lib64/libpthread.so.0
#2 0x00007f8a3ee2ddf2 in pthread_mutex_lock () from /usr/lib64/libpthread.so.0
#3 0x00007f8a40e253ee in dns_resolver_shutdown (res=0x7f87d17a14b8) at resolver.c:9399
#4 0x00007f8a40e650c9 in view_flushanddetach (viewp=<optimized out>, flush=<optimized out>) at view.c:601
#5 0x000000000042e387 in exit_check ()
#6 0x0000000000443310 in prefetch_done ()
#7 0x00007f8a3fafd6bb in dispatch (manager=0x7f8a41514eb0) at task.c:1157
#8 run (uap=0x7f8a41514eb0) at task.c:1331
#9 0x00007f8a3ee2be25 in start_thread () from /usr/lib64/libpthread.so.0
#10 0x00007f8a3e7ebbad in clone () from /usr/lib64/libc.so.6
Thread 7 (Thread 0x7f8a372ee700 (LWP 20020)):
#0 0x00007f8a3ee2f995 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib64/libpthread.so.0
#1 0x00007f8a3fafd4af in dispatch (manager=0x7f8a41514eb0) at task.c:1103
#2 run (uap=0x7f8a41514eb0) at task.c:1331
#3 0x00007f8a3ee2be25 in start_thread () from /usr/lib64/libpthread.so.0
#4 0x00007f8a3e7ebbad in clone () from /usr/lib64/libc.so.6
Thread 6 (Thread 0x7f8a36aed700 (LWP 20021)):
#0 0x00007f8a3ee3251d in __lll_lock_wait () from /usr/lib64/libpthread.so.0
#1 0x00007f8a3ee2de51 in _L_lock_1022 () from /usr/lib64/libpthread.so.0
#2 0x00007f8a3ee2ddf2 in pthread_mutex_lock () from /usr/lib64/libpthread.so.0
#3 0x00007f8a40e20cd5 in empty_bucket (res=0x7f87d17a14b8) at resolver.c:8910
#4 0x00007f8a40d35d9a in fetch_callback (task=<optimized out>, ev=0x7f85a1732568) at adb.c:3868
#5 0x00007f8a3fafd6bb in dispatch (manager=0x7f8a41514eb0) at task.c:1157
#6 run (uap=0x7f8a41514eb0) at task.c:1331
#7 0x00007f8a3ee2be25 in start_thread () from /usr/lib64/libpthread.so.0
#8 0x00007f8a3e7ebbad in clone () from /usr/lib64/libc.so.6
Thread 5 (Thread 0x7f8a362ec700 (LWP 20022)):
#0 0x00007f8a3ee3251d in __lll_lock_wait () from /usr/lib64/libpthread.so.0
#1 0x00007f8a3ee2de51 in _L_lock_1022 () from /usr/lib64/libpthread.so.0
#2 0x00007f8a3ee2ddf2 in pthread_mutex_lock () from /usr/lib64/libpthread.so.0
#3 0x00007f8a40e62106 in dns_view_findzonecut2 (view=0x7f88f1f49240, name=name@entry=0x7f851fd3cd08, fname=fname@entry=0x7f8a362e9070, now=now@entry=0, options=0, use_hints=use_hints@entry=true, use_cache=use_cache@entry=true, rdataset=rdataset@entry=0x7f89103158e8, sigrdataset=sigrdataset@entry=0x0) at view.c:1295
#4 0x00007f8a40e625e8 in dns_view_findzonecut (view=<optimized out>, name=name@entry=0x7f851fd3cd08, fname=fname@entry=0x7f8a362e9070, now=now@entry=0, options=<optimized out>, use_hints=use_hints@entry=true, rdataset=rdataset@entry=0x7f89103158e8, sigrdataset=sigrdataset@entry=0x0) at view.c:1256
#5 0x00007f8a40e23b62 in fctx_create (res=res@entry=0x7f87d17a14b8, name=name@entry=0x7f851fd3cd08, type=type@entry=1, domain=0x7f8a362e9070, domain@entry=0x0, nameservers=nameservers@entry=0x0, client=client@entry=0x0, options=options@entry=32, bucketnum=bucketnum@entry=400, depth=depth@entry=2, qc=qc@entry=0xf7d4918, fctxp=fctxp@entry=0x7f8a362e9f98) at resolver.c:4454
#6 0x00007f8a40e25dd8 in dns_resolver_createfetch3 (res=<optimized out>, name=name@entry=0x7f851fd3cd08, type=type@entry=1, domain=domain@entry=0x0, nameservers=nameservers@entry=0x0, forwarders=forwarders@entry=0x0, client=client@entry=0x0, id=id@entry=0, options=options@entry=32, depth=depth@entry=2, qc=qc@entry=0xf7d4918, task=0x7f8930a85ae8, action=action@entry=0x7f8a40d35c90 <fetch_callback>, arg=arg@entry=0x7f851fd3cd00, rdataset=rdataset@entry=0x7f851fd39088, sigrdataset=sigrdataset@entry=0x0, fetchp=fetchp@entry=0x7f851fd39080) at resolver.c:9630
#7 0x00007f8a40d30269 in fetch_name (adbname=adbname@entry=0x7f851fd3cd00, start_at_zone=start_at_zone@entry=false, depth=depth@entry=2, qc=qc@entry=0xf7d4918, type=type@entry=1) at adb.c:4056
#8 0x00007f8a40d39dde in dns_adb_createfind2 (adb=0x7f851fd08aa0, task=0x7f89251db3f0, action=action@entry=0x7f8a40e2b4b0 <fctx_finddone>, arg=arg@entry=0x7f88eadec120, name=name@entry=0x7f8a362eadd0, qname=qname@entry=0x7f88eadec130, qtype=28, options=223, now=now@entry=1601867731, target=target@entry=0x0, port=53, depth=2, qc=0xf7d4918, findp=findp@entry=0x7f8a362ea8b8) at adb.c:3192
#9 0x00007f8a40e1f92d in findname (fctx=fctx@entry=0x7f88eadec120, name=name@entry=0x7f8a362eadd0, port=port@entry=0, options=<optimized out>, options@entry=31, flags=flags@entry=0, now=1601867731, overquota=overquota@entry=0x7f8a362ead70, need_alternate=need_alternate@entry=0x7f8a362ead57, no_addresses=no_addresses@entry=0x7f8a362ead5c) at resolver.c:3166
#10 0x00007f8a40e27ca2 in fctx_getaddresses (fctx=fctx@entry=0x7f88eadec120, badcache=badcache@entry=false) at resolver.c:3462
#11 0x00007f8a40e2a36a in fctx_try (fctx=0x7f88eadec120, retrying=<optimized out>, badcache=<optimized out>) at resolver.c:3819
#12 0x00007f8a40e2d994 in resquery_response (task=<optimized out>, event=<optimized out>) at resolver.c:8747
#13 0x00007f8a3fafd6bb in dispatch (manager=0x7f8a41514eb0) at task.c:1157
#14 run (uap=0x7f8a41514eb0) at task.c:1331
#15 0x00007f8a3ee2be25 in start_thread () from /usr/lib64/libpthread.so.0
#16 0x00007f8a3e7ebbad in clone () from /usr/lib64/libc.so.6
Thread 4 (Thread 0x7f8a35aeb700 (LWP 20023)):
#0 0x00007f8a3ee2f995 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib64/libpthread.so.0
#1 0x00007f8a3fafd4af in dispatch (manager=0x7f8a41514eb0) at task.c:1103
#2 run (uap=0x7f8a41514eb0) at task.c:1331
#3 0x00007f8a3ee2be25 in start_thread () from /usr/lib64/libpthread.so.0
#4 0x00007f8a3e7ebbad in clone () from /usr/lib64/libc.so.6
Thread 3 (Thread 0x7f8a352ea700 (LWP 20024)):
#0 0x00007f8a3ee2fd42 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /usr/lib64/libpthread.so.0
#1 0x00007f8a3fb1a3c8 in isc_condition_waituntil (c=c@entry=0x7f8a4151c078, m=m@entry=0x7f8a4151c028, t=t@entry=0x7f8a4151c06c) at condition.c:59
#2 0x00007f8a3fb036b3 in run (uap=0x7f8a4151c010) at timer.c:811
#3 0x00007f8a3ee2be25 in start_thread () from /usr/lib64/libpthread.so.0
#4 0x00007f8a3e7ebbad in clone () from /usr/lib64/libc.so.6
Thread 2 (Thread 0x7f8a34ae9700 (LWP 20025)):
#0 0x00007f8a3e7ec183 in epoll_wait () from /usr/lib64/libc.so.6
#1 0x00007f8a3fb112f6 in watcher (uap=0x7f8a4151e010) at socket.c:4302
#2 0x00007f8a3ee2be25 in start_thread () from /usr/lib64/libpthread.so.0
#3 0x00007f8a3e7ebbad in clone () from /usr/lib64/libc.so.6
Thread 1 (Thread 0x7f8a41555840 (LWP 20007)):
#0 0x00007f8a3e7235f2 in sigsuspend () from /usr/lib64/libc.so.6
#1 0x00007f8a3fb04f00 in isc__app_ctxrun (ctx0=ctx0@entry=0x7f8a3fd38dc0 <isc_g_appctx>) at app.c:723
#2 0x00007f8a3fb0515c in isc__app_run () at app.c:756
#3 0x00007f8a3fb05a30 in isc_app_run () at ../app_api.c:207
#4 0x000000000042a905 in main ()
```
### Possible fixes
(If you can, link to the line of code that might be responsible for the
problem.)https://gitlab.isc.org/isc-projects/bind9/-/issues/2209TSAN error bin/named/controlconf.c related.2023-11-23T08:14:30ZMark AndrewsTSAN error bin/named/controlconf.c related.Job [#1213042](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1213042) failed for ced5041de73f16dbadf1acacbf8c20659efcb6a6:
```
WARNING: ThreadSanitizer: data race
Write of size 8 at 0x000000000001 by thread T1:
#0 isc_nmhandle...Job [#1213042](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1213042) failed for ced5041de73f16dbadf1acacbf8c20659efcb6a6:
```
WARNING: ThreadSanitizer: data race
Write of size 8 at 0x000000000001 by thread T1:
#0 isc_nmhandle_detach lib/isc/netmgr/netmgr.c:1258:15
#1 control_command bin/named/controlconf.c:388:3
#2 dispatch lib/isc/task.c:1152:7
#3 run lib/isc/task.c:1344:2
Previous read of size 8 at 0x000000000001 by thread T2:
#0 isc_nm_pauseread lib/isc/netmgr/netmgr.c:1449:33
#1 recv_data lib/isccc/ccmsg.c:109:2
#2 isc__nm_tcp_shutdown lib/isc/netmgr/tcp.c:1157:4
#3 shutdown_walk_cb lib/isc/netmgr/netmgr.c:1515:3
#4 uv_walk <null>
#5 process_queue lib/isc/netmgr/netmgr.c:659:4
#6 process_normal_queue lib/isc/netmgr/netmgr.c:582:10
#7 process_queues lib/isc/netmgr/netmgr.c:590:8
#8 async_cb lib/isc/netmgr/netmgr.c:548:2
#9 <null> <null>
Location is heap block of size 569 at 0x000000000016 allocated by thread T2:
#0 malloc <null>
#1 default_memalloc lib/isc/mem.c:713:8
#2 mem_get lib/isc/mem.c:622:8
#3 isc___mem_get lib/isc/mem.c:1044:9
#4 isc__mem_get lib/isc/mem.c:2432:10
#5 alloc_handle lib/isc/netmgr/netmgr.c:1076:3
#6 isc__nmhandle_get lib/isc/netmgr/netmgr.c:1100:12
#7 isc__nm_async_tcpchildaccept lib/isc/netmgr/tcp.c:486:11
#8 process_queue lib/isc/netmgr/netmgr.c:624:4
#9 process_normal_queue lib/isc/netmgr/netmgr.c:582:10
#10 process_queues lib/isc/netmgr/netmgr.c:590:8
#11 async_cb lib/isc/netmgr/netmgr.c:548:2
#12 <null> <null>
Thread T1 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create lib/isc/pthreads/thread.c:73:8
#2 isc_taskmgr_create lib/isc/task.c:1434:3
#3 create_managers bin/named/main.c:915:11
#4 setup bin/named/main.c:1223:11
#5 main bin/named/main.c:1523:2
Thread T2 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create lib/isc/pthreads/thread.c:73:8
#2 isc_nm_start lib/isc/netmgr/netmgr.c:232:3
#3 create_managers bin/named/main.c:909:15
#4 setup bin/named/main.c:1223:11
#5 main bin/named/main.c:1523:2
SUMMARY: ThreadSanitizer: data race lib/isc/netmgr/netmgr.c:1258:15 in isc_nmhandle_detach
```November 2020 (9.11.25, 9.11.25-S1, 9.16.9, 9.16.9-S1, 9.17.7)https://gitlab.isc.org/isc-projects/bind9/-/issues/2208TCP4RECVERR counter mis-counting on 9.16+?2020-10-30T11:07:28ZMichael McNallyTCP4RECVERR counter mis-counting on 9.16+?Via (Support Ticket #17204](https://support.isc.org/Ticket/Display.html?id=17204), Dave F. tells us of a problem with the TCP4RECVERR counter that sounds as though we are probably mis-counting in releases that use the new netmgr.
> We'r...Via (Support Ticket #17204](https://support.isc.org/Ticket/Display.html?id=17204), Dave F. tells us of a problem with the TCP4RECVERR counter that sounds as though we are probably mis-counting in releases that use the new netmgr.
> We're attempting upgrade from 9.14.12 to 9.16.[5,6,7]. Upon upgrade we started getting internal alarms firing because the Bind internal stat TCP4RecvErr increases on every DNS TCP query we send. The DNS queries get valid DNS responses, so if we hadn't been alarming on the stat we never would have noticed an immediate issue.
>
> ...
>
> We saw this problem on 9.16.5 and then repro'd it on .6 and .7.
>
>
> To help with the debug, I am including some stat blocks.
>
> This is the initial state of the stats before we issue the queries:
```
{
"json-stats-version":"1.5",
"boot-time":"2020-10-08T19:44:32.194Z",
"config-time":"2020-10-08T20:47:37.818Z",
"current-time":"2020-10-08T20:55:05.270Z",
"version":"9.16.7",
"sockstats":{
"UDP4Open":2,
"TCP4Open":3,
"RawOpen":1,
"TCP4Close":243,
"TCP4Accept":244,
"TCP4RecvErr":88,
"UDP4Active":3,
"TCP4Active":4,
"RawActive":1
},
```
> We then run two TCP queries using the same version of dig 9.16.7 built with this version of bind under test.
```
bash-4.2$ dig @127.0.0.1 localhost a +tcp
; <<>> DiG 9.16.7 <<>> @127.0.0.1 localhost a +tcp
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 4021
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: ba9ced48a62b6061010000005f7f7cc12056d6b3fad00a0c (good)
;; QUESTION SECTION:
;localhost. IN A
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Oct 08 20:55:29 UTC 2020
;; MSG SIZE rcvd: 66
bash-4.2$ dig @127.0.0.1 <redacted> TXT +tcp
; <<>> DiG 9.16.7 <<>> @127.0.0.1 <redacted> TXT +tcp
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28547
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: bca3ab06023e0f15010000005f7f7cc7c9512f87cfdff056 (good)
;; QUESTION SECTION:
;<redacted>. IN TXT
;; ANSWER SECTION:
<redacted>. 3600 IN TXT "OK"
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Oct 08 20:55:35 UTC 2020
;; MSG SIZE rcvd: 101
```
> Note that we have a REFUSED response and an NOERROR response, but both valid DNS responses with no sign of TCP error.
>
> After running these queries the stat block looks like:
```
bash-4.2$ curl http://localhost:8053/json/v1/net
{
"json-stats-version":"1.5",
"boot-time":"2020-10-08T19:44:32.194Z",
"config-time":"2020-10-08T20:47:37.818Z",
"current-time":"2020-10-08T20:55:37.681Z",
"version":"9.16.7",
"sockstats":{
"UDP4Open":2,
"TCP4Open":3,
"RawOpen":1,
"TCP4Close":246,
"TCP4Accept":247,
"TCP4RecvErr":90,
"UDP4Active":3,
"TCP4Active":4,
"RawActive":1
},
```
> Note that TCP4RecvErr has increased by 2, corresponding to the 2 queries. This is the concern.
>
> TCP4Close and TCP4Accept both increase by 3 from the baseline due to the 2 queries plus the curl request to obtain the stats. This seems to be normal.
>
> Please let me know if I can provide any more information.
> We'd like to understand if this is a known issue and if there are any other concerns (memory leak, socket leak, performance issue) associated with the error.November 2020 (9.11.25, 9.11.25-S1, 9.16.9, 9.16.9-S1, 9.17.7)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/1462Simplify diffing & merging of message & parser generated files through .gitat...2020-12-11T17:26:16ZAndrei Pavelandrei@isc.orgSimplify diffing & merging of message & parser generated files through .gitattributesThere was some interest in this on mattermost so it's worth creating an issue.
Generated messages & generated parser files are meaningless to inspect. Their source files are easier to read. So there are two things we can do with git att...There was some interest in this on mattermost so it's worth creating an issue.
Generated messages & generated parser files are meaningless to inspect. Their source files are easier to read. So there are two things we can do with git attributes.:
* Not clutter entire screens with differences of generated files when diff-ing branches or commits or so on. This can be done via the `diff=nodiff` attribute.
* Temporarily trick git into solving these spurious conflicts on generated files since a regeneration has to happen anyway. This can be done via `merge=ours` or `merge=theirs` attributes. Almost certainly both are wrong, but there's no magical `merge=$(make messages && make parsers)` so they would have to do. Advantage of `merge=ours`: zero diff, but you will probably have other conflicts and that means other modified files so it let's you focus on them. Advantage of `merge=theirs`: some diff which will tell you nothing more than what files need regenerating.
Git attributes are assigned per file or directory. Since we have generated message & parser files in open directories with other source code files, our attributes would work directly associated with the generated files.kea1.9.3Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.org