[xdebug-general] Re: how breakpoints relate to filenames when remote debugging

From: David Bradley <mail.david.bradley[@]gmail.com>
Date: Mon, 14 May 2018 14:40:30 -0600

Hi Derek,

Thanks for the reply. It greatly simplifies the scope of inquiry.
Once I understand the problem I plan to write it up to help others in the
remote-debugging environment.

BTW, The issue is chronic for the zend debugger users as well. I found a
nice conceptual writeup which was helpful as it is similar - but not
identical to xdebug's API. (

*** In looking at the xdebug log file. I am seeing no entries that show
breakpoints being set or cleared. I would expect those events to be
logged, correct?

If you confirm that they should have been present I will turn to my IDE
(Eclipse) to see why it isn't making the calls even though it shows all the
visual activity of breakpoint setting and clearing.

(All other functioning seems to work, eg calling xdebug_break() explicitly
in the code and stepping line by line all works and is logged )

Thanks again for your time

On Monday, 14 May 2018, Derick Rethans <derick[@]xdebug.org> wrote:

> On Wed, 2 May 2018, David Bradley wrote:
> > >From the DBgp docs I gleaned that:
> > 1) (file) breakpoints commands take a filename and a line number
> > 2) file names have to be absolute paths
> > 3) probably shouldn't have spaces (whoever thinks spaces in paths are a
> > good idea is nuts)
> > 4) may have some case sensitivity issues when crossing Windows -> linux
> VM
> > worlds?
> That's all correct.
> > 5) some kind of mapping from server, debugger, and IDE views of filenames
> > is required.
> This is solely an IDE issue. Xdebug does not know anything about
> mappings.
> > Could you give the community an explanation of the steps from a user
> > asking for a breakpoint to be created in an IDE, through all path
> > mappings to the debugger - being careful to identify which component
> > has the responsibility of mapping
> The IDE needs to map. As Xdebug only runs on the server side, it has no
> knowledge of the file paths on the machine where your IDE runs. And the
> IDE (likely) has no idea of the paths on the machine where Xdebug runs.
> It's therefore unfortunately necessary for users to configure this
> mapping in their IDE. For most projects, you would only need to set the
> root.
> > In the general case for remote debugging the root location of the
> > files in the IDE and the webserver are different names and
> > inaccessible to one another (hence the term "remote").
> >
> > If you could also identify the canonical perspective and format of the
> > filenames in the debugger (if there is one)
> It's what PHP reports to Xdebug - often the absolute path name as
> returned by the "realpath" system call. A PHP equivalent function of
> realpath is documented at http://php.net/realpath
> > Moreover (just in case this matters) URLs passed from the webserver are
> not
> > guaranteed to map via a simple root prefix to any file name ( eg "
> > https://foo/inbox" might map to
> > <someroot>/<someintermediatepath>/inbox-xxx.php) - this would mean web
> > URLs are not relevant for breakpoints
> That's correct. Web URLs have no relation to setting breakpoints.
> > Hopefully with this information I will be able to figure out what my
> > IDE is supposed to be doing and configure it correctly according to
> > some methodology rather than from random posts of desperate developers
> You can also have a look at the log files that Xdebug makes if you
> configure xdebug.remote_log
> (https://xdebug.org/docs/all_settings#remote_log) — it will show you
> exactly which commands the IDE sets, which should allow you to see
> whether it does something wrong with file path roots for example.
> cheers,
> Derick
> --
> Like Xdebug? Consider a donation: https://xdebug.org/donate.php,
> or become my Patron: https://www.patreon.com/derickr
> Xdebug | https://xdebug.org | xdebug-general@lists.xdebug.org
> twitter: @derickr and @xdebug
Received on Mon May 14 2018 - 21:40:33 BST

This archive was generated by hypermail 2.2.0 : Mon Jun 25 2018 - 06:00:04 BST