Fixed the thread list so it correctly updates after the first core thread exists.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@179326 91177308-0d34-0410-b5e6-96231b3b80d8
Fixed SBValueList to have a __str__ function like all other SB classes. Previously this was done as __repr__.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@179327 91177308-0d34-0410-b5e6-96231b3b80d8
Use std::unique_ptr instead of std::auto_ptr.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@179328 91177308-0d34-0410-b5e6-96231b3b80d8
<rdar://problem/13370286>

Fixed a case there the OperatingSystemPython would try to access and play with SBValue objects when the process' public run lock was taken. Prior to this fix, all attempts to run any SBValue functions would fail if run from the private state thread (like updating the thread list). Now we have two run locks, one for public (all threads except the private state thread) and one for private.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@179329 91177308-0d34-0410-b5e6-96231b3b80d8
<rdar://problem/13623698>

This patch fixes the issue that we were using the C stack as a measure of depth of ValueObject hierarchies, in the sense that we were assuming that recursive ValueObject operations would never be deeper than the stack allows.
This assumption is easy to prove wrong, however.
For instance, after ~10k runs through this loop:
struct node
{
	int value;
	node* child;
	node (int x)
	{
		value = x;
		child = nullptr;
	}
};

int main ()
{
	node root(1);
	node* ptr = &root;
	int j = 2;
	while (1)
	{
		ptr->child = new node(j++);
		ptr = ptr->child;
	}
	return 0;
}

the deepmost child object will be deeper than the stack on most architectures, and we would be unable to display it

This checkin fixes the issue by introducing a notion of root of ValueObject hierarchies.
In a couple cases, we have to use an iterative algorithm instead of going to the root because we want to allow deeper customizations (e.g. formats, dynamic values).
While the patch passes our test suite without regressions, it is a good idea to keep eyes open for any unexpected behavior (recursion can be subtle..)
Also, I am hesitant to introduce a test case since failing at this will not just be marked as an "F", but most definitely crash LLDB.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@179330 91177308-0d34-0410-b5e6-96231b3b80d8
Save away the locations at the site we hit and iterate over that collection.  Otherwise the action of one location
could delete the other locations, and that would leave us iterating over a reduced size collection and crash.

<rdar://problem/13592544>


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@179332 91177308-0d34-0410-b5e6-96231b3b80d8
<rdar://problem/13558484>

This makes the dynamic values test case work for both libc++ and libstdcpp



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@179333 91177308-0d34-0410-b5e6-96231b3b80d8