Breakpoint hitting on wrong thread

Hi,

I’m running into an issue on Linux where hitting a breakpoint won’t change the currently selected thread index to that thread:
Notice in this example how the current thread is #1, even though the breakpoint hit on thread #2. I only have one breakpoint set, and thread #2 is the only thread anywhere near that breakpoint.

(lldb) b main.c:21
(lldb) run
Process 12353 stopped
thread #2: tid = 12357, 0x000000000040076a a.out`fn_static(param=0x0000000000000000) + 30 at main.c:21, name = 'a.out', stop reason = breakpoint 1.1
    frame #0: 0x000000000040076a a.out`fn_static(param=0x0000000000000000) + 30 at main.c:21
   18   {
   19           var_static *= 2;
   20           for(;;)
-> 21                   usleep(1); // thread breakpoint
   22   }
   23   
   24   int main (int argc, char const *argv[])
(lldb) thread list
Process 12353 stopped
* thread #1: tid = 12353, 0x00007f0d8e31cd3d libc.so.6`nanosleep + 45, name = 'a.out'
  thread #2: tid = 12357, 0x000000000040076a a.out`fn_static(param=0x0000000000000000) + 30 at main.c:21, name = 'a.out', stop reason = breakpoint 1.1

Somewhat annoyingly, this only fails when inside a unit test, and works fine from the command-line.
Has anyone seen anything like this before?

I haven't seen this.

Set a breakpoint in both of the following functions:

b ThreadList::SetSelectedThreadByID
b ThreadList::SetSelectedThreadByIndexID

You should be able to catch who is setting this incorrectly.

Greg

In POSIXThread.cpp there is a call in BreakNotify() to SetSelectedThreadByID before the stop info gets set to a breakpoint stop. Not that sure if that call is actually needed there, it's not called anywhere in the POSIX/Linux process plugins.

Not sure if this is relevant but on Linux lldb needs to stop the other threads in the inferior with a kill() but I don't think any stop info gets set for those threads.

Matt