Annoyingly, I still can't reproduce this on the systems I have available. On a system where the problem occurs, can it be reproduced when dnsmasq is started standalone with the same command-line parameters? The idea situation would be to get the bug to show up in a dnsmasq instance running under gdb.
The strace gives lots of valuable information: during inialisation in network.c, create_bound_listeners() calls create_listeners() once. The creates a UDP socket and a TCP socket each bound to 127.0.1.1:53, with file-descriptors 4 and 5. Those file descriptors are stored in a struct listener object which will be the only one in a chain pointed to by daemon->listeners (or dnsmasq_daemon->listeners, in gdb). The file descriptors are stored in the ->fd and ->tcpfd fields of the struct. By the time dnsmasq gets to the select loop in dnsmasq.c, those two fields have somehow been zeroed - that's enough to exactly match what's in the strace. dnsmasq selects for read events on fd 0 instead of fd 4 and fd 5 and when select says that reading is OK, is makes the syscalls is would make for fd 4 (recvfrom) and fd 5 (accept) but to fd 0 instead. If someone can reproduce this in gdb I suggest doing the following. 1) Set a breakpoint in create_bound_listeners() and trace through until dnsmasq_daemon->listeners->fd and dnsmasq_daemon->listeners->tcpfd have the correct values (4 and 5) 2) Set watchpoints on those two expressions, and then continue execution. Gdb should then tell us where those locations are being overwritten. 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
