ready for review

updated minor python detail

Address comments

Some changes:

Address comments

I like that idea, but i'd rather do it in a different patch once we have a second stop event, so that I make sure the entire thing makes sense.

Addresses all issues, following our offline discussion.

Updates in the diff description

Changed my mind :)

I'll redo this diff in smaller diffs

address comment

I think that the mechanism used to show progress should be lock-free and mostly unblocked, as it's merely an observer without side effects within LLDB. So from the last thing you said it seems that SBEvent doesn't like a good solution.

I'm quite happy with it besides the multiple callback thing.

This looks really nice. The only thought I have is that you should accept multiple callbacks instead of only one, as the current implementation discards any existing callback if SetProgressCallback is called twice. I know that it'd be rare that two or more callbacks are registered simultaneously, but it might happen in the future and you could save someone's time by making this a little bit more flexible.

I don't feel knowledgeable enough to backport the commit, so if you can do
it, it would be great :)

Damn, I gotta fix that

I think that's because I'm not running all the tests for Debug builds, as they would timeout. I've noticed that an error is due to the use of capture_output when doing Popen, but I use subprocess in other places as well for this feature, so I want to first set up my environment for using python3.6 and making sure everything works well.

@stella.stamenova , I've just pushed a fix. Let me know if it actually works.

Good to know. I'll work on that right now. Thanks!

I'll send a diff tomorrow morning

@stella.stamenova , is that build a Debug or Release build? I think that will help me determine why it's failing

clang-format

rebase and fix compile error on Darwin

I've already submitted a fix, let's see if the buildbot gets fixed

apply suggestion

Updated based on @jingham's idea, and added an independent test for this.

Jim, thanks for the pointers! I think we are getting close to the issue. After doing what you asked, I found out the following:

I've tried to find a way to move the calls the way you mentioned, but it
doesn't seem trivial.

Sorry for returning late to this diff, but I have some additional information. This is what's happening:

I've done a lightweight test and it seems that the BaseThreadPlan is being asked for the stop reason when the exec happens, but it holds a reference to the thread whose destructor has been called, which causes the crash. On Darwin, as Greg said, the BaseThreadPlan is deleted when the thread changes, so this doesn't happen.
Later this week I'll spend more time gathering logs and I'll share them here in a nice format.

@jingham, friendly ping :)

improve tests

Addressed all comments:

Followed all the suggestions:

I'll think about just writing this as tcp sockets. That would for sure be cross platform

I'll follow your recommendations.

Address all comments.

nit

nit

Updated the description of the diff. It was actually very easy to find a deterministic reproduction of the failure. And the diff is actually minimal now.

improve test