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

Reply via email to