On stackTrace should provide stack trace for any live thread

[karthiknadig]

microsoft/PTVS#3736

[karthiknadig]

on_stackTrace currently only provides stackTrace for threads that have been suspended. For threads that are not suspended, such as the main thread in the bug above, there is no saved xframes available. We need to set the suspend_policy while setting breakpoints.

[karthiknadig]

The behavior we want is to only break the thread that had the breakpoint. Other threads should continue to run. This is the expected behavior in VSC.

[zooba]

This is not the expected behavior in VS – we will need both.

[karthiknadig]

Agreed, both are needed. So looks like for VS we will have to set the allThreadsStopped in the response to breakpoint hit, and for VSC we should not set that flag. The IDE's can be distinguished using clientId in the initialize request.

[int19h]

We should ask them to make it a feature flag in the protocol in the future, to support other clients.

[karthiknadig]

Even with that flag event order seems to be a problem. If i have a breakpoint set in a worker function, then when the breakpoint is hit, the breakpoint and paused events for worker and main threads can appear in any order. That makes difficult, if not impossible, to make sure that breakpoint is the last event. breakpoint event has to be the final event to ensure VS UI selects that thread while displaying in threads window and control position in the editor window.

Further there are issues with how we handle individual debuggind steps:

1. continue currently continues only the thread that is stopped. Should it continue all the threads? I think it should.
2. Step** : step-in/out/over are currently done per thread. What should be the action applied to other threads?

[zooba]

Can we default to VSC behavior and pass through an init flag from VS to change to “always break/continue all threads” and then handle it all in ptvsd? That may be a useful flag for VSC users too. We may need to get the debug adapter to prefer breakpoint threads over stopped threads when they all come in at once.

[karthiknadig]

@int19h suggested wrapping the code in pydevd where they generate the thread suspended events with start/end events (see pydevd.suspend_all_other_threads usage). This will allow us to solve the problem in a reliable way.

[DonJayamanne]

@karthiknadig @MikhailArkhipov
What's the status of this issue?

[karthiknadig]

This is not done yet. We have following pending items:

1. A way to tell pydevd to suspend all threads on (breakpoint/exception/etc). There is currently a mechanim but that path does not use breakpoint_id's which we rely on.
2. Get a notification from pydev that all threads are suspended. Currently there is only a way to tell if individual threads are suspended. we need a way to tell if all threads are suspended.

[fabioz]

The part related to pydevd is on my todo-list (my current item is path mapping issues across platforms and right after this deal with the thread suspension policy).

[DonJayamanne]

@karthiknadig @fabioz Would be great if we have separate issues for those and linked them in here. That way we know what the pre-requisites are for this issue to be looked at. I.e. easier to track the status of this.

Please add a checked list of dependencies on the top comment, as follows:

• Depends on #xxx
• Depends on #xxx

[fabioz]

Starting to take a look at this.

[fabioz]

After working a bit on how to provide a message saying that all threads are suspended I got into corner cases where this cannot be reliably done because to actually pause a thread some tracing event is required, but by pausing a thread it's possible that we get into situations where this never happens and waiting for such a message would not work (i.e.: it would effectively deadlock).

I'm posting an example below where this happens:

import threading
import time

go_on = threading.Event()
lock = threading.Lock()
counter = 0


def method():
    global counter
    with lock:
        counter += 1
    go_on.wait()
        

threads = [threading.Thread(target=method) for _ in range(3)]

for t in threads:
    t.start()

while counter < 3:
    time.sleep(.1)    

print('breakpoint with suspend_all here')  # Will never be able to suspend all threads if they reached go_on.wait() as no tracing event will be generated for the thread after reaching that point.

go_on.set()

So, not sure how to proceed... the feature requested seems to be getting the stack of threads even if they're not paused, so, maybe the best approach would be actually implementing that feature (creating a GET_THREAD_STACK command which can be used to get the stack for any running thread by using sys._current_frames).

@karthiknadig do you think that's reasonable?

[karthiknadig]

@fabioz We will need the suspend_policy in CMD_SET_BREAK (currently it is only available if we don't use breakpoint_id). That along with GET_THREAD_STACK should be enough.

[fabioz]

@karthiknadig ok, will work on that.

Although I'll only start those next Monday as I ended up chasing a deadlock today -- there's a pull request for it with the fix at: #591 -- I got reports from it when using scapy and attaching the remote debugger, so, it'd be interesting to merge it before another release as I think it's a pretty critical issue.

[karthiknadig]

Following items are pending on ptvsd side:

• Set the flag to suspend all while setting breakpoints
• Pause should send suspend request to all threads
• Continue should send run request to all threads
• Use the new get stack trace pydevd command to retrieve stack for running threads

[DonJayamanne]

Use the new get stack trace pydevd command to retrieve stack for running threads

Can't we use this approach to get stack trace of suspended threads as well. Instead of using the current approach of strong some stack trace into a variable. I.e. request on demand.