Bind 9.16.6 + dyndb-ldap 11.4 crashes on startup with name.c:2515: REQUIRE(target != ((void *)0)) failed, back trace
name.c:2515: REQUIRE(target != ((void *)0)) failed, back trace
Identical config and LDAP contents were working with bind 9.11.2_p1 and dyndb-ldap 11.1.
No, I have multiple views configured to separate LDAP containers, one of which is empty (contains no idnsZone objects), and presence of any of them in the config file causes the crash
idnsZone
Journal logs:
Sep 20 16:36:42 santo named[129444]: none:99: 'max-cache-size 90%' - setting to 3524MB (out of 3916MB) Sep 20 16:36:42 santo named[129444]: configuring command channel from '/etc/bind/rndc.key' Sep 20 16:36:42 santo named[129444]: command channel listening on 127.0.0.1#953 Sep 20 16:36:42 santo named[129444]: configuring command channel from '/etc/bind/rndc.key' Sep 20 16:36:42 santo named[129444]: command channel listening on ::1#953 Sep 20 16:36:42 santo named[129444]: managed-keys-zone/internal: loaded serial 1 Sep 20 16:36:42 santo named[129444]: managed-keys-zone/external: loaded serial 1 Sep 20 16:36:42 santo named[129444]: name.c:2515: REQUIRE(target != ((void *)0)) failed, back trace Sep 20 16:36:42 santo named[129444]: #0 0x5608f23d6cc0 in ?? Sep 20 16:36:42 santo named[129444]: #1 0x7f7c3208ec6a in ?? Sep 20 16:36:42 santo named[129444]: #2 0x7f7c329d9cc8 in ?? Sep 20 16:36:42 santo named[129444]: #3 0x7f7c29e8bc3d in ?? Sep 20 16:36:42 santo named[129444]: #4 0x7f7c29e8be5d in ?? Sep 20 16:36:42 santo named[129444]: #5 0x7f7c29e8bfb5 in ?? Sep 20 16:36:42 santo named[129444]: #6 0x7f7c320b69b5 in ?? Sep 20 16:36:42 santo named[129444]: #7 0x7f7c31e9e380 in ?? Sep 20 16:36:42 santo named[129444]: #8 0x7f7c3194784f in ?? Sep 20 16:36:42 santo named[129444]: exiting (due to assertion failure) Sep 20 16:36:43 santo systemd[1]: named.service: Main process exited, code=killed, status=6/ABRT Sep 20 16:36:43 santo systemd[1]: named.service: Failed with result 'signal'.
Debug session:
(gdb_ bt #0 0x00007ffff673b18b in raise () from /lib64/libc.so.6 #1 0x00007ffff672355b in abort () from /lib64/libc.so.6 #2 0x000055555557741a in assertion_failed (file=0x7ffff7a9f829 "name.c", line=2515, type=isc_assertiontype_require, cond=0x7ffff7aa0bf9 "target != ((void *)0)") at ./main.c:261 #3 0x00007ffff6f52f72 in isc_assertion_failed (file=0x7ffff7a9f829 "name.c", line=2515, type=isc_assertiontype_require, cond=0x7ffff7aa0bf9 "target != ((void *)0)") at assertions.c:46 #4 0x00007ffff78ed19f in dns_name_copy (source=0x7ffff7cfc000 <root>, dest=0x7ffff2a02150, target=0x0) at name.c:2515 #5 0x00007fffead255d0 in empty_zone_search_init (iter=0x7ffff2a02150, qname=0x7ffff7cfc000 <root>, ztable=0x7ffff7fa5ef8) at empty_zones.c:239 #6 0x00007fffead25836 in empty_zone_handle_conflicts (name=0x7ffff7cfc000 <root>, zonetable=0x7ffff7fa5ef8, warn_only=true) at empty_zones.c:309 #7 0x00007fffead25a06 in empty_zone_handle_globalfwd_ev (task=0x7ffff7faf010, event=0x7fffeb9841d0) at empty_zones.c:361 #8 0x00007ffff6f8bff3 in dispatch (manager=0x7ffff7f9e010, threadid=0) at task.c:1152 #9 0x00007ffff6f8c727 in run (queuep=0x7ffff7f9e130) at task.c:1344 #10 0x00007ffff6d61380 in start_thread () from /lib64/libpthread.so.0 #11 0x00007ffff680a84f in clone () from /lib64/libc.so.6 (gdb) frame 3 #3 0x00007ffff6f52f72 in isc_assertion_failed (file=0x7ffff7a9f829 "name.c", line=2515, type=isc_assertiontype_require, cond=0x7ffff7aa0bf9 "target != ((void *)0)") at assertions.c:46 46 isc_assertion_failed_cb(file, line, type, cond); (gdb) info args file = 0x7ffff7a9f829 "name.c" line = 2515 type = isc_assertiontype_require cond = 0x7ffff7aa0bf9 "target != ((void *)0)" (gdb) frame 4 #4 0x00007ffff78ed19f in dns_name_copy (source=0x7ffff7cfc000 <root>, dest=0x7ffff2a02150, target=0x0) at name.c:2515 2515 REQUIRE(target != NULL); (gdb) info args source = 0x7ffff7cfc000 <root> dest = 0x7ffff2a02150 target = 0x0 (gdb) frame 5 frame 5 #5 0x00007fffead255d0 in empty_zone_search_init (iter=0x7ffff2a02150, qname=0x7ffff7cfc000 <root>, ztable=0x7ffff7fa5ef8) at empty_zones.c:239 239 dns_name_copynf(qname, &iter->qname); (gdb) info args iter = 0x7ffff2a02150 qname = 0x7ffff7cfc000 <root> ztable = 0x7ffff7fa5ef8 (gdb) frame 6 #6 0x00007fffead25836 in empty_zone_handle_conflicts (name=0x7ffff7cfc000 <root>, zonetable=0x7ffff7fa5ef8, warn_only=true) at empty_zones.c:309 309 for (result = empty_zone_search_init(&eziter, name, zonetable); (gdb) info args name = 0x7ffff7cfc000 <root> zonetable = 0x7ffff7fa5ef8 warn_only = true (gdb) info locals result = 0 first = true eziter = {qname = {magic = 1145983854, ndata = 0x0, length = 0, labels = 0, attributes = 0, offsets = 0x0, buffer = 0x7ffff2a021a0, link = { prev = 0xffffffffffffffff, next = 0xffffffffffffffff}, list = {head = 0x0, tail = 0x0}}, qname__buffer = {magic = 1114990113, base = 0x7ffff2a021e0, length = 255, used = 0, current = 0, active = 0, link = {prev = 0xffffffffffffffff, next = 0xffffffffffffffff}, mctx = 0x0, autore = false}, qname__buffer__base = '\000' <repeats 254 times>, ezname = {magic = 0, ndata = 0x0, length = 0, labels = 0, attributes = 0, offsets = 0x0, buffer = 0x0, link = {prev = 0x0, next = 0x0}, list = {head = 0x0, tail = 0x0}}, ezname__buffer = { magic = 0, base = 0x0, length = 0, used = 0, current = 0, active = 0, link = {prev = 0x0, next = 0x0}, mctx = 0x0, autore = false}, ezname__buffer__base = '\000' <repeats 254 times>, nextidx = 0, namerel = dns_namereln_none, zonetable = 0x0} name_char = '\000' <repeats 1023 times> ezname_char = '\000' <repeats 569 times>...
11.4
9.16.6
Gentoo
amd64
OpenLDAP 2.4.50
view "external" { dyndb "external-global-view" "/usr/lib64/bind/ldap.so" { uri "ldaps://ldap.example.com"; base "cn=global, cn=dns, dc=example, dc=com"; auth_method "simple"; bind_dn "cn=bind dlz,ou=People,dc=example,dc=com"; password "redacted"; server_id "santo.example.com"; }; }
No
Yes
None
Thanks. So it looks like current handling of buffered names in bind-dyndb-ldap (util.h) differs from what bind 9.16.6 expects. dns_fixedname_t appears in bind 9.13 and the code changed to use it instead of isc_buffer_t. As a result, current macros in util.h do not fill in offsets structure in the same way it is expected from dns_fixedname_t helpers.
util.h
dns_fixedname_t
isc_buffer_t
offsets
Since 9.11 doesn't have dns_fixedname_t support, we need to change empty_zones.[ch] to use either isc_buffer_t or dns_fixedname_t depending on the bind version.
empty_zones.[ch]
It is strange, it should call dns_name_copynf function with BIND 9.16. But your backtrace is correct for BIND 9.11. Would you be able to check value of LIBDNS_VERSION_MAJOR macro used in your build? Have you tried clean the build and rebuild all again? Is it possible you have both libraries on your system?
Clean the build and reconfigure. New ./configure run is important before the build. LIBDNS_VERSION_MAJOR should have value 1606 with BIND 9.16.6.
Can you share of output grep LIBDNS_VERSION_MAJOR config.log in build directory?
Ok, so the reason it fails is that there is no
#include "config.h"
in src/empty_zones.c and thus we never see LIBDNS_VERSION_MAJOR defined.
src/empty_zones.c
LIBDNS_VERSION_MAJOR
The same happens in some other files, @pemensik is looking into fixing them.
@benroberts I merged https://pagure.io/bind-dyndb-ldap/pull-request/196 that should fix this issue. Could you please try the patch https://pagure.io/bind-dyndb-ldap/c/20127e8276c1cba265f3532051fd42b3081b9095.patch ?
LGTM, bind is starting up and serving queries from the LDAP zones. Thanks for the extremely quick response to this!
Thanks. Closing. I'm going to do 11.5 release today.
Metadata Update from @abbra: - Issue close_status updated to: fixed - Issue status updated to: Closed (was: Open)
Log in to comment on this ticket.