diff options
| author | Simon Marchi <simon.marchi@polymtl.ca> | 2021-08-17 15:23:41 -0400 |
|---|---|---|
| committer | Simon Marchi <simon.marchi@polymtl.ca> | 2021-08-17 15:26:10 -0400 |
| commit | c316c0b29d9991a231bdcbab0fcdc51114cddd13 (patch) | |
| tree | ef79c661bc1d87ab11af252bae695b1417eaf478 /gdb/thread.c | |
| parent | 5d9cff510e8c04ded28272ef2121d814f5787a57 (diff) | |
| download | gdb-c316c0b29d9991a231bdcbab0fcdc51114cddd13.zip gdb-c316c0b29d9991a231bdcbab0fcdc51114cddd13.tar.gz gdb-c316c0b29d9991a231bdcbab0fcdc51114cddd13.tar.bz2 | |
gdb: fix thread_step_over_chain_length
If I debug a single-thread program and look at the infrun debug logs, I
see:
[infrun] start_step_over: stealing global queue of threads to step, length = 2
That makes no sense... turns out there's a buglet in
thread_step_over_chain_length, "num" should be initialized to 0. I
think this bug is a leftover from an earlier version of the code (not
merged upstream) that manually walked the list, where the first item was
implicitly counted (hence the 1).
Change-Id: I0af03aa93509aed36528be5076894dc156a0b5ce
Diffstat (limited to 'gdb/thread.c')
| -rw-r--r-- | gdb/thread.c | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/gdb/thread.c b/gdb/thread.c index 8f0584e..a82fb49 100644 --- a/gdb/thread.c +++ b/gdb/thread.c @@ -380,7 +380,7 @@ thread_is_in_step_over_chain (struct thread_info *tp) int thread_step_over_chain_length (const thread_step_over_list &l) { - int num = 1; + int num = 0; for (const thread_info &thread ATTRIBUTE_UNUSED : l) ++num; |