Hi Thomas, Recently i found this problem is due to the lease file corruption and there is a difference with prefix delegated lease time (14 days), isc-dhcp configured with 30 days lease. At some point the lease tile is getting corrupted, example: DHCPv6 server lease table: Host Name IP Address MAC Address State Type Expiration 2001:1890:xxxx:fa30::45/64 00:18:7d:xx:xx:xx active IA_NA 29:23:22:37 2592000s 604800s 2001:1890:xxxx:fa30::48/64 78:88:6d:xx:xx:xx active IA_NA 17387:20:50:39 1209600s 1209600s 2001:1890:xxxx:fa30::49/64 20:47:47:xx:xx:xx active IA_NA 29:23:25:30 2592000s 604800s I see that the assert condition based on the below scenario. (gdb) p *(struct iasubopt *)pool->active_timeouts->array[1] $16 = {refcnt = 3, addr = {__in6_u = {__u6_addr8 = " \001\030\220\022\250\372\060\000\000\000\000\000\000\000I", __u6_addr16 = {288, 36888, 43026, 12538, 0, 0, 0, 18688}, __u6_addr32 = {2417492256, xxxxxxxxx, 0, 1224736768}}}, plen = 0 '\000', state = 2 '\002', scope = 0x0, hard_lifetime_end_time = 1503763415, soft_lifetime_end_time = 0, prefer = 604800, valid = 2592000, ia = 0x5d7dc0, ipv6_pool = 0x5f6488, heap_index = 1} (gdb) p *(struct iasubopt *)pool->active_timeouts->array[2] $17 = {refcnt = 4, addr = {__in6_u = {__u6_addr8 = " \001\030\220\022\250\372\060\000\000\000\000\000\000\000H", __u6_addr16 = {288, 36888, 43026, 12538, 0, 0, 0, 18432}, __u6_addr32 = {2417492256, xxxxxxxxx, 0, 1207959552}}}, plen = 0 '\000', state = 2 '\002', scope = 0x0, hard_lifetime_end_time = 1502385681, soft_lifetime_end_time = 0, prefer = 1209600, valid = 1209600, ia = 0x5f5d38, ipv6_pool = 0x5f6488, heap_index = 2} these problem can be resolved in latest code ? because no assert or heap.c present in latest code. Thanks, Pradeep On Fri, Jul 14, 2017 at 4:51 PM, Pradeep Ponnuchamy via RT < dhcp-confidential@isc.org> wrote: > Hi Thomas, > > Thanks for the response > > I'm using dhcp-isc for DHCPv6 server. Any hint on bug fixes related to the > below scenario in recent releases will be helpful. > > Can u please explain how and when the lease heap memory can go to > inconsistent state.How the lease->heap.array data strcuture is built. whats > the maximum size of this array. > > I don't have the reproduction steps for now, i try to get it. > Getting continues REBIND messages from the DHCP client cause this assert > failure. The DHCP client is not accepting the REPLY messages from server. > Also, i see this assert failure only in long run, when DHCP clients keep > sending REBIND messages. > > From the coredump i see that the heap index is coming as 2. Is this valid > index to process the heap index in sink_down fn ? > > This is what the information i have for now. I will keep you updated. > > Regards, > Pradeep > > > On Fri, Jul 14, 2017 at 5:41 AM, Thomas Markwalder via RT < > dhcp-confidential@isc.org> wrote: > > > Hello Pradeep: > > > > While back traces are often very helpful, in this case it really doesn't > > give us enough information. The assertion that occurs is detecting an > > inconsistent state within the lease heap and is something of a > self-defense > > mechanism. The back trace really doesn't shed any light on what might > have > > caused the inconsistency. > > > > First, I would recommend that you consider upgrading as you are quite a > > few releases behind. The current releases are 4.3.6 and 4.1-ESV-R14, and > > we are releasing 4.3.6 and 4.1-ESV-R15 betas later today. The final > > releases for those are due 7/31/2017. > > > > While you're considering upgrading, any contextual information you can > > provide such as log files, server config files, lease files, or pcaps > would > > be helpful. Is this something you can reproduce, if so how? Can you > > describe the circumstances under which you see this and how often it > occurs? > > > > The more information you can provide, the more likely it is that we will > > be able to find the issue. Thank you for taking the time to report this > > issue to us. > > > > > > Regards, > > > > Thomas Markwalder > > ISC Software Engineering > > > > > > > > On Thu Jul 13 23:09:29 2017, doors.pradeep@gmail.com wrote: > > > Bug Report from www.isc.org: > > > > > > Name: Pradeep Ponnuchamy > > > Email: doors.pradeep@gmail.com > > > Software Version: Version 4.1-ESV-R8 > > > OS: Linux > > > Subject:sigabrt with assert in dhcpd process > > > > > > > > > Bug Detail > > > =========== > > > #0 0xb6f8ae1c in raise () from lib/libc.so.0 > > > (gdb) bt > > > #0 0xb6f8ae1c in raise () from lib/libc.so.0 > > > #1 0xb6f84ff8 in abort () from lib/libc.so.0 > > > #2 0xb6f50b80 in __assert () from lib/libc.so.0 > > > #3 0x000712e0 in sink_down (heap=0x18360b8, i=, > > > elt=0x189cd38) at ../../common/heap.c:177 > > > #4 0x000404f4 in renew_lease6 (pool=, lease=0x189cd38) > > > at ../../server/mdb6.c:1282 > > > #5 0x0003c4dc in reply_process_ia_na (ia=, > > > reply=) at ../../server/dhcpv6.c:1844 > > > #6 lease_to_client (reply_ret=0xbea906dc, packet=0x1898d70, > > > client_id=, server_id=) at > > > ../../server/dhcpv6.c:1326 > > > #7 0x0003f154 in dhcpv6_rebind (packet=0x1898d70, reply=0xbea906dc) > > > at ../../server/dhcpv6.c:4632 > > > #8 build_dhcpv6_reply (reply=0xbea906dc, packet=0x1898d70) at > > > ../../server/dhcpv6.c:5879 > > > #9 0x0003fc10 in dhcpv6 (packet=0x1898d70) at > > > ../../server/dhcpv6.c:5990 > > > #10 0x00058098 in do_packet6 (interface=0x17e57b8, packet=0xbea9075c > > > "6\261\260}", len=78, from_port=, from=0xbeaa0778, > > > was_unicast=isc_boolean_false) at ../../common/options.c:3941 > > > #11 0x0004abcc in got_one_v6 (h=) at > > > ../../common/discover.c:1587 > > > #12 0x000793a4 in omapi_one_dispatch (wo=, > > > t=0xbeaa0b50) at ../../omapip/dispatch.c:539 > > > #13 0x0004ccf0 in dispatch () at ../../common/dispatch.c:95 > > > #14 0x0000fbc4 in main (argc=, argv=) at > > > ../../server/dhcpd.c:874 > > > > > > --- > > > This email was received through isc.org Bug Submission Form > > > > > >