- User Since
- May 10 2016, 10:57 AM (258 w, 13 h)
ready for review
Sun, Apr 18
Wed, Apr 14
Tue, Apr 13
Mon, Apr 12
updated minor python detail
Wed, Apr 7
Tue, Apr 6
Wed, Mar 31
Tue, Mar 30
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.
Mon, Mar 29
Thu, Mar 25
Updates in the diff description
Mar 18 2021
Changed my mind :)
I'll redo this diff in smaller diffs
Mar 15 2021
Mar 5 2021
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.
Mar 4 2021
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.
Feb 4 2021
I don't feel knowledgeable enough to backport the commit, so if you can do
it, it would be great :)
Jan 28 2021
Jan 27 2021
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!
Jan 26 2021
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
rebase and fix compile error on Darwin
Jan 25 2021
I've already submitted a fix, let's see if the buildbot gets fixed
Jan 22 2021
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:
Jan 21 2021
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:
Jan 11 2021
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 :)
Jan 9 2021
Addressed all comments:
Jan 8 2021
Followed all the suggestions:
Jan 7 2021
I'll think about just writing this as tcp sockets. That would for sure be cross platform
I'll follow your recommendations.
Jan 6 2021
Address all comments.
Jan 4 2021
Dec 30 2020
Dec 29 2020
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.
Dec 28 2020