In our development situation we have a single server on which all our developers have their working areas. Because of this, MacGDBp will receive filepaths from xdebug that relate to the server, instead to those of the clients on which we're using MacGDBp.

We do have a workaround where we symlink our networked drive to the path MacGDBp is looking at. So, if my home dir on the server is /data/home/mathieu - which is locally accessible as /Volumes/mathieu, we create a directory /data/home locally, and then symlink /Volumes/mathieu to /data/home/mathieu.

This works, except for one thing: when we add a breakpoint, MacGDBp will resolve the symlink. So when I select /data/home/mathieu/whatever.php (locally), MacGDBp will see it as /Volumes/mathieu/whatever.php.

Would it be possible to either:

- Prevent resolving the symlink (as an option?)
- Implement a system similar to that I developed for xdebugclient (http://code.google.com/p/xdebugclient) where I allow the use to specify a simple rewrite rule which is then applied to all paths passed around.

Rather than doing a rewrite system, I'm now getting the source code from the Xdebug engine. Settings breakpoints in the breakpoints window will not work, but at least debugging functionality will be there. I'll attach a beta build if you want to test that out.

Here's the beta build. Please try it out and let me know if it resolves debugging on networked drives.

Thanks for taking some time for this bugreport. Tried the beta-build but it seems unable to load my code at all. Mind you, I'm dealing with a rather large codebase - so that might be causing trouble.

Getting to the code was not the biggest problem, we worked around that with a symlink. The big problem for us lies in that we're unable to set breakpoints, one of the more useful features. Without that ability, MacGBBp is basically useless to us. I proposed the rewrite system to the xdebug developers aswell ( http://xdebug.org/archives/xdebug-general/1416.html ) but they strongly feel it's the client's job to do such rewriting.

Do you have any specific objections to implementing the proposed rewrite system?

Can you check Console (/Applications/Utilities) to see if MacGDBp is spitting out any logs when you try to debug?

I have no objections to making a path rewrite system, but I don't think it's the most elegant way to solve this problem. I think I may instead create a "New Breakpoint" dialogue sheet (which will be necessary for conditional breakpoints, etc. anyway) that will allow you to type a path, and then Xdebug will get the source code from that path and you can set breakpoints that way.

But before I do that, I need to figure out why the code isn't showing up for you in the normal debugger.

Yeah, it's saying it can't bind the socket:
23-01-09 16:44:40 MacGDBp[8163] couldn't bind to the socket... trying again in 5

I have no other apps listening on port 9000:

MattieMekkie:~ mathieu$ netstat -p tcp -na | grep 9000
MattieMekkie:~ mathieu$

The rewrite system is (apparently) similar to a system Eclipse+PDT implement. Dialogue sounds good, but slow usability-wise.

Try the help steps outlined here: http://www.bluestatic.org/software/macgdbp/help.php (restarting, of course, being the last option). I've yet to figure out why sometimes the socket just fails to connect.

And I agree that usability should be a concern with creating a dialogue for something as simple as a breakpoint, and I've got some ideas to make it a more fluid process. Additionally, once you have a single breakpoint set in a file, you'll be able to set more breakpoints in that file with just simple clicks in the gutter (like you do now).

Have you been able to connect the debugger? If so, could you please see if there's any Console output when you try to debug?

Sorry for the delay, been rather busy. Turns out that the debugger does connect, I was using it wrong. There's a few reasons why I thought it didn't work:

- When MacGDBp starts, it immediately starts listening. I thought it didn't and clicked the "power button" top right. That caused the "cannot bind socket" messages I was seeing in the logs. I'm thinking this button should be disabled after the listening socket was activated ?

- The window title was (and remains during the debug session): GDBp @ (DISCONNECTED):9000/macgdbp

- When you start a debug session, the buttons continue/step into/step over buttons are enabled, but the initial code is not shown until you click one of the "step" buttons.

I've changed the behavior now so that when a connection is made, it will automatically "step in" to the first line so the debugger looks active.

I've attached the 1.2.0 release candidate. This includes a new paths replacement preference pane. Please try it out and let me know how breakpoints work for you. To explain (which will be clarified with inline documentation):

The path replacement system works by transforming a path on your local computer into the one on the remote server. The only time this needs to happen is when breakpoints are set; all other operations that involve source code are now done via Xdebug. When you add a breakpoint path now, it will replace all the "local paths" from the replacements pane to create the remote path of the source code.

For example, if I were debugging a remote website where the local source was on my computer, this is how I'd set it up:

Local Path (OS X): /Users/Robert/Sites/website
Remote Path (Linux web host): /home/hosting_company/public_html

If this works for you, I'll release 1.2.0.

Cool. It works, but I think there's some issue with the Continue command:

- Configured a path rewrite in the preferences pane
- Set a breakpoint on a certain file
- Started a debug session
- Code breaks on the first line (cool, thanks!)
- I hit Cmd-R (CONTINUE) expecting the debugger to hit the next breakpoint in the other file

Nothing happens until I hit one of the other STEP buttons. It then does jump into the right file.

So, almost there :)

Thanks for catching that. It was unrelated to the path replacement system, though. I had forgotten to update the run command to the new architecture that's in 1.2.0, but it's fixed now. 1.2.0 will be out tomorrow night (US eastern time).

--------------- AUTOMATIC RESPONSE ---------------
Thank you for your bug report. This issue has been closed and fixed in git. This change will be available in a future release, but you can download the change at any time from the git repository, found at http://www.bluestatic.org/git/.