Bug 1076261

Summary: db.c:636: REQUIRE(nodep != ((void *)0) && *nodep != ((void *)0)) failed, back trace
Product: [Fedora] Fedora Reporter: William Brown <william>
Component: bind-dyndb-ldapAssignee: Petr Spacek <pspacek>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 19CC: pspacek, thozza, vonsch, william
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-03-18 12:03:01 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description William Brown 2014-03-13 23:54:15 UTC 
Description of problem:
Running freeIPA with bind-dyndb-ldap, it is a regular occurance to suffer network latency from DNS "disappearing" on the network. I have seen this on 3 domain controllers, so it's not a localised issue. 

Examining the logs, I can see that named is regularly crashing with:

 db.c:636: REQUIRE(nodep != ((void *)0) && *nodep != ((void *)0)) failed, back trace

I am *not* able to get a back trace into ABRT from this. I have installed all the debuginfo packages and when this occurs again I will attach that output if possible.

This tends to occur when requesting AAAA records for a system.
Comment 1 Petr Spacek 2014-03-14 06:48:22 UTC 
Unfortunatelly, I'm not able to help you without more information:
Please post information requrested on https://fedorahosted.org/bind-dyndb-ldap/wiki/BugReporting

And attach backtrace or coredump if possible.

Please make sure that you have debuginfo installed and install also abrt-ccpp package (and restar abrt).
Comment 2 William Brown 2014-03-15 03:28:30 UTC 
Find the abrt report in bz https://bugzilla.redhat.com/show_bug.cgi?id=1076775
Comment 3 Petr Spacek 2014-03-18 12:03:01 UTC 

*** This bug has been marked as a duplicate of bug 1076775 ***