Path mapping bug when using a jail about vdebug HOT 14 CLOSED

Hi,

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).

Thanks

from vdebug.

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/start_vdebug.py", line 135, in set_breakpoint
    self.runner.set_breakpoint(args)
  File "/root/dotfiles/vim/bundle/vdebug/plugin/python/vdebug/runner.py", line 200, in set_breakpoint
    self.breakpoints.add_breakpoint(bp)
  File "/root/dotfiles/vim/bundle/vdebug/plugin/python/vdebug/breakpoint.py", line 36, in add_breakpoint
    breakpoint.on_add()
  File "/root/dotfiles/vim/bundle/vdebug/plugin/python/vdebug/breakpoint.py", line 105, in on_add
    self.ui.register_breakpoint(self)
  File "/root/dotfiles/vim/bundle/vdebug/plugin/python/vdebug/ui/vimui.py", line 96, in register_breakpoint
    breakpoint.file,breakpoint.line)
  File "/root/dotfiles/vim/bundle/vdebug/plugin/python/vdebug/ui/vimui.py", 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?

from vdebug.

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.

Cheers

from vdebug.

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

from vdebug.

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"} }

from vdebug.

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.

Cheers

from vdebug.

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.

from vdebug.

@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?

from vdebug.

@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.

from vdebug.

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

from vdebug.

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!

from vdebug.

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!

Thanks

from vdebug.

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

from vdebug.

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

from vdebug.