On 08/05/14 22:18, James Hunt wrote: > A bit of debugging shows that the culprit is blockdata_expand() which is > being called via blockdata_init(). The issue seems to be that > blockdata_expand() is passed a parameter of zero. That function then > mallocs zero bytes (successfully seemingly), the proceeds to overwrite > data before the returned address resulting the the 2 fds being set to > zero. > > blockdata_expand() is passed zero since daemon->cachesize (aka > dnsmasq_daemon->cachesize) is zero. This is confirmed by looking at > syslog which shows: > > May 8 21:56:54 utopic dnsmasq[10812]: started, version 2.70 cache > disabled >
Excellent. Many thanks for doing that. I've pushed the fix to the git repo and a test release, 2.71test2. I'm minded to make a 2.71 release (which has this and a few other bugfixes) in the next couple of days. > BTW - the problem is recreatable for me every time simply by spinning > up a utopic kvm instance. I'm on the end of a dodgy 3G connection that won't support a netinstall or image download in reasonable time/cost. Cheers, Simon. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1314697 Title: DNS resolution no longer works; dnsmasq uses 100% CPU To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1314697/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs