Report information
The Basics
Id:
37131
Status:
resolved
Priority:
Medium/Medium
Queue:

People
Requestors:
Cc:
AdminCc:

BugTracker
Version Fixed:
(no value)
Version Found:
(no value)
Versions Affected:
(no value)
Versions Planned:
(no value)
Priority:
(no value)
Severity:
(no value)
CVSS Score:
(no value)
CVE ID:
(no value)
Component:
(no value)
Area:
(no value)

Dates
Created:Tue, 09 Sep 2014 08:25:08 -0400
Updated:Fri, 07 Jul 2017 20:16:22 -0400
Closed:Wed, 02 Dec 2015 22:10:08 -0500



This bug tracker is no longer active.

Please go to our Gitlab to submit issues (both feature requests and bug reports) for active projects maintained by Internet Systems Consortium (ISC).

Due to security and confidentiality requirements, full access is limited to the primary maintainers.

Subject: [9.9.4-P2] crash in dns_adb_cancelfind() - a ratelimiter problem?
Date: Tue, 09 Sep 2014 14:24:49 +0200
To: bind-bugs@isc.org
From: Petr Spacek <pspacek@redhat.com>
Hello, I have encountered weir crash on this require: (((task) != ((void *)0)) && (((const isc__magic_t *)(task))->magic == ((('T') << 24 | ('A') << 16 | ('S') << 8 | ('K'))))) This happened couple times when I tried to load 100 small zones (~ 100 records each) and send SIGINT to named during zone loading. I'm attaching back traces from GDB. I'm not 100 % sure that it wasn't caused by my own code loaded into BIND but I have one wild hypothesis: isc_ratelimiter_enqueue() function (and its family) for some reason do not use isc_task_attach() for attaching sender task to ev->ev_sender field in the isc_event structure. In my case it seems that the task referenced from ev->ev_sender was detached and freed before the event from rate limiter had a chance to do something about it. Is it possible or am I completely wrong? Thank you for your time! -- Petr Spacek @ Red Hat

Message body is not shown because sender requested not to inline it.

Message body is not shown because sender requested not to inline it.

Message body is not shown because sender requested not to inline it.

I couldn't reproduce this and it should be sending to the same task as zone->task which is yet to be detached.