Debugger "crashes"

[felixfbecker]

vscode-php-debug stopped working after VS Code 1.2, see xdebug/vscode-php-debug#39. The debug section and breakpoint markers disappear after the second step over. The requests send by the adapter seem to be completely fine though:

-> nextRequest
{ type: 'request',
  seq: 13,
  command: 'next',
  arguments: { threadId: 1 } }
<- outputEvent
OutputEvent {
  seq: 0,
  type: 'event',
  event: 'output',
  body: { category: 'stdout', output: 'hello' } }
hello
<- stoppedEvent
StoppedEvent {
  seq: 0,
  type: 'event',
  event: 'stopped',
  body: { reason: 'step', threadId: 1, allThreadsStopped: false } }
<- nextResponse
Response {
  seq: 0,
  type: 'response',
  request_seq: 13,
  command: 'next',
  success: true,
  body: { allThreadsContinued: false } }
-> threadsRequest
{ type: 'request', seq: 14, command: 'threads' }
<- threadsResponse
Response {
  seq: 0,
  type: 'response',
  request_seq: 14,
  command: 'threads',
  success: true,
  body: { threads: [ Thread { id: 1, name: 'Request 1 (3:17:24 PM)' } ] } }
-> stackTraceRequest
{ type: 'request',
  seq: 15,
  command: 'stackTrace',
  arguments: { threadId: 1, startFrame: 0, levels: 20 } }
<- stackTraceResponse
Response {
  seq: 0,
  type: 'response',
  request_seq: 15,
  command: 'stackTrace',
  success: true,
  body: 
   { stackFrames: 
      [ StackFrame {
          id: 2,
          source: 
           Source {
             name: 'hello_world.php',
             path: 'C:\\Users\\felix\\git\\OpenSource\\vscode-php-debug\\testproject\\hello_world.php',
             sourceReference: 0 },
          line: 4,
          column: 1,
          name: '{main}' } ] } }
-> scopesRequest
{ type: 'request',
  seq: 16,
  command: 'scopes',
  arguments: { frameId: 2 } }
<- scopesResponse
Response {
  seq: 0,
  type: 'response',
  request_seq: 16,
  command: 'scopes',
  success: true,
  body: 
   { scopes: 
      [ Scope { name: 'Locals', variablesReference: 4, expensive: false },
        Scope { name: 'Superglobals', variablesReference: 5, expensive: false },
        Scope {
          name: 'User defined constants',
          variablesReference: 6,
          expensive: false } ] } }
-> variablesRequest
{ type: 'request',
  seq: 17,
  command: 'variables',
  arguments: { variablesReference: 4 } }
<- variablesResponse
Response {
  seq: 0,
  type: 'response',
  request_seq: 17,
  command: 'variables',
  success: true,
  body: { variables: [] } }

VS Code just doesnt display anything anymore. Could it have something todo with the async events? Sometimes events are sent in between a request and a response

@weinand

[weinand]

@felixfbecker and this problem does not occur in the Insiders release from May 30?

[weinand]

Could this be related to xdebug/vscode-php-debug#37 ?

[felixfbecker]

@weinand I was short on time an didn't test with Insiders release. It might be related to 37, but as I stated there it is a major effort to guarantee this at the adapter implementation level, because every connection can produce an event at any time... As I already I said I think this would fit good for vscode-debugapter to keep a queue of events. Would you accept a PR?

[weinand]

@felixfbecker Yes, I would accept a PR, but before investing into this please verify with a (quick-and-dirty) rearrangement of the nextRequest implementation that this fixes the problem for you.

I don't think that queuing in the in the debugSession implementation is a good approach.

The problem we have to address in the UI is that it should not be possible to flood the debug adapter with many step requests that are queued and result in lag and imprecise stepping behaviour.
For this we track the state of the debugee and enable step and continue requests only when being stopped and pause request when running. This requires that responses and corresponding events arrive in a deterministic (causal) order: events must arrive after the request that enables them has returned its response.

A simple (but not perfect) way to achieve this follows:

Instead of implementing the step and continue requests like this:

    if arguments are ok
        do 'step'
        if no error
            send 'ok' response
        else
            send error
    else
        send error

you could implement them like this:

    if arguments are ok
        send 'ok' response
        do 'step'
    else
        send error

Yes, in the latter case it is not possible to turn a failure of the actual 'step' into an error response.
But the response/event order is correct and it is not necessary to delay (queue) events.

[felixfbecker]

@weinand That would not help because my "threads" (aka connections) are totally independent from each other. While one connection is inside a request/response sequence another connection could totally randomly break and trigger a StoppedEvent.

And in your latter example, how should I handle an error from XDebug if the step failed? There is no way to tell VS Code. I still don't get why Code can't simply accept events at any time, as every request/response has a unique ID to map them together. You shouldn't rely on the order, but map the requests/responses by ID, asynchronously (I do the same when communicating with XDebug). You are putting an unneeded burden on the debug adapter developers... :(

[weinand]

@felixfbecker sure, we are not mapping responses to requests based on order but based on id and asynchronously. That's not the issue here.

The issue is that it is difficult to track the state of a thread if there is only a 'stopped' event, but no corresponding 'running' event.

In that case we have to use the successful reponse of a request that leads to the 'running' state as the 'running' transition.

But if the stopped event triggered by that 'step' or 'continue' request arrives before the request has finished, the causality is reversed.

Explain to me how we should track the state of the thread.

BTW, the ID of requests, responses, and events is not only an ID for mapping responses to requests but it is a sequence number (basically a timestamp) too. That implies causality. You cannot just reorder events and expect that everything still works correctly.

[felixfbecker]

@weinand Alright, that makes sense. I realize the mistake is on my side. I checked back and I can first send the response, then call checkStatus (which will trigger events based on the XDebug response).

One thing though - to be completely sure that the response has been sent, shouldn't you have to use the callback parameter of writetableStream.write() and return a promise from sendResponse()?

[weinand]

@felixfbecker I will check the writetableStream.write() when I'm in the office. Thanks for bringing this up.