ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2019-04-10T11:35:45Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/431Write a script that cleans up config backend DB2019-04-10T11:35:45ZTomek MrugalskiWrite a script that cleans up config backend DB@marcin and @tomek discussed a concept of wiping database. This may address several issues:
- system tests need to discard all data from a DB after a CB test.
- after schema was extended, every unit-test creates and then tears down the ...@marcin and @tomek discussed a concept of wiping database. This may address several issues:
- system tests need to discard all data from a DB after a CB test.
- after schema was extended, every unit-test creates and then tears down the schema. With many (around 40) tables, this is very slow process. We should have an option (possibly even enabled by default) to wipe data from the tables rather then tear them down and recreate every time. (TRUNCATE TABLE is supposedly faster than DELETE FROM, but has some constraints and can't be used everywhere).Kea1.6https://gitlab.isc.org/isc-projects/kea/-/issues/389script for creating mysql database fails on Debian 9 using MariaDB 10.12019-02-01T06:08:41ZMichal Nowikowskiscript for creating mysql database fails on Debian 9 using MariaDB 10.1After preparing mysql and running:
```bash
$ mysql -N -B --user=keatest --password=keatest keatest < /home/vagrant/kea-src/kea-1.5.0/src/share/database/scripts/mysql/dhcpdb_create.mysql
```
I get the following error:
```
ERROR 1071 (42...After preparing mysql and running:
```bash
$ mysql -N -B --user=keatest --password=keatest keatest < /home/vagrant/kea-src/kea-1.5.0/src/share/database/scripts/mysql/dhcpdb_create.mysql
```
I get the following error:
```
ERROR 1071 (42000) at line 805: Specified key was too long; max key length is 767 bytes
```
Database: Server version: 10.1.37-MariaDB-0+deb9u1 Debian 9.6
System: Debian 9Kea1.6Vicky Riskvicky@isc.orgVicky Riskvicky@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/374KB doc links need to be updated after 1.5 release2019-01-11T16:33:40ZTomek MrugalskiKB doc links need to be updated after 1.5 releaseThis page https://kb.isc.org/docs/kea-administrator-reference-manual should be extended to link to 1.5 docs.This page https://kb.isc.org/docs/kea-administrator-reference-manual should be extended to link to 1.5 docs.Kea1.6https://gitlab.isc.org/isc-projects/kea/-/issues/363#13966: DHCP Option start sequence2019-03-11T12:50:56ZVicky Riskvicky@isc.org#13966: DHCP Option start sequenceSome clients require Option 53 first and don't accept options presented in numerical order the way they are in Kea 1.5.0. ISC DHCP sends option 53 first and so this has become an established, although non-standard, expectation.
After di...Some clients require Option 53 first and don't accept options presented in numerical order the way they are in Kea 1.5.0. ISC DHCP sends option 53 first and so this has become an established, although non-standard, expectation.
After discussion in the Kea support meeting, everyone thinks we should just change the default behavior in the base Kea code to support this (non-standard) client requirement. Thomas has written a patch for this (below) which was shared with the support customer requesting this. We should review, merge and test this and include the change in the next Kea release.
----------
diff --git a/src/lib/dhcp/libdhcp++.cc b/src/lib/dhcp/libdhcp++.cc
index ced705dd29..a9f956eda8 100644
--- a/src/lib/dhcp/libdhcp++.cc
+++ b/src/lib/dhcp/libdhcp++.cc
@@ -790,11 +790,19 @@ LibDHCP::packOptions4(isc::util::OutputBuffer& buf,
const OptionCollection& options) {
OptionPtr agent;
OptionPtr end;
+
+ auto x = options.find(DHO_DHCP_MESSAGE_TYPE);
+ if (x != options.end()) {
+ x->second->pack(buf);
+ }
+
for (OptionCollection::const_iterator it = options.begin();
it != options.end(); ++it) {
- // RAI and END options must be last.
+ // TYPE is already done, RAI and END options must be last.
switch (it->first) {
+ case DHO_DHCP_MESSAGE_TYPE:
+ break;
case DHO_DHCP_AGENT_OPTIONS:
agent = it->second;
break;Kea1.6Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/320kea-admin, keactrl doesn't report Kea version (trac5411) (GH #76)2019-01-17T14:54:03ZVicky Riskvicky@isc.orgkea-admin, keactrl doesn't report Kea version (trac5411) (GH #76)<Migrated from Gitlab issue #76, originally opened by Tomaszmrugalski on April 19, 2018>
Those two tools don't report their version as other components do (neither -v or -V is working).
For details, see https://kea.isc.org/ticket/5411.<Migrated from Gitlab issue #76, originally opened by Tomaszmrugalski on April 19, 2018>
Those two tools don't report their version as other components do (neither -v or -V is working).
For details, see https://kea.isc.org/ticket/5411.Kea1.6https://gitlab.isc.org/isc-projects/kea/-/issues/319kea-admin / admin-utils.sh ignores the -h --host arg for the database (GH#104)2019-01-17T14:54:51ZVicky Riskvicky@isc.orgkea-admin / admin-utils.sh ignores the -h --host arg for the database (GH#104)<This issue was opened on Github as issue #104 by Kroki0815 on Sept 20, 2018>
If the mysql-database is not on localhost, upgrade of the database with kea-admin is not possible.
i looked into the code and the problem is in the admin-uti...<This issue was opened on Github as issue #104 by Kroki0815 on Sept 20, 2018>
If the mysql-database is not on localhost, upgrade of the database with kea-admin is not possible.
i looked into the code and the problem is in the admin-utils.sh:
```
mysql_execute() {
QUERY=$1
shift
if [ $# -gt 1 ]; then
mysql -N -B "$@" -e "${QUERY}"
retcode=$?
else
mysql -N -B --database="${db_name}" --user="${db_user}" --password="${db_password}" -e "${QUERY}"
retcode=$?
fi
return $retcode
}
mysql_execute_script() {
file=$1
shift
if [ $# -ge 1 ]; then
mysql -N -B "$@" < "${file}"
retcode=$?
else
mysql -N -B --database="${db_name}" --user="${db_user}" --password="${db_password}" < "${file}"
retcode=$?
fi
return $retcode
}
```
The mysql lines should look like this:
```
mysql -N -B --host="${db_host}" --database="${db_name}" --user="${db_user}" --password="${db_password}"
```
This problem may be also in the other backends.
This bug is in all versions, also in the master-branch.Kea1.6https://gitlab.isc.org/isc-projects/kea/-/issues/184Performance testing with kea less than ISC2019-02-07T21:00:01ZGhost UserPerformance testing with kea less than ISCHi,
I was trying to do the bench marking between ISC dhcp and Kea for POC
Since kea HA will have two IP, how can i test perfdhcp with multiple DHCP server ip
```
perfdhcp -b mac=dd:55:33:00:dd:00 -4 10.25.133.12
perfdhcp -M smac -4...Hi,
I was trying to do the bench marking between ISC dhcp and Kea for POC
Since kea HA will have two IP, how can i test perfdhcp with multiple DHCP server ip
```
perfdhcp -b mac=dd:55:33:00:dd:00 -4 10.25.133.12
perfdhcp -M smac -4 10.25.133.12
```
Is it possible to test with both servers ?Kea1.6https://gitlab.isc.org/isc-projects/kea/-/issues/146Documentation misses required packages for sysrepo installation2019-01-17T15:12:55ZStephen MorrisDocumentation misses required packages for sysrepo installationThe installation instructions for libyang and sysrepo (in doc/guide/netconf.xml) are preceded by a list of prerequisite packages. That list appears to be OK for libyang but I found that I needed to install a further two: `libev-dev` and...The installation instructions for libyang and sysrepo (in doc/guide/netconf.xml) are preceded by a list of prerequisite packages. That list appears to be OK for libyang but I found that I needed to install a further two: `libev-dev` and `swig` in order to build sysrepo on an Ubuntu 18.04 system. The list of packages should be updated.
Also, the list of packages is too long for one line (unless the browser is full screen): it should be split across two lines.Kea1.6Stephen MorrisStephen Morrishttps://gitlab.isc.org/isc-projects/kea/-/issues/124Implement system tests for the configuration backend2019-01-11T16:38:19ZStephen MorrisImplement system tests for the configuration backendAs described in the test plan for the configuration backend.As described in the test plan for the configuration backend.Kea1.6https://gitlab.isc.org/isc-projects/kea/-/issues/123Write configuration backend test plan2019-12-03T13:59:18ZStephen MorrisWrite configuration backend test planWrite a test plan for the configuration backend code. This should be placed in the wiki.Write a test plan for the configuration backend code. This should be placed in the wiki.Kea1.6https://gitlab.isc.org/isc-projects/bind9/-/issues/1082Detecting conflicts between static and initializing keys is unreliable2019-06-11T01:56:57ZMichał KępieńDetecting conflicts between static and initializing keys is unreliableThe code checking for both static keys and initializing keys being configured for the same domain is unreliable because it [calls][1] `isc_symtab_define()` with the `key` parameter pointing to a stack-allocated variable. Meanwhile, symt...The code checking for both static keys and initializing keys being configured for the same domain is unreliable because it [calls][1] `isc_symtab_define()` with the `key` parameter pointing to a stack-allocated variable. Meanwhile, symtab docs [say][2]:
> The symbol table library does not make a copy the key field, so the
> caller must ensure that any key it passes to isc_symtab_define() will not
> change until it calls isc_symtab_undefine() or isc_symtab_destroy().
This issue manifests itself e.g. by `named-checkconf` [failing to raise a configuration error][3] for at least some configurations which intentionally contain both static and initializing keys for the same domain (e.g. `bin/tests/system/checkconf/bad-duplicate-key.conf`). If the `namebuf` local variable in `record_static_keys()` has a close, but not identical address as the `namebuf` local variable in `check_initializing_keys()`, lookups for previously defined symtab entries will fail when they should succeed - but this is just one possible failure mode.
The solution here is to ensure what the docs ask the developer to ensure (e.g. use `isc_mem_strdup()` for the keys passed to `isc_symtab_define()` and then clean the copies up properly when `isc_mem_destroy()` is called).
[1]: https://gitlab.isc.org/isc-projects/bind9/blob/90ff5a551aa6ba4340ae45f6ff3a97b3141d8b5c/lib/bind9/check.c#L3288-3289
[2]: https://gitlab.isc.org/isc-projects/bind9/blob/90ff5a551aa6ba4340ae45f6ff3a97b3141d8b5c/lib/isc/include/isc/symtab.h#L45-47
[3]: https://jenkins.isc.org/job/bind9-test-release-tarball/label=fedora-32-latest/22/testReport/junit/bind/system/checkconf/BIND 9.15.1https://gitlab.isc.org/isc-projects/bind9/-/issues/1064Adding --enable-pthread-rwlock broke Windows build2019-06-05T18:29:42ZMichał KępieńAdding --enable-pthread-rwlock broke Windows build!1397 broke the Windows build:
https://jenkins.isc.org/view/BIND_Parameterized/job/bind9-parameterized-win2012-x64/306/console
(Here is a build of the same commit as above, but with !1397 reverted: https://jenkins.isc.org/view/BIND_Par...!1397 broke the Windows build:
https://jenkins.isc.org/view/BIND_Parameterized/job/bind9-parameterized-win2012-x64/306/console
(Here is a build of the same commit as above, but with !1397 reverted: https://jenkins.isc.org/view/BIND_Parameterized/job/bind9-parameterized-win2012-x64/307/console)
This needs to be fixed before 9.15.1 is tagged (i.e. within the next week).BIND 9.15.1Witold KrecickiWitold Krecickihttps://gitlab.isc.org/isc-projects/bind9/-/issues/1044gen fails to generate headers on Debian buster2019-05-29T11:34:39ZOndřej Surýgen fails to generate headers on Debian buster`./gen` utility fails to go through all the files it should generating almost empty header files because it's missing the defines from `config.h`.`./gen` utility fails to go through all the files it should generating almost empty header files because it's missing the defines from `config.h`.BIND 9.15.1Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1073Release Checklist for 9.15.12019-06-24T17:08:22ZStephen MorrisRelease Checklist for 9.15.1## Release Checklist for 9.15.1
- [x] (Manager) Check for the presence of a milestone for the release:
- If there is a milestone, are all the issues for the milestone resolved? (other than this checklist).
- [x] (Manager) Inform S...## Release Checklist for 9.15.1
- [x] (Manager) Check for the presence of a milestone for the release:
- If there is a milestone, are all the issues for the milestone resolved? (other than this checklist).
- [x] (Manager) Inform Support/Marketing of impending release (and give estimated release dates).
- (SwEng) Prepare the sources for tarball generation:
- [x] Check perflab to ensure there has been no unexplained drop in performance for the version being released.
- [x] Ensure that there are no outstanding merge requests in the private repository (subscription version only).
- [x] Update API files for libraries with new version information.
- [x] Change software version and library versions in configure.in (new major release only).
- [x] Rebuild configure using autoconf on docs.isc.org.
- [x] Update CHANGES.
- [x] Update "version".
- [x] Update "readme.md".
- Check the release notes are correct:
- [x] Compare content with merge requests for the release.
- [x] Check formatting.
- [x] Build documentation on docs.isc.org.
- [x] Commit changes and make sure the gitlab-ci tests are passing.
- [x] Push the changes and tag ("alphatag" is an optional string such as "b1", "rc1" etc.). (```git tag -u <DEVELOPER_KEYID> -a -s -m "BIND 9.X.Y[alphatag]" v9_X_Y[alphatag]```)
- [x] If this is the first tag for a release (e.g. beta), create a release branch named `release_v9_X_Y` (this allows development to continue on the release branch whilst release engineering continues).
- [x] (SwEng) Run the "make release" Jenkins job to produce the tarballs and zips.
- [x] (SwEng) Ask QA to sanity check the tarball and zips (passing to them the number of the Jenkins job).
- [x] (QA) Sanity check the tarballs.
- [x] (QA) Request the signature on the tarballs.
- [x] (QA) Check signatures on tarballs.
- [x] (QA) Tell Support to handle notification of release.
- [x] (Manager) Inform Marketing of the release
- [x] (Manager) Update the internal [BIND release dates wiki page](https://wiki.isc.org/bin/view/Main/BindReleaseDates) when public announcement has been made.
- [x] (SwEng) Update DEB and RPM packages
- [x] (SwEng) Merge the automatically prepared `prep 9.X.Y` commit which updates `version` and documentation on the release branch into the relevant maintenance branch (`v9_X`)
## Support
- [x] Make tarballs and signatures available to download.
- [x] Write release email to bind9-announce.
- [x] Write email to bind9-users (if a major release).
- [x] Update tickets in case of waiting support customers.
## Marketing
- [x] Post short note to Twitter.
- [x] Update [Wikipedia entry for BIND](http://en.wikipedia.org/wiki/BIND).
- [x] Write blog article (if a major release).BIND 9.15.1Michael McNallyMichael McNallyhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1054Release Checklist for 9.11.8, 9.12.4-P2, 9.14.3, 9.11.8-S12019-06-24T17:08:18ZStephen MorrisRelease Checklist for 9.11.8, 9.12.4-P2, 9.14.3, 9.11.8-S1## Release Checklist
- [x] (Manager) Check for the presence of a milestone for the release:
- If there is a milestone, are all the issues for the milestone resolved? (other than this checklist).
- [x] (Manager) Inform Support/Mark...## Release Checklist
- [x] (Manager) Check for the presence of a milestone for the release:
- If there is a milestone, are all the issues for the milestone resolved? (other than this checklist).
- [x] (Manager) Inform Support/Marketing of impending release (and give estimated release dates).
- (SwEng) Prepare the sources for tarball generation:
- [x] Check perflab to ensure there has been no unexplained drop in performance for the version being released.
- [x] Ensure that there are no outstanding merge requests in the private repository (subscription version only).
- [x] Update API files for libraries with new version information.
- [x] Change software version and library versions in configure.in (new major release only).
- [x] Rebuild configure using autoconf on docs.isc.org.
- [x] Update CHANGES.
- [x] Update CHANGES.SE (subscription branch only).
- [x] Update "version".
- [x] Update "readme.md".
- Check the release notes are correct:
- [x] Compare content with merge requests for the release.
- [x] Check formatting.
- [x] Build documentation on docs.isc.org.
- [x] Commit changes and make sure the gitlab-ci tests are passing.
- [x] Push the changes and tag ("alphatag" is an optional string such as "b1", "rc1" etc.). (```git tag -u <DEVELOPER_KEYID> -a -s -m "BIND 9.X.Y[alphatag]" v9_X_Y[alphatag]```)
- [x] If this is the first tag for a release (e.g. beta), create a release branch named `release_v9_X_Y` (this allows development to continue on the release branch whilst release engineering continues).
- [x] (QA) Run the "make release" Jenkins job to produce the tarballs and zips.
- [x] (QA) Sanity check the tarball and zips.
- [x] (QA) Sanity check the tarballs.
- [x] (QA) Request the signature on the tarballs.
- [x] (QA) Check signatures on tarballs.
- [x] (QA) Tell Support to handle notification of release.
- [x] (Manager) Inform Marketing of the release
- [x] (Manager) Update the internal [BIND release dates wiki page](https://wiki.isc.org/bin/view/Main/BindReleaseDates) when public announcement has been made.
- [x] (SwEng) Update DEB and RPM packages
- [x] (SwEng) Merge the automatically prepared `prep 9.X.Y` commit which updates `version` and documentation on the release branch into the relevant maintenance branch (`v9_X`)
## Support
- [x] Make tarballs and signatures available to download.
- [x] Write release email to bind9-announce.
- [x] Write email to bind9-users (if a major release).
- [x] Update tickets in case of waiting support customers.
## Marketing
- [x] Post short note to Twitter.
- [x] Update [Wikipedia entry for BIND](http://en.wikipedia.org/wiki/BIND).
- [x] Write blog article (if a major release).BIND 9.14.3Michael McNallyMichael McNallyhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1028dig +trace should not set RD=0 (+norecurse) for the initial root hints query2019-05-22T03:13:20ZTore Andersondig +trace should not set RD=0 (+norecurse) for the initial root hints queryWhen running, e.g., `dig +trace gitlab.isc.org`, recursion is automatically disabled. This is documented in the manual page:
```
+[no]recurse
Toggle the setting of the RD (recursion desired) bit in the query.
...When running, e.g., `dig +trace gitlab.isc.org`, recursion is automatically disabled. This is documented in the manual page:
```
+[no]recurse
Toggle the setting of the RD (recursion desired) bit in the query.
This bit is set by default, which means dig normally sends
recursive queries. Recursion is automatically disabled when the
+nssearch or +trace query options are used.
```
This makes perfect sense, *except* for the initial query for the NS records of the `.` root zone.
Setting `RD=0` in the initial `IN NS .` query prevents `dig +trace` from functioning correctly when the configured upstream nameserver of the system (e.g., the `nameserver` line(s) found in `/etc/resolv.conf` on Linux systems) is a DNS forwarder/proxy - because it will refuse to answer the query.
This example shows this happening on a modern Linux system (Fedora 30) using the `systemd-resolved` DNS forwarder:
```console
$ ./dig +trace gitlab.isc.org.
; <<>> DiG 9.15.0 <<>> +trace gitlab.isc.org.
;; global options: +cmd
;; Received 51 bytes from 127.0.0.53#53(127.0.0.53) in 0 ms
$ ./dig . IN NS +norecurse
; <<>> DiG 9.15.0 <<>> . IN NS +norecurse
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 35753
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;. IN NS
;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: må. mai 13 20:56:57 CEST 2019
;; MSG SIZE rcvd: 28
```
When querying for the root hints with `RD=1`, the desired answer is given:
```console
$ ./dig . IN NS +recurse
; <<>> DiG 9.15.0 <<>> . IN NS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49484
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;. IN NS
;; ANSWER SECTION:
. 81613 IN NS b.root-servers.net.
. 81613 IN NS d.root-servers.net.
. 81613 IN NS f.root-servers.net.
. 81613 IN NS a.root-servers.net.
. 81613 IN NS k.root-servers.net.
. 81613 IN NS c.root-servers.net.
. 81613 IN NS j.root-servers.net.
. 81613 IN NS i.root-servers.net.
. 81613 IN NS m.root-servers.net.
. 81613 IN NS l.root-servers.net.
. 81613 IN NS h.root-servers.net.
. 81613 IN NS g.root-servers.net.
. 81613 IN NS e.root-servers.net.
;; Query time: 138 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: må. mai 13 20:57:00 CEST 2019
;; MSG SIZE rcvd: 239
```
As I understand it, the DNS forwarder correctly implements the DNS protocol when it answers this query with `REFUSED`.
This understanding is based on the following specification from [RFC 8499](https://tools.ietf.org/html/rfc8499):
```
Non-recursive query: A query with the Recursion Desired (RD) bit set
to 0 in the header. A server can answer non-recursive queries
using only local information: the response contains either an
error, the answer, or a referral to some other server "closer" to
the answer. (See Section 4.3.1 of [RFC1034].)
```
Since the forwarder does not contain a built-in root hints zone file, it simply cannot *«answer [dig +trace's] no-recursive queries using only local information»*; thus answering with a `REFUSED` error is the only real option: it does not have the answer, nor would it be possible to give a *«a referral to some other server "closer" to the answer»* (at least I cannot imagine how such a referral would look like).
I therefore propose that the `dig` tool delays setting `+norecurse`/`RD=0` until the *second* query, i.e., *after* the root hints have been obtained.BIND 9.15.1https://gitlab.isc.org/isc-projects/bind9/-/issues/1023Make lib/isc/<platform>/app.c TSAN clean2019-05-20T17:00:21ZOndřej SurýMake lib/isc/<platform>/app.c TSAN cleanThreadSanitizer reports couple of problems in `app.c`, let's clean and refactor the file.ThreadSanitizer reports couple of problems in `app.c`, let's clean and refactor the file.BIND 9.15.1Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1011Use proper linker (config) on HP-UX2019-05-30T00:30:01ZMichael OsipovUse proper linker (config) on HP-UXIn `configure.ac` the config is still tuned for HP-UX on PA-RISC which is dead for many many years. Attached you'll find a patch to properly link with HP-UX on IA64:
* Shared libs on IA64 are -- by default -- `.so`
* The default way to ...In `configure.ac` the config is still tuned for HP-UX on PA-RISC which is dead for many many years. Attached you'll find a patch to properly link with HP-UX on IA64:
* Shared libs on IA64 are -- by default -- `.so`
* The default way to link is to use the compiler -- as advised by HPE support
The patch has been produced against 9.11.6.[bind9.patch](/uploads/f70f00ceed7144c57f14653147c3b9b0/bind9.patch)BIND 9.15.1Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/942BIND 9.12.3-P4 crash at dispatch.c:3426: REQUIRE(resp->item_out == 1)2019-06-19T21:56:10ZVeroniqueBIND 9.12.3-P4 crash at dispatch.c:3426: REQUIRE(resp->item_out == 1)```
dispatch.c:3426: REQUIRE(resp->item_out == 1) failed, back trace
#0 0x426970 in assertion_failed()+0x60
#1 0x61279a in isc_assertion_failed()+0xa
#2 0x4a5862 in dns_dispatch_getnext()+0x352
#3 0x57292a in rctx_done()+0x17a
#4 0x572db...```
dispatch.c:3426: REQUIRE(resp->item_out == 1) failed, back trace
#0 0x426970 in assertion_failed()+0x60
#1 0x61279a in isc_assertion_failed()+0xa
#2 0x4a5862 in dns_dispatch_getnext()+0x352
#3 0x57292a in rctx_done()+0x17a
#4 0x572db4 in resquery_response()+0x204
#5 0x63606b in run()+0x2bb
#6 0x7f8458968e25 in __do_global_dtors_aux_fini_array_entry()+0x7f8458063c95
#7 0x7f8458692bad in __do_global_dtors_aux_fini_array_entry()+0x7f8457d8da1d
exiting (due to assertion failure)
```
Please tell me if you need more info. This is running on Centos7, with dnssec-validation = auto.
Thanks.BIND 9.15.1Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/999Cannot build BIND 9.11.6-P1 on Solaris 11.3 / sparc with Developer Studio 12....2019-05-10T13:47:38ZGhost UserCannot build BIND 9.11.6-P1 on Solaris 11.3 / sparc with Developer Studio 12.5 compiler### Summary
Cannot build BIND 9.11.6-P1 on Oracle Solaris 11.3 on sparc architecture with Developer Studio 12.5 compiler.
### BIND version used
9.11.6-P1
### Steps to reproduce
Tried on Oracle Solaris 11.3 on sparc architecture with...### Summary
Cannot build BIND 9.11.6-P1 on Oracle Solaris 11.3 on sparc architecture with Developer Studio 12.5 compiler.
### BIND version used
9.11.6-P1
### Steps to reproduce
Tried on Oracle Solaris 11.3 on sparc architecture with Developer Studio 12.5 compiler.
- export PATH=/usr/bin:/opt/developerstudio12.5/bin
- ./configure --without-gssapi CC=/opt/developerstudio12.5/bin/cc CFLAGS='-xtarget=native -m64 -O' CXX=/opt/developerstudio12.5/bin/CC CXXFLAGS='-xtarget=native -m64 -O'
- make
### What is the current *bug* behavior?
The build was failed on link phase with the following error.
```
Undefined first referenced
symbol in file
isc_atomic_xadd client.o
ld: fatal: symbol referencing errors
*** Error code 1
make: Fatal error: Command failed for target `named'
Current working directory /var/share/tmp/bind-9.11.6-P1/bin/named
*** Error code 1
```
It seems BIND 9.11.6-P1 introduce new requirement "atomic".
BIND 9.11.6 was able to build on the same environment successfully.
Developer Studio 12.5 compiler has stdatomic but BIND configure rejects this stdatomic because ATOMIC_INT_LOCK_FREE is defined as "1" on /opt/developerstudio12.5/lib/compilers/include/cc/stdatomic.h file.
The configure said that:
```
checking for usable stdatomic.h... no
checking architecture type for atomic operations... noatomic
```
On x86_64 architecture, the configure said that:
```
checking for usable stdatomic.h... no
checking size of void *... 8
checking architecture type for atomic operations... x86_64
```
### What is the expected *correct* behavior?
build successfully
### Relevant configuration files
```
$ uname -psvri
SunOS 5.11 11.3 sparc sun4v
$ cc -V
cc: Studio 12.5 Sun C 5.14 SunOS_sparc 2016/05/31
```
### Relevant logs and/or screenshots
Attached config.log file.[config.log](/uploads/58d3d7c79bb3ab309013084c47eecfc2/config.log)BIND 9.11.7