Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Will not stop at breakpoints with symlinks involved in directories #147

Closed
brettwilliams opened this issue Jun 18, 2015 · 8 comments
Closed

Comments

@brettwilliams
Copy link

I am working in linux/x86_64 with ruby 2.1.6. A simple ruby script is in a directory which looks like this:

>> cd $HOME
>> pwd
/home/brettw
>> tree simple_ruby/
simple_ruby/
|-- bin
|   `-- simple_run
`-- run_dir

2 directories, 1 file

>> ll simple_link
lrwxrwxrwx 1 brettw design 11 Jun 17 23:01 simple_link -> simple_ruby
>> cd simple_ruby/run_dir/
/home/brettw/simple_ruby/run_dir

I then call this program via PATH in two ways, first with the direct path, and secondly through the symlink. The first one works as expected, the second does not. You can see that if I do so with the symlink, that breakpoints do not fire.

>> PATH=$PATH:$HOME/simple_ruby/bin simple_run
Starting simple program with $0 = /home/brettw/simple_ruby/bin/simple_run

[2, 11] in /home/brettw/simple_ruby/bin/simple_run
    2: 
    3: require 'byebug'
    4: 
    5: puts "Starting simple program with $0 = #{$0}"
    6: byebug
    7: 
=>  8: var = 33
    9: puts "Set a variable"
   10: 
   11: puts "Done"
(byebug) break 9 
Successfully created breakpoint with id 1
(byebug) c
Stopped by breakpoint 1 at /home/brettw/simple_ruby/bin/simple_run:9

[2, 11] in /home/brettw/simple_ruby/bin/simple_run
    2: 
    3: require 'byebug'
    4: 
    5: puts "Starting simple program with $0 = #{$0}"
    6: byebug
    7: 
    8: var = 33
=>  9: puts "Set a variable"
   10: 
   11: puts "Done"
(byebug) c
Set a variable
Done

Now for the second run, where I call it using PATH through a symlinked directory:

>> pwd
/home/brettw/simple_ruby/run_dir
>> PATH=$PATH:$HOME/simple_link/bin simple_run
Starting simple program with $0 = /home/brettw/simple_link/bin/simple_run

[2, 11] in /home/brettw/simple_link/bin/simple_run
    2: 
    3: require 'byebug'
    4: 
    5: puts "Starting simple program with $0 = #{$0}"
    6: byebug
    7: 
=>  8: var = 33
    9: puts "Set a variable"
   10: 
   11: puts "Done"
(byebug) break 9
Successfully created breakpoint with id 1
(byebug) c
Set a variable
Done

Note that this is further complicated by the fact that even cutting and pasting the file and line number that byebug thinks it is currently on (i.e. when hitting an explicit byebug statement) will not give the correct result.

If all symlinks are resolved, it seems to work ok.

Is there a way to make this work better, or a best practice that I can follow?

Thank you for your contribution and consideration.

@deivid-rodriguez
Copy link
Owner

@brettwilliams Sorry I totally missed this issue. Great report, thanks! If you want to give it a try, this shouldn't be a really hard one to tackle!

@os97673
Copy link
Contributor

os97673 commented Jul 29, 2015

@deivid-rodriguez just to share our experience with debugging symlinked files. Tracepoint API report file name which was used when the file was loaded first time. In some cases it will be symlinked name in others - real (non-symlinked) name. In ruby-debug-ide/debase we always use resolved name to make this work reliably. Hope this will be useful for you.

deivid-rodriguez pushed a commit that referenced this issue Jul 29, 2015
@deivid-rodriguez
Copy link
Owner

@os97673 Thanks a lot, your input an experience with the other ruby debugging tools is always appreciated.

@brettwilliams Could you try latest master and see if it fixes your issue? I've added a possible fix following @os97673 advice but was too lazy to check if it works or write a test...

@os97673
Copy link
Contributor

os97673 commented Jul 29, 2015

@os97673 Thanks a lot, your input an experience with the other ruby debugging tools is always appreciated.

any time :)

@brettwilliams
Copy link
Author

I'll try to check when I'm able. I'm pretty sure that the normalize files
method already present is all that is needed since it looks like it does
exactly what is needed

On Wed, Jul 29, 2015 at 5:18 AM, David Rodríguez notifications@github.com
wrote:

@os97673 https://github.com/os97673 Thanks a lot, your input an
experience with the other ruby debugging tools is always appreciated.

@brettwilliams https://github.com/brettwilliams Could you try latest
master and see if it fixes your issue? I've added a possible fix following
@os97673 https://github.com/os97673 advice but was too lazy to check if
it works or write a test...


Reply to this email directly or view it on GitHub
#147 (comment)
.

@brettwilliams
Copy link
Author

@deivid-rodriguez,

Attempt #147 commit fixes the issue in my small test case. Thanks!

On Wed, Jul 29, 2015 at 7:48 AM, Brett Williams brett@brettandbecky.net
wrote:

I'll try to check when I'm able. I'm pretty sure that the normalize files
method already present is all that is needed since it looks like it does
exactly what is needed

On Wed, Jul 29, 2015 at 5:18 AM, David Rodríguez <notifications@github.com

wrote:

@os97673 https://github.com/os97673 Thanks a lot, your input an
experience with the other ruby debugging tools is always appreciated.

@brettwilliams https://github.com/brettwilliams Could you try latest
master and see if it fixes your issue? I've added a possible fix following
@os97673 https://github.com/os97673 advice but was too lazy to check
if it works or write a test...


Reply to this email directly or view it on GitHub
#147 (comment)
.

@deivid-rodriguez
Copy link
Owner

@brettwilliams I missed this message and I've done a couple other changes in that area. Could you try, again, against last master and if fixed, close this issue? Thanks a lot!

@brettwilliams
Copy link
Author

@deivid-rodriguez latest master passes test

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants