Bug#921310: dnsmasq "segment fault" bug when total conf files size is too large
I guess this can be closed. Gone all day without being able to replicate the sigfault, so nothing to capture. It seems to be chugging along well now, must have been user error on my side. Thanks for the quick response! -Zac Morris On Sun, Feb 10, 2019 at 2:03 PM Bernhard Übelacker wrote: > Ok, so the package corekeeper would be an option? > Is gdb-minimal also already too much? > > Kind regards, > Bernhard > > PS.: please leave the bugs email as CC or To. ;-) > >
Bug#921310: dnsmasq "segment fault" bug when total conf files size is too large
(meta: sorry reply all goes against my core nature ;-) Ive stepped out for a bit so I'll take a look at gdb-minimal when I'm back, but as of this morning I haven't been able to make it crash. I'll try the largest energized pak when I'm back and see if I can force a crash then. Thanks, Zac On Sun, Feb 10, 2019, 2:03 PM Bernhard Übelacker wrote: > Ok, so the package corekeeper would be an option? > Is gdb-minimal also already too much? > > Kind regards, > Bernhard > > PS.: please leave the bugs email as CC or To. ;-) > >
Bug#921310: dnsmasq "segment fault" bug when total conf files size is too large
Ok, so the package corekeeper would be an option? Is gdb-minimal also already too much? Kind regards, Bernhard PS.: please leave the bugs email as CC or To. ;-)
Bug#921310: dnsmasq "segment fault" bug when total conf files size is too large
Hello Zac Morris, you still may consider installed systemd-coredump and when it happens again provide the complete lines reported by journalctl related to the crash. I, as I said not deeply involved in dnsmasq and just trying to collect some information, tried to replicate your configuration, but in my case dnsmasq then crashes already at start. I have created these files just as empty ones: /etc/dnsmasq.d/hosts/hosts.block /etc/dnsmasq.d/hosts/hosts.local /etc/dnsmasq.d/dhcp-hosts And appended to /etc/dnsmasq.conf: conf-file=/etc/dnsmasq.d/lan.conf If I understand you right, you download e.g. https://raw.githubusercontent.com/EnergizedProtection/block/master/unified/formats/dnsmasq.conf and then put it to /etc/dnsmasq.d/hosts/hosts.block.dnsmasq.conf Kind regards, Bernhard
Bug#921310: dnsmasq "segment fault" bug when total conf files size is too large
{sigh}
So of course, today (2019-02-10) I can't reproduce the error. I even went
up to the Extreme (762213 entries) pak, and increased the DNS cache to
1, and it's humming along perfectly.
It is increasing the first lookup speed from ~50-70ms to ~400-500ms, but I
would consider that reasonable for a local lookup against 762213 entries!
If you would, keep the case open another day, and I'll leave it running.
Tomorrow it will be under greater load.
Thanks!!!
P.S. One question: When added via:
conf-file=/etc/dnsmasq.d/hosts/hosts.block.dnsmasq.conf are those entries
added to an in memory cache (separate from the lookup-cache I'm assuming?),
or at first-lookup does the application read the file (or a hashed temp
file it creates?) if the entry isn't already cached?
The Extreme file is 29MB, yet my current memory usage is:
totalusedfree shared buff/cache
available
Mem: 16361824 401040141501042052 1810680
15776944
Here's a dig lookup example:
dig library.usc.edu @192.168.1.1
; <<>> DiG 9.10.3-P4-Debian <<>> library.usc.edu @192.168.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14105
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;library.usc.edu. IN A
;; ANSWER SECTION:
library.usc.edu.3600IN CNAME usclibraries.usc.edu.
usclibraries.usc.edu. 3600IN A 128.125.183.98
;; Query time: 559 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Sun Feb 10 12:42:49 EST 2019
;; MSG SIZE rcvd: 87
On Sun, Feb 10, 2019 at 8:17 AM Bernhard Übelacker
wrote:
> Hello Zac Morris,
>
> >> Yeah, I didn't know how to update the case. Is there a web front-end for
> >> updating/tracking the cases? I couldn't figure out how to do it via
> email.
>
> You just need to send the answers also to 921...@bugs.debian.org
> as receiver or CC. Then all the information is collected in this page:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921310
>
> >> The dmesg output was: segfault error 4 (memory?)
>
> Is this the complete line in dmesg output?
>
>
> Forwarding the information to the bug.
>
> Kind regards,
> Bernhard
>
>
> ---- Weitergeleitete Nachricht
> Betreff:Re: Bug#921310: dnsmasq "segment fault" bug when total conf
> files size is too large
> Datum: Sat, 9 Feb 2019 15:31:52 -0500
> Von:Zac Morris
> An: Bernhard Übelacker
>
>
>
> Yeah, I didn't know how to update the case. Is there a web front-end for
> updating/tracking the cases? I couldn't figure out how to do it via email.
>
> The dmesg output was: segfault error 4 (memory?)
>
> So hopefully walking you through it might help?
>
> When I use the conf-file=parm in my config file to point to any of the
> dnsmasq formatted block lists provided by https://energized.pro/#packs,
> using anything larger than Basic (which contains about 466000 entries)
> causes the segfault error 4 after just a few DNS queries.
>
> Using Basic doesn't cause the segfault, but from the machine running
> dnsmasq, when I use a dig (using the Basic dnsmasq format file added via
> conf-file= ) it adds over 500ms to the lookup. (I got 4 seconds once,
> but haven't been able to replicate that again). I didn't use this setup
> very long so it may have caused the segfault as well after some time.
>
> What I ended up doing is using the /etc/hosts version of the energized
> files.
> #my local static network devices
> addn-hosts=/etc/dnsmasq.d/hosts/hosts.local
> #Basic etc/hosts formated file provided by Energized.pro
> addn-hosts=/etc/dnsmasq.d/hosts/hosts.block
>
> When I do that I'm getting an average new domain lookup of 23ms
> non-dnssec, 65ms with dnssec), with 0ms on subsequent (cached, as
> expected) lookups either way.
>
> I understand that dnsmasq is geared more towards small memory devices,
> so this may not be a priority.
>
> It would seem that loading large address=based conf files causes a
> segfault error 4 if it's too larger, but if it's large (but not too
> larger) it adds substantial time to a lookup, but why would
> using addn-hosts= with the the same huge ~466000 entries add no time to
> the lookup nor cause an error 4?
>
>
> I'm attaching my current lan.conf which is loaded from the default
> /etc/dnsmasq.conf
>
> THANKS!!!
>
>
Bug#921310: Fwd: Bug#921310: dnsmasq "segment fault" bug when total conf files size is too large
Hello Zac Morris, >> Yeah, I didn't know how to update the case. Is there a web front-end for >> updating/tracking the cases? I couldn't figure out how to do it via email. You just need to send the answers also to 921...@bugs.debian.org as receiver or CC. Then all the information is collected in this page: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921310 >> The dmesg output was: segfault error 4 (memory?) Is this the complete line in dmesg output? Forwarding the information to the bug. Kind regards, Bernhard Weitergeleitete Nachricht Betreff: Re: Bug#921310: dnsmasq "segment fault" bug when total conf files size is too large Datum: Sat, 9 Feb 2019 15:31:52 -0500 Von:Zac Morris An: Bernhard Übelacker Yeah, I didn't know how to update the case. Is there a web front-end for updating/tracking the cases? I couldn't figure out how to do it via email. The dmesg output was: segfault error 4 (memory?) So hopefully walking you through it might help? When I use the conf-file=parm in my config file to point to any of the dnsmasq formatted block lists provided by https://energized.pro/#packs, using anything larger than Basic (which contains about 466000 entries) causes the segfault error 4 after just a few DNS queries. Using Basic doesn't cause the segfault, but from the machine running dnsmasq, when I use a dig (using the Basic dnsmasq format file added via conf-file= ) it adds over 500ms to the lookup. (I got 4 seconds once, but haven't been able to replicate that again). I didn't use this setup very long so it may have caused the segfault as well after some time. What I ended up doing is using the /etc/hosts version of the energized files. #my local static network devices addn-hosts=/etc/dnsmasq.d/hosts/hosts.local #Basic etc/hosts formated file provided by Energized.pro addn-hosts=/etc/dnsmasq.d/hosts/hosts.block When I do that I'm getting an average new domain lookup of 23ms non-dnssec, 65ms with dnssec), with 0ms on subsequent (cached, as expected) lookups either way. I understand that dnsmasq is geared more towards small memory devices, so this may not be a priority. It would seem that loading large address=based conf files causes a segfault error 4 if it's too larger, but if it's large (but not too larger) it adds substantial time to a lookup, but why would using addn-hosts= with the the same huge ~466000 entries add no time to the lookup nor cause an error 4? I'm attaching my current lan.conf which is loaded from the default /etc/dnsmasq.conf THANKS!!! lan.conf Description: Binary data
Bug#921310: dnsmasq "segment fault" bug when total conf files size is too large
Hello Zac Morris, I am not the maintainer and just trying to get some more informations of the segfault. Unfortunately I think you need to provide some more details on your used configuration. The line shown in dmesg about the segfault could also be of help already. Otherwise you could also install a core dump collector like systemd-coredump and gdb and trigger the segfault. Then you can inspect the created dumps by: coredumpctl list And show where it is really crashing by sending the output of: coredumpctl gdb [PID] bt Even better if the matching debug symbol packages are installed like in [1], but I fear that there is not yet such a package in stretch for dnsmasq. Kind regards, Bernhard [1] https://wiki.debian.org/HowToGetABacktrace
Bug#921310: dnsmasq "segment fault" bug when total conf files size is too large
Package: dnsmasq Status: install ok installed Priority: optional Section: net Installed-Size: 71 Maintainer: Simon Kelley Architecture: all Version: 2.76-5+deb9u2 Depends: netbase, dnsmasq-base (>= 2.76-5+deb9u2), init-system-helpers (>= 1.18~) Suggests: resolvconf Conflicts: resolvconf (<< 1.15) Conffiles: /etc/init.d/dnsmasq 619ec632736050c3f49e43ecf218efce /etc/default/dnsmasq 8528b9b07acf4cbac231eb21dd3d262c /etc/dnsmasq.conf bc949f5cad485a88b585271b933f0c05 When I add conf files from: https://energized.pro/#packs Any of the files greater than Basic (13MB), cause dnsmasq to crash with a segmentation fault 0 fault 4. I do not use resolvconf nor systemd. This is running on a PC with 16GB of RAM, and a 4 core i3 Intel processor, not just a small consumer wifi router/ARM box. My lan.conf file: 1 listen-address=192.168.1.1,127.0.0.1 2 cache-size=1000 3 no-negcache 4 conf-file=/usr/share/dnsmasq-base/trust-anchors.conf 5 dnssec 6 dnssec-check-unsigned 7 8 #domain-needed 9 bogus-priv 10 no-resolv 11 no-poll 12 server=/lan.zacwolf.com/192.168.1.1 13 server=8.8.8.8 14 server=8.8.4.4 15 #server=209.18.47.61 16 #server=209.18.47.62 17 strict-order 18 local=/lan.zacwolf.com/ 19 interface=br0 20 expand-hosts 21 domain=lan.zacwolf.com 22 dhcp-range=192.168.1.100,192.168.1.249,72h 23 addn-hosts=/etc/dnsmasq_static_hosts.conf 24-50 assign reserved IPs to MACs 51 #===START TFTP Options 52 enable-tftp 53 dhcp-range=tftp,192.168.1.250,192.168.1.253 54 tftp-root=/var/tftp 55 tftp-no-fail 56 #tftp-secure 57 #tftp-no-blocksize 58 #===END TFTP OPTIONS 59 dhcp-option=option6:information-refresh-time,6h 60 dhcp-option=19,0# option ip-forwarding off 61 dhcp-option=42,216.239.35.0 # Google NTP server 62 dhcp-option=44,192.168.1.1 # set netbios-over-TCP/IP nameserver(s) aka WINS server(s) 63 dhcp-option=45,192.168.1.1 # netbios datagram distribution server 64 dhcp-option=46,8# netbios node type 65 66 dhcp-authoritative 67 #dhcp-script=/bin/echo 68 69 #Redirect trackers to local webserver 70 conf-file=/etc/dnsmasq.d/blocks.conf If the blocks.conf goes over the 13MB Basic file from Energized Pro, I get the segment fault error. THANKS!
