-
-
Notifications
You must be signed in to change notification settings - Fork 357
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
memory corruption related core dumps #1017
Comments
Can I ask about the compilation? In particular the coredump where it calls the key_cache_insert function in the process_dnskey_response function, and that fails. That seems to look like a miscompilation to me. That happens to me, when I git change to different versions and the dependency tracking is not good; so that the wrong object files are not compiled; causing the compiler to link in code that refers to different layout. This kind of error looks like it. Is the code from a git checkout and after a change in code, did not 'make clean' before making a new compile? Or some other dependency tracking issue, where files are copied or modified and the dates change, and there is a partial or previous compilation? In any case, a clean working directory, or 'make clean', before 'make', that would remove the problem, if the dependency tracking is an issue. I have seen similar issues with miscompilation for using experimental, eg. buggy, compiler options; like new optimizations. It could be good to use |
When we compile unbound it is packaged and the same package is used across Oh, one thing more. We never To be transparent; here are our configure options.
|
Could the program get executed with address debugging? Perhaps that can catch the offending activity. Two options, one is valgrind, run the program using valgrind. Another is to compile with libasan, the address sanitizer, with a configure line like The error can then perhaps be caught at the time when it writes wrongly. Not so much catching it later, when the data is corrupted and a failure happens. This could be much more frequent than that data is corrupted that causes a core dump, like when it overwrites harmlessly. Seeing this kind of error at the time and place where it happens, is a good way to find it, otherwise there are no clues as to where the issue is in the program code. Take care starting the program, the debugging may make it sluggish. The asan configure line references a define for VALGRIND, and this is used to set the hash function in unbound to not cause false positives in the memory detector, even though the address sanitizer is not valgrind, the false positive removal is convenient. |
Describe the bug
The bug has been discussed in unbound maillist.
https://lists.nlnetlabs.nl/pipermail/unbound-users/2024-February/008257.html
Short summary of the circumstances. The coredumps happen in locations that have bad network connectivity.
I have a feeling cache handling has something to do with the issue. Assuming that
is correct it is worthwhile to know following settings are in use.
serve-expired: yes
serve-expired-ttl: 3600
serve-expired-client-timeout: 500
infra-keep-probing: yes
To reproduce
Steps to reproduce the behavior:
Expected behavior
No coredumps.
System:
unbound -V
output:Additional information
Collection of 117 gdb backtraces: some-backtraces.tar.gz
The text was updated successfully, but these errors were encountered: