Bug 878139

Created attachment 647905 [details]
File: core_backtrace

Created attachment 647906 [details]
File: environ

Created attachment 647907 [details]
File: backtrace

Created attachment 647908 [details]
File: limits

Created attachment 647909 [details]
File: cgroup

Created attachment 647910 [details]
File: smolt_data

Created attachment 647911 [details]
File: executable

Created attachment 647912 [details]
File: maps

Created attachment 647913 [details]
File: dso_list

Created attachment 647914 [details]
File: proc_pid_status

Created attachment 647915 [details]
File: var_log_messages

Created attachment 647916 [details]
File: open_fds

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

*** Bug 919637 has been marked as a duplicate of this bug. ***

*** Bug 919710 has been marked as a duplicate of this bug. ***

The issue is caused by a mistake in the patch added some time ago [1].

I appears that timing is critical for this issue to occur. host/nslookup sends
a UDP DNS QUERY and starts a timer with timeout. The timer handler is
"connect_timeout()". When answer is received "recv_done()" is called in which
in the end "clear_query(query)" is called. In some circumstances the "query"
passed is the lookup->current_query in which case the lookup->current_query
freed and set to NULL. Well and now it gets interesting when the timeout runs
out and the "connect_timeout()" is called.

<snip from connect_timeout()>
...
l = event->ev_arg;
query = l->current_query;  /* this is NULL */
...
<snip>
...
} else {
		fputs(l->cmdline, stdout);
		if (!next_origin(query))) {    /* <- query is NULL */
			printf(";; connection timed out; no servers could be "
			       "reached\n");
		} else {
			printf(";; connection timed out; trying next "
			       "origin\n");
		}
...

But there are situations when timeout handler is called before the current_query
is freed and set to NULL and then it works.

The lookup structure is protected by mutex. So it looks that the issue depends on
how the system schedules threads and which locks the lookup structure first.

But this is expected behaviour (I think) since the "connection_timeout()"
checks if query (current_query) is NULL. And later on when retrying to send
queries once more ISC_LIST_HEAD(l->q) is used instead of the current_query.
l->q is a list of queries and when it's empty, the whole lookup structure
is destroyed and also a timer if there is any. So there should not be
a situation when timeout handler is called and the queries list is empty.

From what I tested, using "ISC_LIST_HEAD(l->q)" instead of "query" when calling
next_origin() works well. It is also good to mention that for the next_origin()
function it is irrelevant with which query it is called. The parameter is used
only to get to the "parent" lookup structure pointer which is the same for all
queries in the list.

[1] http://lists.fedoraproject.org/pipermail/scm-commits/2011-October/677202.html

Fixed in:
bind-9.9.3-0.7.rc2.fc20
bind-9.9.3-0.7.rc2.fc19
bind-9.9.2-12.P2.fc18
bind-9.9.2-8.P2.fc17

(In reply to Tomas Hozza from comment #17)
> bind-9.9.2-12.P2.fc18

It seems that at least for this, only a koji build exists but no update has been submitted, is that on purpose?

(In reply to Ville Skyttä from comment #18)
> (In reply to Tomas Hozza from comment #17)
> > bind-9.9.2-12.P2.fc18
> 
> It seems that at least for this, only a koji build exists but no update has
> been submitted, is that on purpose?

This is true. I'm waiting for bind-9.9.3 to be released to push an update in
bodhi. Currently there is 9.9.3rc2. So this is intentional and therefore the
Bug status is MODIFIED and not ON_QA.

bind-dyndb-ldap-2.6-2.fc18,dnsperf-2.0.0.0-4.fc18,dhcp-4.2.5-12.fc18,bind-9.9.3-2.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/bind-dyndb-ldap-2.6-2.fc18,dnsperf-2.0.0.0-4.fc18,dhcp-4.2.5-12.fc18,bind-9.9.3-2.fc18

dhcp-4.2.5-2.fc17,dnsperf-2.0.0.0-3.fc17,bind-dyndb-ldap-2.5-2.fc17,bind-9.9.3-2.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/dhcp-4.2.5-2.fc17,dnsperf-2.0.0.0-3.fc17,bind-dyndb-ldap-2.5-2.fc17,bind-9.9.3-2.fc17

Package dhcp-4.2.5-2.fc17, dnsperf-2.0.0.0-3.fc17, bind-dyndb-ldap-2.5-2.fc17, bind-9.9.3-3.P1.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing dhcp-4.2.5-2.fc17 dnsperf-2.0.0.0-3.fc17 bind-dyndb-ldap-2.5-2.fc17 bind-9.9.3-3.P1.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-10100/dhcp-4.2.5-2.fc17,dnsperf-2.0.0.0-3.fc17,bind-dyndb-ldap-2.5-2.fc17,bind-9.9.3-3.P1.fc17
then log in and leave karma (feedback).

bind-dyndb-ldap-2.6-2.fc18, dnsperf-2.0.0.0-4.fc18, dhcp-4.2.5-12.fc18, bind-9.9.3-3.P1.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

dhcp-4.2.5-2.fc17, dnsperf-2.0.0.0-3.fc17, bind-dyndb-ldap-2.5-2.fc17, bind-9.9.3-3.P1.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.