Repository navigation
debugger_test.sh: ignore the order of waiting threads - #33
Merged
Merged
Conversation
ptbtall lists waiting threads by wait-list bucket, and the bucket comes from hashing the channel address. The channels in test_barrier() are on the stack, whose addresses differ between gdb and lldb (their inferior environments differ), so the two can list the same waiters in different orders. CI failed this way on master at d4dd7c8 with no code change. Sort each run of waiting threads before comparing. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SR7v9BVsFrHiEhQBSqZmAs
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
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.
CI's debuggers job failed on master at d4dd7c8, a docs-only commit. gdb and lldb listed the two waiting threads at the barrier stop in opposite orders.
ptbtall walks the wait lists by bucket, and the bucket comes from hashing the channel address. The test's channels are on the stack, and the stack addresses differ between gdb and lldb, so the bucket order can differ too. It looks like it only passed before because the addresses happened to hash the same way.
The script now sorts each run of waiting threads before comparing. Running and ready threads keep their order, since the ready list is FIFO. Passes locally with gdb and lldb-22.
🤖 Generated with Claude Code
https://claude.ai/code/session_01SR7v9BVsFrHiEhQBSqZmAs