Many thanks for the thorough analysis. My understanding is that this is
fixed in
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=7b174c250df2bc97b503fd03b9e473998676b1a6
and therefore in 2.68test1 onwards. The Subject of your email implies
that's not true, or have I misunderstood?
Certainly, the existance of this bug is large part of the motivation for
the in-progress 2.68 release.
Cheers,
Simon.
On 25/11/13 12:54, Andrew Childs wrote:
Hi,
I recently upgraded to v2.67 (on FreeBSD, built with “gmake clean all-i18n
CFLAGS=-g") and found dnsmasq was frequently crashing when queried for a
particular cname with the following stack trace:
Program received signal SIGSEGV, Segmentation fault.
0x0000000000403804 in cache_unlink (crecp=0x80146f580) at cache.c:221
221 crecp->prev->next = crecp->next;
(gdb) bt
#0 0x0000000000403804 in cache_unlink (crecp=0x80146f580) at cache.c:221
#1 0x00000000004042bc in cache_find_by_name (crecp=0x80146f580, name=0x801409100
"a", now=1385382757, prot=2176) at cache.c:568
#2 0x000000000040c005 in answer_request (header=0x80142d000, limit=0x80142d200
"", qlen=19, local_addr=..., local_netmask=..., now=1385382757) at
rfc1035.c:1765
#3 0x000000000041b2b1 in receive_query (listen=0x801407100, now=1385382757) at
forward.c:893
#4 0x0000000000421a36 in check_dns_listeners (set=0x7fffffffd4c0,
now=1385382757) at dnsmasq.c:1369
#5 0x00000000004207d6 in main (argc=4, argv=0x7fffffffd718) at dnsmasq.c:898
With the configuration:
no-hosts
addn-hosts=dnsmasq-hosts
cname=a,b
Where dnsmasq-hosts has the following contents:
192.168.1.1 minecraft.cons.org.nz
192.168.1.2 b
Using git bisect it looks like this was introduced in
d56a604a9600c08d4a863527d549713c07f0186d.
As far as I understand it’s not valid to call cache_unlink on an entry added by
the configuration files, and indeed the next and prev pointers look like
uninitialised memory (possibly even part of the word “minecraft”). I think the
crash is being caused by a disagreement of which flags designate a
configuration based cache entry. add_hosts_cname sets the flag F_CONFIG
(changed from F_HOSTS by d56a604), while cache_find_by_name checks for F_HOSTS
| F_DHCP when deciding whether or not to call cache_unlink.
Changing the two occurrences of testing F_HOSTS | F_DHCP to testing F_CONFIG in
cache_find_by_name allows me to successfully resolve my test case, but I
haven’t explored enough to know which location isn’t using the correct flags.
Regards,
Andrew
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
