FTL
FTL copied to clipboard
pi-hole
FTL crashes
Versions
Pi-hole version is v5.9 (Latest: v5.9) AdminLTE version is v5.11 (Latest: v5.11) FTL version is v5.14 (Latest: v5.14)
Platform
OS and version: Debian 10 Platform: Raspberry Pi
Expected behavior
Not crashing
Actual behavior / bug
FTL crashes every sunday on database update, occurred several times already.
Steps to reproduce
Unknown.
Debug Token
- URL: https://tricorder.pi-hole.net/Bf2B5aTd/
Screenshots
N/A
Additional context
[2022-03-13 00:59:01.046 26349/T26353] Notice: Database size is 488.36 MB, deleted 87 rows [2022-03-13 02:00:00.859 26349/T26353] Notice: Database size is 488.39 MB, deleted 69 rows [2022-03-13 02:59:01.033 26349/T26353] Notice: Database size is 488.44 MB, deleted 79 rows [2022-03-13 03:59:01.266 26349/T26353] Notice: Database size is 488.47 MB, deleted 64 rows [2022-03-13 04:26:01.736 26349M] Reloading DNS cache [2022-03-13 04:26:01.748 26349M] !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! [2022-03-13 04:26:01.748 26349M] ----------------------------> FTL crashed! <---------------------------- [2022-03-13 04:26:01.748 26349M] !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! [2022-03-13 04:26:01.748 26349M] Please report a bug at https://github.com/pi-hole/FTL/issues [2022-03-13 04:26:01.748 26349M] and include in your report already the following details: [2022-03-13 04:26:01.748 26349M] FTL has been running for 585355 seconds [2022-03-13 04:26:01.748 26349M] FTL branch: master [2022-03-13 04:26:01.749 26349M] FTL version: v5.14 [2022-03-13 04:26:01.749 26349M] FTL commit: 52e6b95 [2022-03-13 04:26:01.749 26349M] FTL date: 2022-02-12 19:58:34 +0000 [2022-03-13 04:26:01.749 26349M] FTL user: started as pihole, ended as pihole [2022-03-13 04:26:01.749 26349M] Compiled for armv7hf (compiled on CI) using arm-linux-gnueabihf-gcc (Debian 6.3.0-18) 6.3.0 20170516 [2022-03-13 04:26:01.749 26349M] Process details: MID: 26349 [2022-03-13 04:26:01.749 26349M] PID: 26349 [2022-03-13 04:26:01.749 26349M] TID: 26349 [2022-03-13 04:26:01.749 26349M] Name: pihole-FTL [2022-03-13 04:26:01.750 26349M] Received signal: Segmentation fault [2022-03-13 04:26:01.750 26349M] at address: 0x2a [2022-03-13 04:26:01.750 26349M] with code: SEGV_MAPERR (Address not mapped to object) [2022-03-13 04:26:01.750 26349M] Backtrace: [2022-03-13 04:26:01.751 26349M] B[0000]: /usr/bin/pihole-FTL(generate_backtrace+0x29) [0x4a0f6e] [2022-03-13 04:26:02.054 26349/T26353] SQLite3 message: file renamed while open: /etc/pihole/gravity.db (28) [2022-03-13 04:26:02.057 26349/T26353] Compiled 0 whitelist and 0 blacklist regex filters for 33 clients in 0.6 msec [2022-03-13 04:26:02.680 26349M] L[0000]: /__w/FTL/FTL/src/signals.c:99 [2022-03-13 04:26:02.687 26349M] B[0001]: /usr/bin/pihole-FTL(+0x41322) [0x4a1322] [2022-03-13 04:26:02.747 26349M] L[0001]: /__w/FTL/FTL/src/signals.c:242 [2022-03-13 04:26:02.754 26349M] B[0002]: /lib/arm-linux-gnueabihf/libc.so.6(__default_rt_sa_restorer+0) [0x76cd3120] [2022-03-13 04:26:02.755 26349M] ------ Listing content of directory /dev/shm ------ [2022-03-13 04:26:02.755 26349M] File Mode User:Group Size Filename [2022-03-13 04:26:02.755 26349M] rwxrwxrwx root:root 260 . [2022-03-13 04:26:02.756 26349M] rwxr-xr-x root:root 4K .. [2022-03-13 04:26:02.756 26349M] rw------- pihole:pihole 4K FTL-per-client-regex [2022-03-13 04:26:02.757 26349M] rw------- pihole:pihole 98K FTL-dns-cache [2022-03-13 04:26:02.757 26349M] rw------- pihole:pihole 12K FTL-overTime [2022-03-13 04:26:02.758 26349M] rw------- pihole:pihole 2M FTL-queries [2022-03-13 04:26:02.758 26349M] rw------- pihole:pihole 160K FTL-upstreams [2022-03-13 04:26:02.759 26349M] rw------- pihole:pihole 684K FTL-clients [2022-03-13 04:26:02.759 26349M] rw------- pihole:pihole 82K FTL-domains [2022-03-13 04:26:02.760 26349M] rw------- pihole:pihole 164K FTL-strings [2022-03-13 04:26:02.760 26349M] rw------- pihole:pihole 12 FTL-settings [2022-03-13 04:26:02.761 26349M] rw------- pihole:pihole 240 FTL-counters [2022-03-13 04:26:02.761 26349M] rw------- pihole:pihole 56 FTL-lock [2022-03-13 04:26:02.762 26349M] --------------------------------------------------- [2022-03-13 04:26:02.762 26349M] Please also include some lines from above the !!!!!!!!! header. [2022-03-13 04:26:02.762 26349M] Thank you for helping us to improve our FTL engine! [2022-03-13 04:26:02.762 26349M] Waiting for threads to join [2022-03-13 04:26:02.762 26349M] Thread telnet-IPv4 (0) is idle, terminating it. [2022-03-13 04:26:02.763 26349M] Thread telnet-IPv6 (1) is idle, terminating it. [2022-03-13 04:26:02.763 26349M] Thread telnet-socket (2) is idle, terminating it. [2022-03-13 04:26:02.764 26349M] Thread database (3) is idle, terminating it. [2022-03-13 04:26:02.765 26349M] Thread housekeeper (4) is idle, terminating it. [2022-03-13 04:26:02.765 26349M] Thread DNS client (5) is idle, terminating it. [2022-03-13 04:26:02.766 26349M] All threads joined [2022-03-13 04:26:02.775 26349M] ########## FTL terminated after 6d 18h 35m 56s (code 1)! ##########
Sorry for the (huge!) delay in replying and the inconvenience this is causing. This very much looks like an issue with shared memory on your machine.
Please add
DEBUG_ALL=true
to the file /etc/pihole/pihole-FTL.conf (create if it does not exist) and run
pihole restartdns
Next time the crash happens, please include again the crash report from /var/log/pihole-FTL.conf with some extra lines of context above the !!!!!! header. This may help us getting a better picture of where/why exactly the issue happens.
Be prepared that this will increase the log size significantly. You may only want to do this shortly before FTL is known to crash (e.g. when going to bed today).
Thanks and sorry for the continued delay. Your last log was still somewhat inconclusive. Unfortunately, this happens often on the ARM platform and there isn't really something we can do about it[^1]. Typically, I ask users to attach a debugger to FTL in this case, however, this won't work in your case as the crash happens soon after a restart of FTL which would dis- and then not reconnect the debugger.
The only solution seems to be to prepared a special version that will log some (actually a lot) more debugging lines and then move on slowly from here. Please run
pihole checkout ftl fix/mysterious_crash
and report the new log. It should be sufficient if you include some (let's say roughly 20 lines) above the
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
----------------------------> FTL crashed! <----------------------------
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
lines. You could do this and securely upload it via
grep --before-context=100 "FTL crashed!" | pihole tricorder
If you decide to send it through tricorder, please provide the link you see so we can access it (only approved Pi-hole developers can access the tokens).
Hopefully, we will get enough information to be able to narrow it down afterwards.
[^1]: See here for further details. We already have both -funwind-tables and -fasynchronous-unwind-tables options enabled for years, this isn't the solution.
Uploaded: https://tricorder.pi-hole.net/AO5euttP/ Below lines here:
[2022-04-03 04:26:19.952 12591M] !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! [2022-04-03 04:26:19.952 12591M] ----------------------------> FTL crashed! <---------------------------- [2022-04-03 04:26:19.952 12591M] !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! [2022-04-03 04:26:19.952 12591M] Please report a bug at https://github.com/pi-hole/FTL/issues [2022-04-03 04:26:19.952 12591M] and include in your report already the following details: [2022-04-03 04:26:19.952 12591M] FTL has been running for 21043 seconds [2022-04-03 04:26:19.952 12591M] FTL branch: fix/mysterious_crash [2022-04-03 04:26:19.952 12591M] FTL version: vDev-7b1c94c [2022-04-03 04:26:19.952 12591M] FTL commit: 7b1c94c [2022-04-03 04:26:19.952 12591M] FTL date: 2022-04-02 16:27:22 +0200 [2022-04-03 04:26:19.952 12591M] FTL user: started as pihole, ended as pihole [2022-04-03 04:26:19.952 12591M] Compiled for armv7hf (compiled on CI) using arm-linux-gnueabihf-gcc (Debian 6.3.0-18) 6.3.0 20170516 [2022-04-03 04:26:19.953 12591M] Process details: MID: 12591 [2022-04-03 04:26:19.953 12591M] PID: 12591 [2022-04-03 04:26:19.953 12591M] TID: 12591 [2022-04-03 04:26:19.953 12591M] Name: pihole-FTL [2022-04-03 04:26:19.956 12591M] Received signal: Segmentation fault [2022-04-03 04:26:19.956 12591M] at address: 0x2a [2022-04-03 04:26:19.956 12591M] with code: SEGV_MAPERR (Address not mapped to object) [2022-04-03 04:26:19.957 12591M] Backtrace: [2022-04-03 04:26:19.957 12591M] B[0000]: /usr/bin/pihole-FTL(generate_backtrace+0x29) [0x4514ce] [2022-04-03 04:26:20.132 12591M] L[0000]: /__w/FTL/FTL/src/signals.c:99 [2022-04-03 04:26:20.136 12591M] B[0001]: /usr/bin/pihole-FTL(+0x41882) [0x451882] [2022-04-03 04:26:20.171 12591M] L[0001]: /__w/FTL/FTL/src/signals.c:242 [2022-04-03 04:26:20.175 12591M] B[0002]: /lib/arm-linux-gnueabihf/libc.so.6(__default_rt_sa_restorer+0) [0x76c94120] [2022-04-03 04:26:20.175 12591M] ------ Listing content of directory /dev/shm ------ [2022-04-03 04:26:20.175 12591M] File Mode User:Group Size Filename [2022-04-03 04:26:20.175 12591M] rwxrwxrwx root:root 260 . [2022-04-03 04:26:20.176 12591M] rwxr-xr-x root:root 4K .. [2022-04-03 04:26:20.176 12591M] rw------- pihole:pihole 4K FTL-per-client-regex [2022-04-03 04:26:20.176 12591M] rw------- pihole:pihole 12K FTL-dns-cache [2022-04-03 04:26:20.176 12591M] rw------- pihole:pihole 12K FTL-overTime [2022-04-03 04:26:20.177 12591M] rw------- pihole:pihole 2M FTL-queries [2022-04-03 04:26:20.177 12591M] rw------- pihole:pihole 160K FTL-upstreams [2022-04-03 04:26:20.177 12591M] rw------- pihole:pihole 684K FTL-clients [2022-04-03 04:26:20.177 12591M] rw------- pihole:pihole 41K FTL-domains [2022-04-03 04:26:20.177 12591M] rw------- pihole:pihole 82K FTL-strings [2022-04-03 04:26:20.178 12591M] rw------- pihole:pihole 12 FTL-settings [2022-04-03 04:26:20.178 12591M] rw------- pihole:pihole 240 FTL-counters [2022-04-03 04:26:20.178 12591M] rw------- pihole:pihole 56 FTL-lock [2022-04-03 04:26:20.178 12591M] --------------------------------------------------- [2022-04-03 04:26:20.178 12591M] Please also include some lines from above the !!!!!!!!! header. [2022-04-03 04:26:20.178 12591M] Thank you for helping us to improve our FTL engine! [2022-04-03 04:26:20.178 12591M] Waiting for threads to join [2022-04-03 04:26:20.179 12591M] Thread telnet-IPv4 (0) is idle, terminating it. [2022-04-03 04:26:20.179 12591M] Thread telnet-IPv6 (1) is idle, terminating it. [2022-04-03 04:26:20.179 12591M] Thread telnet-socket (2) is idle, terminating it. [2022-04-03 04:26:20.234 12591/T12595] Terminating database thread [2022-04-03 04:26:20.235 12591M] Thread housekeeper (4) is idle, terminating it. [2022-04-03 04:26:20.236 12591M] Thread DNS client (5) is idle, terminating it. [2022-04-03 04:26:20.236 12591M] All threads joined [2022-04-03 04:26:20.237 12591M] SQLite3 message: file unlinked while open: /etc/pihole/gravity.db (28) [2022-04-03 04:26:20.259 12591M] ########## FTL terminated after 5h 50m 43s (code 1)! ##########
Sorry for the long silence, a lot has come in my personal way and I haven't found more time to debug this. The last thing I did was checking your debug log (before it expired) but, unfortunately, it didn't contain anything that brought me closer to the root of the issue.
Meanwhile, a new FTL version was released with a few bug fixes - did you already try to update? If not, please do this with
pihole checkout master
to have everything set back on track. Does the crash happen again after the update?
The next step we'd do is attaching a debugger to FTL which should, hopefully, be able to get a more precise crash feedback. All necessary steps can be found here https://docs.pi-hole.net/ftldns/debugging/ - if you have any questions, don't hesitate to ask. And sorry once again for the massive delay.
Yes, it still crashes with latest version. Output from the debugger: `Thread 1 "pihole-FTL" received signal SIGHUP, Hangup.
Thread 1 "pihole-FTL" received signal SIGSEGV, Segmentation fault. __GI___libc_free (mem=0x2e) at malloc.c:3093 3093 malloc.c: No such file or directory. (gdb) Continuing. [Detaching after fork from child process 17715] [New Thread 0x72eff440 (LWP 17717)] [Thread 0x72eff440 (LWP 17717) exited] [Detaching after fork from child process 17722]
Thread 2 "telnet-IPv4" received signal SIG32, Real-time event 32. [Thread 0x7643c440 (LWP 18104) exited]
Thread 3 "telnet-IPv6" received signal SIG32, Real-time event 32. [Thread 0x75c3b440 (LWP 18105) exited]
Thread 4 "telnet-socket" received signal SIG32, Real-time event 32. [Thread 0x7543a440 (LWP 18106) exited]
Thread 5 "database" received signal SIG32, Real-time event 32. [Thread 0x74c39440 (LWP 18107) exited]
Thread 6 "housekeeper" received signal SIG32, Real-time event 32. [Thread 0x74438440 (LWP 18108) exited]
Thread 7 "DNS client" received signal SIG32, Real-time event 32. [Thread 0x73c37440 (LWP 18109) exited] [Inferior 1 (process 18103) exited with code 01]
(gdb) backtrace No stack. `
Okay, thanks. This looks promising. However, you should have run backtrace at the time of the crash:
Thread 1 "pihole-FTL" received signal SIGSEGV, Segmentation fault. __GI___libc_free (mem=0x2e) at malloc.c:3093 3093 malloc.c: No such file or directory. (gdb) Continuing.
As you continued instead, FTL wrote its debug log and exited normally. This is also the reason why your final backtrace didn't return anything useful - FTL had already shutdown and exited:
[Inferior 1 (process 18103) exited with code 01]
When you run backtrace directly after the SIGSEGV report, we should get what we need to fix this.
I precisely followed instructions from the page you provided - attached gdb to the process and immediately resumed its execution by running continue long before it crashed. I didn't continue'd execution interactively after the process crashed - this happens around 4AM. I guess we need to stop/break the execution on crash and then perform backtrace as the process is still there, but I'm not familiar with gdb.
I ran the pihole -g with attached debugger and this time it didn't continue so I've managed to obtain backtrace. Here it is:
Thread 1 "pihole-FTL" received signal SIGHUP, Hangup.
Thread 1 "pihole-FTL" received signal SIGSEGV, Segmentation fault.
__GI___libc_free (mem=0x2e) at malloc.c:3093
3093 malloc.c: No such file or directory.
(gdb) backtrace
#0 __GI___libc_free (mem=0x2e) at malloc.c:3093
#1 0x004de358 in dhcp_netid_free (nid=0x7ecbb880) at /__w/FTL/FTL/src/dnsmasq/option.c:1114
#2 dhcp_netid_list_free (netid=0x0) at /__w/FTL/FTL/src/dnsmasq/option.c:1145
#3 dhcp_config_free (config=0xd76bb0) at /__w/FTL/FTL/src/dnsmasq/option.c:1163
#4 0x004e6934 in clear_dynamic_conf () at /__w/FTL/FTL/src/dnsmasq/option.c:5392
#5 reread_dhcp () at /__w/FTL/FTL/src/dnsmasq/option.c:5425
#6 0x004cc618 in clear_cache_and_reload (now=1653217756) at /__w/FTL/FTL/src/dnsmasq/dnsmasq.c:1745
#7 0x004cdde4 in async_event (now=1653217756, pipe=10) at /__w/FTL/FTL/src/dnsmasq/dnsmasq.c:1490
#8 main_dnsmasq (argc=<optimized out>, argv=<optimized out>) at /__w/FTL/FTL/src/dnsmasq/dnsmasq.c:1226
#9 0x0049aa32 in main (argc=<optimized out>, argv=<optimized out>) at /__w/FTL/FTL/src/main.c:112
Thanks, this looks really helpful. The crash is happening here https://github.com/pi-hole/FTL/blob/4bb0bfe939cc43c23639163deaf15a218e692acb/src/dnsmasq/option.c#L1114 which gives us something to look at.
Together with your crash log from above
[2022-04-03 04:26:19.956 12591M] Received signal: Segmentation fault [2022-04-03 04:26:19.956 12591M] at address: 0x2a
and also
__GI___libc_free (mem=0x2e)
this shows that always the same (or at least very similar) issue happens. Investigating this may be tricky, however, it looks like we have to search for a case where ->net is left uninitialized. I'll come back to you.
@pewu78 Could you upload another debug log for us using pihole -d ? I would like to look again at your DHCP configuration.
We've been discussing and looking at this bug but it doesn't seem clear where it comes from, so far. As it is located in the embedded code of the dnsmasq resolver which is not documented/commented at all doesn't really make things easier here.
-
You said it happens every Sunday when gravity runs, but can you also force the crash happening when you run
sudo killall -HUP pihole-FTLon your system?
-
Please run
pihole checkout ftl fix/dhcp_netid_freeon your system. This will not yet fix the crash, however, it should give us valuable insight into where the invalid netid comes from that causes the crash eventually. Please extract the relevant lines by running a command like
grep -E "dhcp_netid_create|dhcp_netid_free|LOPT_NAME_MATCH" /var/log/pihole-FTL.logPossibly upload it directly to the Pi-hole servers using
grep -E "dhcp_netid_create|dhcp_netid_free|LOPT_NAME_MATCH" /var/log/pihole-FTL.log | pihole tricorder
- It didn't crash when sending HUP to pihole-FTL now. Last time it crashed only at the end of pihole -g command process (ran manually) and during weekly update, which was today at 4:19.
- Did it, https://tricorder.pi-hole.net/B0JjET14/. I tried few times both options from step 1 but oddly couldn't make it crash. Finally switched back to master (5.15), and it also survived. Don't know what to think about it.
Everything seems normal in the log you uploaded. So it seems we have to wait until the next crash happens on the special branch
Again it din't crash on scheduled update Gratity task. Still using fix/dhcp_netid_free branch.
Well ... when adding print statements here and there fixes it, then this typically points towards a really difficult bug possibly caused by branch prediction on paths that now have been ignored before (because the compiler thought this is not necessary) but now forced to be taken (because we print something). Let's monitor it for one or two more weeks and when this really proves to be stable, we can again invest more thoughts into how this could be made permanent (without logging a hell to the logfile).
Running fine so far, again passed todays update. Not too much logging either - about 6 entries of dhcp_netid_free() and 8 dhcp_netid_create() during this operation, none outside of it.
Today and last Sunday wasn't so good, pihole-FTL process was gone while pihole status showed:
[✓] FTL is listening on port
[✓] UDP (IPv4)
[✓] TCP (IPv4)
[✓] UDP (IPv6)
[✓] TCP (IPv6)
[✓] Pi-hole blocking is enabled
Note the missing port. Last logged messages in pihole-FTL.log:
[2022-07-03 03:02:48.878 30407M] Resizing "FTL-dns-cache" from 151552 to (9728 * 16) == 155648 (/dev/shm: 3.4MB used, 484.0MB total, FTL uses 3.4MB)
[2022-07-03 03:10:07.532 30407M] Reloading DNS cache
[2022-07-03 03:10:07.680 30407/T30411] Notice: Database size is 632.78 MB, deleted 64 rows
[2022-07-03 03:10:07.683 30407M] dhcp_netid_free(): Setting nid 0xf75c48 to 0x7e986880
[2022-07-03 03:10:07.683 30407M] dhcp_netid_free(): Freeing tmp = 0xf75c48
[2022-07-03 03:10:07.683 30407M] dhcp_netid_free(): Freeing tmp->net = 0xf75c58
[2022-07-03 03:10:07.683 30407M] dhcp_netid_free(): Setting nid 0x7e986880 to 0x7e9868b0
[2022-07-03 03:10:07.683 30407M] dhcp_netid_free(): Freeing tmp = 0x7e986880
[2022-07-03 03:10:07.684 30407M] dhcp_netid_free(): Freeing tmp->net = 0x652130
Okay, so it was still alive but not reacting to anything? I'm really sorry we're still not closer to a solution here. The code we added to trace the crash let us onto a different path where no crash is happening anymore. Could you test again with the latest release that has received some fixes (although nothing really into your direction)? You should be able to get it through pihole -up in a few minutes. I just updated the branch I've prepared for you manually to the latest version.
Not alive, the process is gone without any error messages in logs.
Updated to the latest release, attached debugger and ran pihole -g:
Attaching to process 31310
[New LWP 31311]
[New LWP 31312]
[New LWP 31313]
[New LWP 31314]
[New LWP 31315]
[New LWP 31316]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
0x76dffcc0 in fts_build (sp=0xffffffff, type=5) at fts.c:639
639 fts.c: No such file or directory.
(gdb) continue
Continuing.
[Detaching after fork from child process 29535]
[Detaching after fork from child process 29537]
[Detaching after fork from child process 30187]
[Detaching after fork from child process 30189]
[Detaching after fork from child process 30372]
[Detaching after fork from child process 30374]
[Detaching after fork from child process 30391]
[Detaching after fork from child process 30393]
[Detaching after fork from child process 30419]
[Detaching after fork from child process 30421]
Thread 1 "pihole-FTL" received signal SIGHUP, Hangup.
[Detaching after fork from child process 30439]
Thread 1 "pihole-FTL" received signal SIGABRT, Aborted.
0x76d5ef14 in __GI___open_catalog (cat_name=0x1 <error: Cannot access memory at address 0x1>, nlspath=<optimized out>, env_var=0x2 <error: Cannot access memory at address 0x2>, catalog=0x0) at open_catalog.c:145
145 open_catalog.c: No such file or directory.
(gdb) backtrace
#0 0x76d5ef14 in __GI___open_catalog (cat_name=0x1 <error: Cannot access memory at address 0x1>, nlspath=<optimized out>, env_var=0x2 <error: Cannot access memory at address 0x2>, catalog=0x0) at open_catalog.c:145
#1 0xfffffffe in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) continue
Continuing.
Unable to fetch general registers.: No such process.
Unable to fetch general registers.: No such process.
(gdb) [Thread 0x73c4e440 (LWP 31316) exited]
[Thread 0x7444f440 (LWP 31315) exited]
[Thread 0x74c50440 (LWP 31314) exited]
[Thread 0x75451440 (LWP 31313) exited]
[Thread 0x76453440 (LWP 31311) exited]
[Thread 0x76fca040 (LWP 31310) exited]
Continuing.
Unable to fetch general registers.: No such process.
This happens after
[✓] Flushing DNS cache
[✓] Cleaning up stray matter
and after resuming in gdb with continue:
[✓] FTL is listening on port
[✓] UDP (IPv4)
[✓] TCP (IPv4)
[✓] UDP (IPv6)
[✓] TCP (IPv6)
- no process, no port. FTL.log shows only this:
[2022-07-14 16:36:13.416 31310M] Reloading DNS cache
[2022-07-14 16:36:13.484 31310M] dhcp_netid_free(): Setting nid 0xe7c410 to 0x7ea76880
[2022-07-14 16:36:13.484 31310M] dhcp_netid_free(): Freeing tmp = 0xe7c410
[2022-07-14 16:36:13.484 31310M] dhcp_netid_free(): Freeing tmp->net = 0xe7cfa8
[2022-07-14 16:36:13.484 31310M] dhcp_netid_free(): Setting nid 0x7ea76880 to 0x7ea768b0
[2022-07-14 16:36:13.484 31310M] dhcp_netid_free(): Freeing tmp = 0x7ea76880
[2022-07-14 16:36:13.484 31310M] dhcp_netid_free(): Freeing tmp->net = 0x635130
This issue is stale because it has been open 30 days with no activity. Please comment or update this issue or it will be closed in 5 days.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
@pewu78 Could you try with the most recent FTL release (pihole checkout master)? We have simplified quite a few internal routines and removed a few oddities. Your issue might be fixed, too.