fix(remote-config): poll for new config after unblocking SIGVTALRM to fix flaky valgrind test#3717
Open
fix(remote-config): poll for new config after unblocking SIGVTALRM to fix flaky valgrind test#3717
Conversation
|
✨ Fix all issues with BitsAI or with Cursor
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #3717 +/- ##
==========================================
- Coverage 68.74% 68.73% -0.02%
==========================================
Files 166 166
Lines 19030 19030
Branches 1797 1797
==========================================
- Hits 13082 13080 -2
- Misses 5132 5135 +3
+ Partials 816 815 -1
Flags with carried forward coverage won't be shown. Click here to find out more. Continue to review full report in Codecov by Sentry.
🚀 New features to boost your workflow:
|
Collaborator
|
What about and you can put |
…der valgrind On Linux, unblocking SIGVTALRM causes immediate delivery if it was pending, which triggers remote config processing via dd_vm_interrupt. However, valgrind intercepts SIGVTALRM for its own timing, making signal delivery unreliable and causing the live debugger probe installation to time out in CI valgrind passes. Introduce REMOTE_CONFIG_NEEDS_POLLING_AFTER_SIGNAL to explicitly call ddtrace_check_for_new_config_now() after unblocking only when needed: - Linux + valgrind: RUNNING_ON_VALGRIND (runtime check, zero overhead otherwise) - Linux without valgrind headers: always 0 (no overhead) - Non-Linux: always 1 (signal delivery not guaranteed) Also add AC_CHECK_HEADERS([valgrind/valgrind.h]) to config.m4 to detect valgrind headers at build time.
cca1f64 to
ef083b8
Compare
Benchmarks [ tracer ]Benchmark execution time: 2026-03-20 17:50:50 Comparing candidate commit ef083b8 in PR branch Found 1 performance improvements and 3 performance regressions! Performance is the same for 188 metrics, 2 unstable metrics. scenario:ComposerTelemetryBench/benchTelemetryParsing
scenario:MessagePackSerializationBench/benchMessagePackSerialization
scenario:MessagePackSerializationBench/benchMessagePackSerialization-opcache
scenario:SamplingRuleMatchingBench/benchRegexMatching3
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
debugger_enable_dynamic_config.phptfails intermittently in the valgrind CI pass:foo()returns the script filename instead of"dd.dynamic.span", meaning the span probe was not active whenfoo()was called.Root cause:
await_probe_installation()relies onddog_process_remote_configs()being triggered viaSIGVTALRM. Thedd_handle_signalwrapper blocks/unblocksSIGVTALRMaround calls likeusleep(), relying on Linux's immediate pending-signal delivery to fire the config check. Under valgrind,SIGVTALRMdelivery is unreliable (valgrind uses this signal internally), so the probe occasionally isn't installed within the 15s timeout.Fix: Remove the
#ifndef __linux__guard inext/handlers_signal.csoddtrace_check_for_new_config_now()is always called aftersigprocmask(SIG_UNBLOCK). Eachusleep()inawait_probe_installation()now actively polls for pending config instead of depending on signal delivery. In the normal case, the!reread_remote_configurationguard inside that function prevents double-processing.