Skip to content
This repository

Path mapping bug when using a jail #54

michaeltwofish opened this Issue March 01, 2013 · 14 comments

3 participants

Michael C. Harris Jonathan Cairns Quinn Strahl
Michael C. Harris

When I run the debugger, the code buffer is empty. While stepping through code, I can see variables update in the DebuggerWatch buffer, but the code buffer remains empty.

Empty code panel

Additionally, execution doesn't stop at breakpoints, even on a trivial script, though xdebug_break() works.

I see the same behaviour after disabling all other plugins.

Vdebug 1.3.2, Python 2.7, Xdebug v2.1.0, Vim 7.3.843.

Jonathan Cairns


This sounds like a path mapping issue, in that Vdebug is interpreting a path from Xdebug that doesn't exist on the local file system.

Are you debugging a local or remote script? If remote, check that the contents of the path map are correct. If local, check that the path map is empty:

:VdebugOpt path_maps

If this doesn't help then could you create a log file before starting your session? You can do this with:

:VdebugOpt debug_file /path/to/vdebug.log
:VdebugOpt debug_file_level 2

Then start your debugging session, close it and upload the log (preferably as a Gist).


Michael C. Harris

You're absolutely right, and I feel like a dope for not realising. The code is in a jail.

I suspect I'm abusing the option, but setting path_maps to map the jailed path to the filesystem path, let g:vdebug_options = {'path_maps' : {"/usr": "/jails/alcatraz/usr"} }, means the code is displayed in the code buffer, but I get the following error if I try to set a breakpoint.

E158: Invalid buffer name: /jails/alcatraz/jails/alcatraz/usr/local/www/schools/webroot/index.php
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/root/dotfiles/vim/bundle/vdebug/plugin/python/", line 135, in set_breakpoint
  File "/root/dotfiles/vim/bundle/vdebug/plugin/python/vdebug/", line 200, in set_breakpoint
  File "/root/dotfiles/vim/bundle/vdebug/plugin/python/vdebug/", line 36, in add_breakpoint
  File "/root/dotfiles/vim/bundle/vdebug/plugin/python/vdebug/", line 105, in on_add
  File "/root/dotfiles/vim/bundle/vdebug/plugin/python/vdebug/ui/", line 96, in register_breakpoint
  File "/root/dotfiles/vim/bundle/vdebug/plugin/python/vdebug/ui/", line 103, in place_breakpoint
    ' file='+file)

Is there a way to achieve what I want with the current options or should I look into implementing it?

Jonathan Cairns

Is there a way to achieve what I want with the current options or should I look into implementing it?

I love your attitude :)

The code is in a jail.

I didn't actually consider this use case, so that's very interesting. It looks like it's failing on setting a sign, so that's definitely a bug. I'll investigate a bit more, as I think I know what's going on.


Jonathan Cairns

Give the dev branch a go - it might solve your problem.

Michael C. Harris

Give the dev branch a go - it might solve your problem.

Sadly, I get the same behaviour on the dev branch, both with and without a path_maps setting.

I'm sure you know all this, but for my benefit working through it, FilePath._create_local prepends the locally mapped path, so it's already been replaced by the time place_breakpoint calls file.as_local. When xdebug is looking for the file, it needs to be mapped because it's in the jail. When vdebug is looking for the file it shouldn't be mapped, because it has access to the correct path, but a straight string replace replaces in the middle of the string so the jail mount point is repeated.

I see two options. The first is to introduce another setting. The second is to include something in the path_maps entry that says it should be treated as a regular expression and do an re.sub on it instead of a string.replace. Perhaps something like prefixing with !:

let g:vdebug_options = {'path_maps' : {"!^/usr": "/jails/alcatraz/usr"} }
Jonathan Cairns

Sadly, I get the same behaviour on the dev branch

Oh well, worth a shot!

Regular expressions in path mapping are something that I've wanted to implement for a while now. In fact, the whole path mapping thing in general is on the list for an overhaul. But since this is a more immediate issue I like your idea of adding a ! to signify a regular expression.

I'm going to create a new branch for working on this. Feel free to contribute something if you like, and I'll keep this issue updated with changes.


Michael C. Harris

I had a go implementing both regular expression support and the ! prefix and basically ran into the same issue with both: going from a remote_path with a regular expression to a local_path is fine but going from a local_path back to a remote_path with a regular expression is too tricky for my small brain. I'm happy to brainstorm and help with implementation if I can. Any small thing to help you maintain your fantastic plugin.

Quinn Strahl

@michaeltwofish I'm not sure what you're playing around with but circumstance has forced me to acquire an encyclopaedic grokking of regular expressions; what is it you need?

Michael C. Harris

@qstrahl offers of help are always appreciated. It's not really a regex problem though, more a logic issue. The vdebug path_maps option is bidirectional, mapping remote paths to local paths and local paths to remote paths. In my case, I want the mapping to be /usr to /jails/alcatraz/usr, but setting 'path_maps' : {"/usr": "/jails/alcatraz/usr"} means I end up with /jails/alcatraz/jails/alcatraz/usr when setting a breakpoint.

Actually, I think I've just realised the solution: if the target is a regex, just ignore it.

Michael C. Harris

I tried to implement the prefix but I've failed to make it respect breakpoints.

Jonathan Cairns

I think the problem here is that I've tried to make the filename mapping too general. I created a single file wrapper object, expecting to be able to convert to and from remote/local paths at will. The reality is that I should probably have a RemoteFilePath object, which handles all file paths that Xdebug sends to Vdebug.

The problem is that a local file path is being converted to a local file path again. This has always been a problem, but it's only come up now that the remote file path is actually a substring of the local one. Instead of passing all file paths into a single FilePath object, I'm going to discern between local and remote file paths at the point of creation.

Still, regular expressions are definitely a feature I want to implement, and I like your idea @michaeltwofish of using a ! prefix.

I don't know how much work this remote file path thing will be, so watch this space!

Jonathan Cairns

So, I'm back. And I might have a working fix this time.

Check out the fix-file-paths branch - this is a bit more intelligent about when to convert file paths and apply the mapping.

I hope it fixes it for you. It seemed to work for me, but there's a possibility of it having introduced other issues so treat it as unstable!


Michael C. Harris

Works perfectly so far! Thanks a million for a) the plugin b) your responsiveness and c) being a first class open source citizen.

Jonathan Cairns

Great! And no problem. I'll keep this issue open until I release the next bug fix. Cheers

Jonathan Cairns joonty closed this May 09, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.