Adapter works only with stopOnEntry

[Mte90]

PHP version: 7.3
Xdebug version: 3.0.3
Adapter version: 1.14.9

Your launch.json:

type = 'php',
        request = 'launch',
        name = 'Listen for xdebug',
        port = '9003',
        log = true,
        serverSourceRoot = '/srv/www/',
        localSourceRoot = '/var/www/VVV/www/',

Xdebug php.ini config:

zend_extension=xdebug.so

[XDebug]

xdebug.mode=debug,develop,profile
xdebug.start_with_request=yes
xdebug.client_host=_gateway
xdebug.discover_client_host=0
xdebug.var_display_max_depth=10
xdebug.var_display_max_children=256
xdebug.var_display_max_data=1024
xdebug.output_dir="/tmp"
xdebug.log="/var/log/php/xdebug-remote.log"

; xdebug.collect_return
; Type: boolean, Default value: 0
; This setting, defaulting to Off, controls whether Xdebug should write the return value of function
; calls to the trace files.
xdebug.collect_return = 0

; xdebug.dump.*
; Type: string, Default value: Empty
; * = COOKIE, FILES, GET, POST, REQUEST, SERVER, SESSION. These seven settings control which data
; from the superglobals is shown when an error situation occurs. Each php.ini setting can consist of
; a comma separated list of variables from this superglobal to dump, but make sure you do not add
; spaces in this setting. In order to dump the REMOTE_ADDR and the REQUEST_METHOD when an error
; occurs, add this setting:
;
xdebug.dump.COOKIE = ""
xdebug.dump.FILES = ""
xdebug.dump.GET = ""
xdebug.dump.POST = ""
xdebug.dump.REQUEST = ""
xdebug.dump.SERVER = ""
xdebug.dump.SESSION = ""

; xdebug.dump_globals
; Type: boolean, Default value: 1
; Controls whether the values of the superglobals as defined by the xdebug.dump.* settings would be
; shown or not.
xdebug.dump_globals = 1

; xdebug.dump_once
; Type: boolean, Default value: 1
; Controls whether the values of the superglobals should be dumped on all error situations (set to
; Off) or only on the first (set to On).
xdebug.dump_once = 1

; xdebug.dump_undefined
; Type: boolean, Default value: 0
; If you want to dump undefined values from the superglobals you should set this setting to On,
; otherwise leave it set to Off.
xdebug.dump_undefined = 0

; xdebug.file_link_format
; Type: string, Default value: *empty string* , Introduced in Xdebug 2.1
;
; This setting determines the format of the links that are made in the display of stack traces where
; file names are used. This allows IDEs to set up a link-protocol that makes it possible to go
; directly to a line and file by clicking on the filenames that Xdebug shows in stack traces.
xdebug.file_link_format = ""

; xdebug.idekey
; Type: string, Default value: *complex*
; Controls which IDE Key Xdebug should pass on to the DBGp debugger handler. The default is based on
; environment settings. First the environment setting DBGP_IDEKEY is consulted, then USER and as last
; USERNAME. The default is set to the first environment variable that is found. If none could be
; found the setting has as default ''.
xdebug.idekey = "VVVDEBUG"

; xdebug.max_nesting_level
; Type: integer, Default value: 100
; Controls the protection mechanism for infinite recursion protection. The value of this setting is
; the maximum level of nested functions that are allowed before the script will be aborted.
xdebug.max_nesting_level = 100

; xdebug.profiler_append
; Type: integer, Default value: 0
; When this setting is set to 1, profiler files will not be overwritten when a new request would map
; to the same file (depending on the xdebug.profiler_output_name setting. Instead the file will be
; appended to with the new profile.
xdebug.profiler_append = 0

; xdebug.profiler_output_name
; Type: string, Default value: cachegrind.out.%p
;
; This setting determines the name of the file that is used to dump traces into. The setting
; specifies the format with format specifiers, very similar to sprintf() and strftime(). There are
; several format specifiers that can be used to format the file name.
;
; See the xdebug.trace_output_name documentation for the supported specifiers.
xdebug.profiler_output_name = "cachegrind.out.%t-%s"

; xdebug.show_exception_trace
; Type: integer, Default value: 0
; When this setting is set to 1, Xdebug will show a stack trace whenever an exception is raised -
; even if this exception is actually caught.
xdebug.show_exception_trace = 0

; xdebug.show_local_vars
; Type: integer, Default value: 0
; When this setting is set to something != 0 Xdebug's generated stack dumps in error situations will
; also show all variables in the top-most scope. Beware that this might generate a lot of
; information, and is therefore turned off by default.
xdebug.show_local_vars = 0

; xdebug.trace_format
; Type: integer, Default value: 0
; The format of the trace file.
;
; See the introduction of Function Traces for a few examples.
xdebug.trace_format = 0

; xdebug.trace_options
; Type: integer, Default value: 0
; When set to '1' the trace files will be appended to, instead of being overwritten in subsequent
; requests.
xdebug.trace_options = 0

; Type: string, Default value: trace.%c
;
; This setting determines the name of the file that is used to dump traces into. The setting
; specifies the format with format specifiers, very similar to sprintf() and strftime(). There are
; several format specifiers that can be used to format the file name. The '.xt' extension is always
; added automatically.
xdebug.trace_output_name = "trace.%c"

; xdebug.var_display_max_children
; Type: integer, Default value: 128
; Controls the amount of array children and object's properties are shown when variables are
; displayed with either xdebug_var_dump(), xdebug.show_local_vars or through Function Traces. This
; setting does not have any influence on the number of children that is send to the client through
; the Remote Debugging feature.
xdebug.var_display_max_children = -1

; xdebug.var_display_max_data
; Type: integer, Default value: 512
; Controls the maximum string length that is shown when variables are displayed with either
; xdebug_var_dump(), xdebug.show_local_vars or through Function Traces. This setting does not have
; any influence on the amount of data that is send to the client through the Remote Debugging
; feature.
xdebug.var_display_max_data = -1

; xdebug.var_display_max_depth
; Type: integer, Default value: 3
; Controls how many nested levels of array elements and object properties are when variables are
; displayed with either xdebug_var_dump(), xdebug.show_local_vars or through Function Traces. This
; setting does not have any influence on the depth of children that is send to the client through the
; Remote Debugging feature.
xdebug.var_display_max_depth = -1

Xdebug logfile (from setting xdebug.remote_log in php.ini):

[5936] Log opened at 2021-03-11 10:52:56.721076
[5936] [Step Debug] INFO: Connecting to configured address/port: _gateway:9003.
[5936] [Step Debug] INFO: Connected to debugging client: _gateway:9003 (through xdebug.client_host/xdebug.client_port). :-)
[5936] [Step Debug] -> <init xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" fileuri="file:///srv/www/glossary/public_html/index.php" language="PHP" xdebug:language_version="7.3.27-9+ubuntu18.04.1+deb.sury.org+1" protocol_version="1.0" appid="5936" idekey="VVVDEBUG"><engine version="3.0.3"><![CDATA[Xdebug]]></engine><author><![CDATA[Derick Rethans]]></author><url><![CDATA[https://xdebug.org]]></url><copyright><![CDATA[Copyright (c) 2002-2021 by Derick Rethans]]></copyright></init>

[5936] [Step Debug] <- breakpoint_list -i 1
[5936] [Step Debug] -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="breakpoint_list" transaction_id="1"></response>

[5936] [Step Debug] <- breakpoint_set -i 2 -t line -f file:///home/www/VVV/www/glossary/public_html/wp-content/plugins/glossary/glossary.php -n 30
[5936] [Step Debug] -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="breakpoint_set" transaction_id="2" id="59360009"></response>

[5936] [Step Debug] <- breakpoint_list -i 3
[5936] [Step Debug] -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="breakpoint_list" transaction_id="3"><breakpoint type="line" filename="file:///home/www/VVV/www/glossary/public_html/wp-content/plugins/glossary/glossary.php" lineno="30" state="enabled" hit_count="0" hit_value="0" id="59360009"></breakpoint></response>

[5936] [Step Debug] <- breakpoint_set -i 4 -t exception -x *
[5936] [Step Debug] -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="breakpoint_set" transaction_id="4" id="59360010"></response>

[5936] [Step Debug] <- run -i 5
[5874] Log opened at 2021-03-11 10:52:57.323745
[5874] [Step Debug] INFO: Connecting to configured address/port: _gateway:9003.
[5874] [Step Debug] INFO: Connected to debugging client: _gateway:9003 (through xdebug.client_host/xdebug.client_port). :-)
[5874] [Step Debug] -> <init xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" fileuri="file:///srv/www/glossary/public_html/wp-cron.php" language="PHP" xdebug:language_version="7.3.27-9+ubuntu18.04.1+deb.sury.org+1" protocol_version="1.0" appid="5874" idekey="VVVDEBUG"><engine version="3.0.3"><![CDATA[Xdebug]]></engine><author><![CDATA[Derick Rethans]]></author><url><![CDATA[https://xdebug.org]]></url><copyright><![CDATA[Copyright (c) 2002-2021 by Derick Rethans]]></copyright></init>

[5874] [Step Debug] <- breakpoint_list -i 1
[5874] [Step Debug] -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="breakpoint_list" transaction_id="1"></response>

[5874] [Step Debug] <- breakpoint_set -i 2 -t line -f file:///home/www/VVV/www/glossary/public_html/wp-content/plugins/glossary/glossary.php -n 30
[5874] [Step Debug] -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="breakpoint_set" transaction_id="2" id="58740010"></response>

[5874] [Step Debug] <- breakpoint_list -i 3
[5874] [Step Debug] -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="breakpoint_list" transaction_id="3"><breakpoint type="line" filename="file:///home/www/VVV/www/glossary/public_html/wp-content/plugins/glossary/glossary.php" lineno="30" state="enabled" hit_count="0" hit_value="0" id="58740010"></breakpoint></response>

[5874] [Step Debug] <- breakpoint_set -i 4 -t exception -x *
[5874] [Step Debug] -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="breakpoint_set" transaction_id="4" id="58740011"></response>

[5874] [Step Debug] <- run -i 5
[5874] [Step Debug] -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="run" transaction_id="5" status="stopping" reason="ok"></response>

[5874] [Step Debug] <- stop -i 6
[5874] [Step Debug] -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="stop" transaction_id="6" status="stopped" reason="ok"></response>

[5874] Log closed at 2021-03-11 10:52:57.617396

[5936] [Step Debug] -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="run" transaction_id="5" status="stopping" reason="ok"></response>

[5936] [Step Debug] <- breakpoint_list -i 6
[5936] [Step Debug] -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="breakpoint_list" transaction_id="6"><breakpoint type="line" filename="file:///home/www/VVV/www/glossary/public_html/wp-content/plugins/glossary/glossary.php" lineno="30" state="enabled" hit_count="0" hit_value="0" id="59360009"></breakpoint><breakpoint type="exception" exception="*" state="enabled" hit_count="0" hit_value="0" id="59360010"></breakpoint></response>

[5936] [Step Debug] <- breakpoint_list -i 7
[5936] [Step Debug] -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="breakpoint_list" transaction_id="7"><breakpoint type="line" filename="file:///home/www/VVV/www/glossary/public_html/wp-content/plugins/glossary/glossary.php" lineno="30" state="enabled" hit_count="0" hit_value="0" id="59360009"></breakpoint><breakpoint type="exception" exception="*" state="enabled" hit_count="0" hit_value="0" id="59360010"></breakpoint></response>

[5936] [Step Debug] <- stop -i 8
[5936] [Step Debug] -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="stop" transaction_id="8" status="stopped" reason="ok"></response>

[5936] Log closed at 2021-03-11 10:53:02.640501

Adapter logfile (from setting "log": true in launch.json):

[ DEBUG ] 2021-03-11T11:53:42Z+0100 ] /home/mte90/.vim/plugged/nvim-dap/lua/dap.lua:836 ]	{
  body = {
    category = "console",
    output = "new connection 8\n"
  },
  event = "output",
  seq = 116,
  type = "event"
}
[ DEBUG ] 2021-03-11T11:53:42Z+0100 ] /home/mte90/.vim/plugged/nvim-dap/lua/dap.lua:836 ]	{
  body = {
    category = "console",
    output = "<- threadEvent\nThreadEvent {\n  seq: 0,\n  type: 'event',\n  event: 'thread',\n  body: { reason: 'started', threadId: 8 }\n}\n\n"
  },
  event = "output",
  seq = 117,
  type = "event"
}
[ DEBUG ] 2021-03-11T11:53:42Z+0100 ] /home/mte90/.vim/plugged/nvim-dap/lua/dap.lua:836 ]	{
  body = {
    reason = "started",
    threadId = 8
  },
  event = "thread",
  seq = 118,
  type = "event"
}
[ DEBUG ] 2021-03-11T11:53:42Z+0100 ] /home/mte90/.vim/plugged/nvim-dap/lua/dap.lua:836 ]	{
  body = {
    category = "console",
    output = "<- initializedEvent\nInitializedEvent { seq: 0, type: 'event', event: 'initialized' }\n\n"
  },
  event = "output",
  seq = 119,
  type = "event"
}
[ DEBUG ] 2021-03-11T11:53:42Z+0100 ] /home/mte90/.vim/plugged/nvim-dap/lua/dap.lua:836 ]	{
  event = "initialized",
  seq = 120,
  type = "event"
}
[ DEBUG ] 2021-03-11T11:53:42Z+0100 ] /home/mte90/.vim/plugged/nvim-dap/lua/dap.lua:1006 ]	"request"	{
  arguments = {
    breakpoints = { {
        line = 30
      } },
    lines = { 30 },
    source = {
      name = "glossary.php",
      path = "/home/www/VVV/www/glossary/public_html/wp-content/plugins/glossary/glossary.php"
    }
  },
  command = "setBreakpoints",
  seq = 23,
  type = "request"
}
[ DEBUG ] 2021-03-11T11:53:42Z+0100 ] /home/mte90/.vim/plugged/nvim-dap/lua/dap.lua:836 ]	{
  body = {
    category = "console",
    output = "-> setBreakpointsRequest\n{\n  seq: 23,\n  arguments: {\n    source: {\n      name: 'glossary.php',\n      path: '/home/www/VVV/www/glossary/public_html/wp-content/plugins/glossary/glossary.php'\n    },\n    breakpoints: [ { line: 30 } ],\n    lines: [ 30 ]\n  },\n  type: 'request',\n  command: 'setBreakpoints'\n}\n\n"
  },
  event = "output",
  seq = 121,
  type = "event"
}
[ DEBUG ] 2021-03-11T11:53:42Z+0100 ] /home/mte90/.vim/plugged/nvim-dap/lua/dap.lua:836 ]	{
  body = {
    category = "console",
    output = "<- setBreakpointsResponse\nResponse {\n  seq: 0,\n  type: 'response',\n  request_seq: 23,\n  command: 'setBreakpoints',\n  success: true,\n  body: { breakpoints: [ { verified: true, line: 30 } ] }\n}\n\n"
  },
  event = "output",
  seq = 122,
  type = "event"
}
[ DEBUG ] 2021-03-11T11:53:42Z+0100 ] /home/mte90/.vim/plugged/nvim-dap/lua/dap.lua:836 ]	{
  body = {
    breakpoints = { {
        line = 30,
        verified = true
      } }
  },
  command = "setBreakpoints",
  request_seq = 23,
  seq = 123,
  success = true,
  type = "response"
}
[ DEBUG ] 2021-03-11T11:53:42Z+0100 ] /home/mte90/.vim/plugged/nvim-dap/lua/dap.lua:1006 ]	"request"	{
  arguments = {
    filters = { "*" }
  },
  command = "setExceptionBreakpoints",
  seq = 24,
  type = "request"
}
[ DEBUG ] 2021-03-11T11:53:42Z+0100 ] /home/mte90/.vim/plugged/nvim-dap/lua/dap.lua:836 ]	{
  body = {
    category = "console",
    output = "-> setExceptionBreakpointsRequest\n{\n  seq: 24,\n  arguments: { filters: [ '*' ] },\n  type: 'request',\n  command: 'setExceptionBreakpoints'\n}\n\n"
  },
  event = "output",
  seq = 124,
  type = "event"
}
[ DEBUG ] 2021-03-11T11:53:42Z+0100 ] /home/mte90/.vim/plugged/nvim-dap/lua/dap.lua:836 ]	{
  body = {
    category = "console",
    output = "<- setExceptionBreakpointsResponse\nResponse {\n  seq: 0,\n  type: 'response',\n  request_seq: 24,\n  command: 'setExceptionBreakpoints',\n  success: true\n}\n\n"
  },
  event = "output",
  seq = 125,
  type = "event"
}
[ DEBUG ] 2021-03-11T11:53:42Z+0100 ] /home/mte90/.vim/plugged/nvim-dap/lua/dap.lua:836 ]	{
  command = "setExceptionBreakpoints",
  request_seq = 24,
  seq = 126,
  success = true,
  type = "response"
}
[ DEBUG ] 2021-03-11T11:53:42Z+0100 ] /home/mte90/.vim/plugged/nvim-dap/lua/dap.lua:1006 ]	"request"	{
  command = "configurationDone",
  seq = 25,
  type = "request"
}
[ DEBUG ] 2021-03-11T11:53:42Z+0100 ] /home/mte90/.vim/plugged/nvim-dap/lua/dap.lua:836 ]	{
  body = {
    category = "console",
    output = "-> configurationDoneRequest\n{ seq: 25, type: 'request', command: 'configurationDone' }\n\n"
  },
  event = "output",
  seq = 127,
  type = "event"
}
[ DEBUG ] 2021-03-11T11:53:47Z+0100 ] /home/mte90/.vim/plugged/nvim-dap/lua/dap.lua:836 ]	{
  body = {
    category = "console",
    output = "<- configurationDoneResponse\nResponse {\n  seq: 0,\n  type: 'response',\n  request_seq: 25,\n  command: 'configurationDone',\n  success: true\n}\n\n"
  },
  event = "output",
  seq = 128,
  type = "event"
}
[ DEBUG ] 2021-03-11T11:53:47Z+0100 ] /home/mte90/.vim/plugged/nvim-dap/lua/dap.lua:836 ]	{
  command = "configurationDone",
  request_seq = 25,
  seq = 129,
  success = true,
  type = "response"
}
[ DEBUG ] 2021-03-11T11:53:47Z+0100 ] /home/mte90/.vim/plugged/nvim-dap/lua/dap.lua:836 ]	{
  body = {
    category = "console",
    output = "<- threadEvent\nThreadEvent {\n  seq: 0,\n  type: 'event',\n  event: 'thread',\n  body: { reason: 'exited', threadId: 8 }\n}\n\n"
  },
  event = "output",
  seq = 130,
  type = "event"
}
[ DEBUG ] 2021-03-11T11:53:47Z+0100 ] /home/mte90/.vim/plugged/nvim-dap/lua/dap.lua:836 ]	{
  body = {
    reason = "exited",
    threadId = 8
  },
  event = "thread",
  seq = 131,
  type = "event"
}

Code snippet to reproduce:
I am using https://github.com/Varying-Vagrant-Vagrants/vvv with the adapter on nvim.

If I turn stopOnEntry:true neovim detect and show the first file (index.php) of WordPress, instead if I turn off that function nothing it is happening as you can see from the log. My idea is that the request is everything ok but somehow the adapter send also the stop command after so it is automatically closed.

Instead if I use my client https://github.com/Mte90/pugdebug everything works also with that option turned off (break on first line). A thing that I noticed that in the page elaboration the request is happening twice.

[zobo]

Before I dig in here, do I understand correctly you are not using this adapter in VSCode but in nvim? I was not aware of this and this has some implications on how I develop things. Thanks.

[Mte90]

Yes as it is an adapter protocol can be used in vim with https://puremourning.github.io/vimspector-web/ or in neovim with https://github.com/mfussenegger/nvim-dap

Those plugins supports a lot of vscode adapters by default.

Anyway my neovim settings are there github.com/mte90/dotfiles

I can hack in the code if needed so just let me know how I can help :-)

[zobo]

Great to hear, alto this introduces complexity for me :)
The problem with the current design is that we try to handle multiple Xdebug/DBGp sessions within one DAP session, presenting each one as a thread.
The part that becomes the problem is that VScode/DAP have one set of breakpoints, Xdebug/DBGp on the other hand can have many sets of them and it becomes impossible to map this things...

What I'm currently working on is #517 a way to initiate multiple DAP sessions, one for each DBGp connections. The way I do this is that I start one DAP were I only listen for connections, then short-circuit back to VSCode extension to start a new DAP session with existing socket connection details... Check that PR for more details.

I'm working on a compatibility mode where the classic (thread) and the new approach would continue to work...

I'll check out your logs and try to setup nvim on my environment.

[Mte90]

I will try those but maybe you can turn this things with config so with vscode don't create issue and for others you can turn off etc.

[zobo]

Hello @Mte90 !

I spent a few days trying to setup neovim and alto frustrating in the end I managed to get a working environment. Because I have a very strange setup (was running nvim and php in WSL/linux, but the DAP adapter on windows) I had some path issues, but in the end breakpoints worked. I then went back to your logs and saw something.

Your config says:

        serverSourceRoot = '/srv/www/',
        localSourceRoot = '/var/www/VVV/www/',

This would mean, that your php process would see the filed under /var/www/VVV/www. However looking at the Xdebug log I see:

[5936] [Step Debug] -> <init xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" fileuri="file:///srv/www/glossary/public_html/index.php" language="PHP" xdebug:language_version="7.3.27-9+ubuntu18.04.1+deb.sury.org+1" protocol_version="1.0" appid="5936" idekey="VVVDEBUG"><engine version="3.0.3"><![CDATA[Xdebug]]></engine><author><![CDATA[Derick Rethans]]></author><url><![CDATA[https://xdebug.org]]></url><copyright><![CDATA[Copyright (c) 2002-2021 by Derick Rethans]]></copyright></init>

file:///srv/www/glossary/public_html/index.php this is your entrypoint as PHP sees it.

The DAP send this breakpoint to Xdebug:
[5936] [Step Debug] <- breakpoint_set -i 2 -t line -f file:///home/www/VVV/www/glossary/public_html/wp-content/plugins/glossary/glossary.php -n 30

Seems to me the config should be:

        serverSourceRoot = '/srv/www/',
        localSourceRoot = '/home/www/VVV/www/',

[Mte90]

I can confirm that works, I am using locally symlinks to that folder...