Enable debug mode when debugger is detected #2120
Conversation
…hed. This allows us to debug TCP workers as well as they won't fork Signed-off-by: DL6ER <[email protected]>
…ingdump.txt if debug.gc is true Signed-off-by: DL6ER <[email protected]>
…ssume not being debugged in this case Signed-off-by: DL6ER <[email protected]>
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
There was a problem hiding this comment.
Even after attaching gdb it loggs some vforks. Are those real forks or something else?
(gdb) continue
Continuing.
[Detaching after vfork from child process 735265]
[Detaching after vfork from child process 735267]
[Detaching after vfork from child process 735269]
[Detaching after vfork from child process 735271]
|
Even with this PR, it is expected that other processes we are calling are considered forks - we don't want to debug, e.g., |
Not within the last 10 hours. |
| @@ -1471,3 +1472,82 @@ void print_recycle_list_fullness(void) | |||
| log_info(" Domains: %u/%u (%.2f%%)", recycler->domain.count, RECYCLE_ARRAY_LEN, (double)recycler->domain.count / RECYCLE_ARRAY_LEN * 100.0); | |||
| log_info(" DNS Cache: %u/%u (%.2f%%)", recycler->dns_cache.count, RECYCLE_ARRAY_LEN, (double)recycler->dns_cache.count / RECYCLE_ARRAY_LEN * 100.0); | |||
| } | |||
|
|
|||
| /** | |||
| * @brief Dumps the string table to a temporary file. | |||
There was a problem hiding this comment.
What kind of strings are dumped here? Do we need to make sure that no privacy related information are dumped?
There was a problem hiding this comment.
All strings FTL knows about. Mainly domains, host names, and IP addresses. But it can also be group strings (like 0,1,2,3) or local interface names or MAC addresses (if clients are configured by these).
Debugging is not really concerned about privacy levels, e.g., debug.queries also always prints the full strings as FTL needs them internally to handle to queries correctly. Only API responses and database records are affected by privacy levels.
What does this implement/fix?
During #2112, it became an issue that
gdbis only able to follow one process at a time. This can either be (a) the main process, causing any forks to run unsupervised, or (b) following the new fork, either (b.1) detaching from the main process or (b.2) freezing the main process while the fork is being traced. (a) is the default behavior.All three possibilities are not really what we want. This PR adds a mechanism to detect if the debugger is being attached and - if so - stops forking temporarily until the debugger is again detached. Even when this has a possible performance impact on TCP connections, it allows
gdbto follow the program closely and will help us to debug crashes only becoming visible in TCP forks.Related issue or feature (if applicable): #2112
Pull request in docs with documentation (if applicable): N/A
By submitting this pull request, I confirm the following:
git rebase)Checklist:
developmentalbranch.