This looks surprisingly similar to a bug we have fixed rather recently in the currently active Pi-hole v6.0 beta development, I didn't know we inherited it from v5.x.
I proposed a fix in branch fix/many_clients but I am not set up for doing really good testing myself for v5.x stuff anymore. It'd be awesome if you could test this in roughly half an hour from now when the binaries finished building.
Pinging almost randomly @PromoFaux@yubiuser@rdwebdesign for advise how to check out a custom FTL branch (fix/many_clients) in a Pi-hole v5.x docker container.
Thank you so much for your time.
so I'm waiting for a fix to be released for this? can you let me know when this happens or I'll just wait for the next release.
Thanks again
Me too!
today I try to regenerate the container.
I am running these tests on a test container, but if this goes well my test container will remain in production.
I give you the result later
root@raspberrypi:/# sudo gdb -p $(pidof pihole-FTL)
GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "aarch64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
Attaching to process 394
Reading symbols from /usr/bin/pihole-FTL...
Reading symbols from /lib/aarch64-linux-gnu/libm.so.6...
Reading symbols from /usr/lib/debug/.build-id/96/753a610bba2bd96d65892adfdb4a5246e6c754.debug...
Reading symbols from /lib/aarch64-linux-gnu/librt.so.1...
Reading symbols from /usr/lib/debug/.build-id/b5/d4628673dfea1cdf2297aac433bb9feec5f269.debug...
Reading symbols from /lib/aarch64-linux-gnu/libpthread.so.0...
Reading symbols from /usr/lib/debug/.build-id/f3/35aa4318e0d87acccf286bbf12724a53fbee8b.debug...
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
Reading symbols from /lib/aarch64-linux-gnu/libc.so.6...
Reading symbols from /usr/lib/debug/.build-id/74/ed0aefe9a937a76a5d320fd24f2e01762ca277.debug...
Reading symbols from /lib/ld-linux-aarch64.so.1...
Reading symbols from /usr/lib/debug/.build-id/c9/55aebf7720fc28ce7443a0599cde62b194e7b7.debug...
Reading symbols from /lib/aarch64-linux-gnu/libnss_files.so.2...
Reading symbols from /usr/lib/debug/.build-id/d8/3acfa0cca35bafd0b0777dec2e5e6187836279.debug...
sqlite3VdbeExec (p=p@entry=0x5576d29568) at /__w/FTL/FTL/src/database/sqlite3.c:91545
91545 /__w/FTL/FTL/src/database/sqlite3.c: No such file or directory.
(gdb) thread 1
[Switching to thread 1 (Thread 0x7f80902420 (LWP 394))]
#0 sqlite3_finalize (pStmt=0x306874653030322e) at /__w/FTL/FTL/src/database/sqlite3.c:88353
88353 /__w/FTL/FTL/src/database/sqlite3.c: No such file or directory.
(gdb) where
#0 sqlite3_finalize (pStmt=0x306874653030322e) at /__w/FTL/FTL/src/database/sqlite3.c:88353
#1 0x000000555bfd6aa8 in gravityDB_finalize_client_statements (client=0x7f7f5886e0) at /__w/FTL/FTL/src/database/gravity-db.c:952
#2 gravityDB_reload_groups (client=0x7f7f5886e0) at /__w/FTL/FTL/src/database/gravity-db.c:1252
#3 gravityDB_client_check_again (client=0x7f7f5886e0) at /__w/FTL/FTL/src/database/gravity-db.c:1272
#4 gravityDB_client_check_again (client=0x7f7f5886e0) at /__w/FTL/FTL/src/database/gravity-db.c:1261
#5 0x000000555bfd72c0 in in_whitelist (domain=0x5576d98c50 "apple.com", dns_cache=0x7f809061b0, client=0x7f7f5886e0) at /__w/FTL/FTL/src/database/gravity-db.c:1284
#6 0x000000555bfba598 in _FTL_check_blocking (queryID=queryID@entry=40967, domainID=domainID@entry=1, clientID=clientID@entry=13595, line=<optimized out>,
file=<optimized out>) at /__w/FTL/FTL/src/dnsmasq_interface.c:1429
#7 0x000000555bfbde7c in _FTL_check_blocking (file=0x555c1edf78 "/__w/FTL/FTL/src/dnsmasq_interface.c", line=836, clientID=13595, domainID=1, queryID=40967)
at /__w/FTL/FTL/src/dnsmasq_interface.c:683
#8 _FTL_new_query (flags=flags@entry=524296, name=<optimized out>, addr=addr@entry=0x7ff70fb988, arg=0x555c1f27d0 "query", qtype=<optimized out>, id=<optimized out>,
proto=proto@entry=UDP, file=file@entry=0x555c1feb80 "/__w/FTL/FTL/src/dnsmasq/forward.c", line=line@entry=1771) at /__w/FTL/FTL/src/dnsmasq_interface.c:836
#9 0x000000555c000994 in receive_query (listen=listen@entry=0x5576ced3a0, now=now@entry=1700733603) at /__w/FTL/FTL/src/dnsmasq/forward.c:1770
#10 0x000000555bff14f4 in check_dns_listeners (now=now@entry=1700733603) at /__w/FTL/FTL/src/dnsmasq/dnsmasq.c:1868
#11 0x000000555bff30f0 in main_dnsmasq (argc=<optimized out>, argv=<optimized out>) at /__w/FTL/FTL/src/dnsmasq/dnsmasq.c:1275
#12 0x000000555bfb2180 in main (argc=<optimized out>, argv=0x7ff70fbe38) at /__w/FTL/FTL/src/main.c:116
The concerning bit here is that we have by now seen three crashes in three different locations and they - at first glance - are all completely independent from each other. How many clients do you have (roughly) in your network? Are they known to change very often - please also think into the direction of clients shuffling their addresses on a regular basis for increased "privacy".
edit The various places - so far - always had a connection to the whitelist...
@n3rvino I'm sorry to cause additional trouble for you but it'd probably be very helpful if you could some log files with crashes and corresponding likes with all debug options set to true as you did above: