SBThread::IsStopped() always returns false on Linux

Subprojects LLDB
1

Hi,

I am running lldb-4.7 that I built from sources on Linux Ubuntu 14.04.

I am using C++ API to debug my program. The program runs into different events: breakpoints I set, signals. But all threads always returnIsStopped() as false in any program state. I traced this call and it seems that the thread state is eStateUnloaded. The only place I found that changes thread state in Thread.cpp is this method:

void

Thread::SetState(StateType state)

{

Mutex::Locker locker(m_state_mutex);

m_state = state;

}

So, I put breakpoint there and it is never hit. I tried to put similar breakpoint in lldb-server, but it seems that the method is not present here:

(gdb) b lldb_private::Target::SetS

SetSectionLoadAddress(std::shared_ptr<lldb_private::Section> const&, unsigned long, bool)

SetSectionUnloaded(std::shared_ptr<lldb_private::Section> const&)

SetSectionUnloaded(std::shared_ptr<lldb_private::Section> const&, unsigned long)

SetStopHookActiveStateByID(unsigned long, bool)

(gdb) b lldb_private::Target::SetState

Function “lldb_private::Target::SetState” not defined.

Make breakpoint pending on future shared library load? (y or [n])

So far, this seems broken to me.

Thanks,
Eugene

2

OOPS, on server I tried wrong class, that’s why the method is not here. Still, client inspects local m_state to make the call, and it is “unloaded” in cases I inspected.

3

Hi,

thanks for the feedback. We are tracking this problem, and we
currently have some tests XFAILed because of this (I don't think the
issue is linux-specific). As a workaround for now, I think you can
assume all threads are stopped if process state is eStateStopped.

cheers,
pl

4

Thread states are broken across all platforms except maybe FreeBSD

5

Until we actually get "keep alive debugging" working in lldb, thread states aren't terribly interesting. If the process is stopped the threads are. For threads, the interesting bit of information is not the thread state but the thread StopInfo. The StateType is pretty crude, it is mostly there to handle the state changes in the debugee, and is not required to carry more information than that.

Not that we shouldn't get this right, but there hasn't been any reason to do so up to now. For now, if the process is stopped you can assume all the threads are as well.

Jim