Issue Details (XML | Word | Printable)

Key: JRUBY-2909
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Charles Oliver Nutter
Reporter: Charles Oliver Nutter
Votes: 0
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
JRuby

Tracing regression, full pathing in trace output

Created: 10/Aug/08 12:33 AM   Updated: 12/Jan/09 04:28 PM
Component/s: Core Classes/Modules
Affects Version/s: None
Fix Version/s: JRuby 1.1.5

Time Tracking:
Not Specified


 Description  « Hide
I thought we had this fixed...but it appears full paths are back in trace events:
  1) Failure:
test_require_trace_full_paths(TestTraceFunc) [/Users/headius/NetBeansProjects/jruby/./test/tracing/test_trace_func.rb:154]:
<["test/tracing/test_trace_func.rb line 143 test_require_trace_full_paths TestTraceFunc",
 "./test/tracing/dummy1.rb line 1 nil false",
 "./test/tracing/dummy1.rb class 1 nil false",
 "./test/tracing/dummy1.rb end 1 nil false",
 "test/tracing/test_trace_func.rb line 145 test_require_trace_full_paths TestTraceFunc"]> expected but was
<["/Users/headius/NetBeansProjects/jruby/./test/tracing/test_trace_func.rb line 143 test_require_trace_full_paths TestTraceFunc",
 "./test/tracing/dummy1.rb line 1 nil false",
 "./test/tracing/dummy1.rb class 1 nil false",
 "./test/tracing/dummy1.rb end 1 nil false",
 "/Users/headius/NetBeansProjects/jruby/./test/tracing/test_trace_func.rb line 145 test_require_trace_full_paths TestTraceFunc"]>.

Run with jruby --debug -S rake test:tracing.



 All   Comments   Work Log   Change History      Sort Order: Ascending order - Click to sort in descending order
Thomas E Enebo added a comment - 23/Aug/08 02:32 PM
Not sure why this is failing but when I solved this last time I was running it with:
jruby --debug test/tracing/test_trace_func.rb

So however rake invokes this is uncovering another issue. Another interesting observation is that MRI does not pass from rake either (though the output is different than ours). If I run the test like above then MRI also passes. So heh...WTF? The output is just different when run in rake and when run from command-line. I guess at a minimum we are still doing something wrong. I will at least make it fail the same way when run from rake if not make it work for both command-line and rake.


Thomas E Enebo added a comment - 26/Aug/08 04:11 PM
Not a regression so much as another discovered case where it has not properly worked. The fix is trivial but it breaks jar file support for load/require. This will get fully fixed after we refactor the Jar file support for 1.1.5. Bumping.

Charles Oliver Nutter added a comment - 09/Oct/08 09:50 PM
I've been exploring various cases and trying to determine the pattern in Ruby's pathing. It seems that largely, Ruby leaves relative paths relative and absolute paths absolute, using those literal paths in logging and traces. It also resolves relative paths dynamically at runtime based on the process CWD:
~/projects/jruby &#10132; ruby -Ifoo -e "require 'bar'"
./foo/bar.rb:1: unhandled exception
	from -e:1:in `require'
	from -e:1
~/projects/jruby &#10132; cd foo
~/projects/jruby/foo &#10132; ruby -e "require 'bar'"
./bar.rb:1: unhandled exception
	from -e:1:in `require'
	from -e:1
~/projects/jruby/foo &#10132; cd ../lib
~/projects/jruby/lib &#10132; ruby -I../foo -e "require 'bar'"
../foo/bar.rb:1: unhandled exception
	from -e:1:in `require'
	from -e:1
~/projects/jruby/lib &#10132; ruby -I../../jruby/foo -e "require 'bar'"
../../jruby/foo/bar.rb:1: unhandled exception
	from -e:1:in `require'
	from -e:1
~/projects/jruby/lib &#10132; ruby -I/Users/headius/projects/jruby/foo -e "require 'bar'"
/Users/headius/projects/jruby/foo/bar.rb:1: unhandled exception
	from -e:1:in `require'
	from -e:1
~/projects/jruby/lib &#10132; cd ..
~/projects/jruby &#10132; ruby -Ifoo -e "Dir.chdir('lib'); require 'bar'"
-e:1:in `require': no such file to load -- bar (LoadError)
	from -e:1

So our problem, and the reason why we always seem to have full paths in traces, is that we always turn paths into absolute paths, losing that original short path. This also represents a behavioral difference; notice in the last case that when the CWD is changed, relative paths no longer resolve the same.

I'll keep poking and see if I can find a way to fix this in our LoadService.


Charles Oliver Nutter added a comment - 10/Oct/08 12:06 AM
A few more interesting cases:
~/projects/jruby &#10132; ruby -Ifoo -e "require 'bar'"
./foo/bar.rb:1: unhandled exception
	from -e:1:in `require'
	from -e:1
~/projects/jruby &#10132; ruby -e "require 'foo/bar'"
./foo/bar.rb:1: unhandled exception
	from -e:1:in `require'
	from -e:1
~/projects/jruby &#10132; ruby -e "require './foo/bar'"
./foo/bar.rb:1: unhandled exception
	from -e:1:in `require'
	from -e:1

Note that, while not immediately apparent here, Ruby does appear to attempt to certain paths as-is before trying load paths, and does not appear to ever attach load paths to absolute paths (which makes some sense). So adding a short-circuit that tries the path as-is first seems to also be in the cards.


Charles Oliver Nutter added a comment - 10/Oct/08 12:12 AM
A couple more, showing Ruby does not attempt to search load path for a relative path based on . (CWD):

First with no bar.rb in current dir, but a bar.rb in the 'foo' dir:

~/projects/jruby &#10132; ruby -Ifoo -e "require './bar.rb'"
-e:1:in `require': no such file to load -- ./bar.rb (LoadError)
	from -e:1

Now with a bar.rb in current dir:

~/projects/jruby &#10132; echo puts \'hello\' > bar.rb
~/projects/jruby &#10132; ruby -Ifoo -e "require './bar.rb'"
hello

Obviously we need to put together specs for all the many cases. A few more that need to be specified:

  • home dir using ~ and ~username
  • all URLs, not just the limited support for file: and jar: we have now
  • Windows paths
  • paths with symlinks (to see whether they get expanded or left as-is in traces, etc)

Others?


Charles Oliver Nutter added a comment - 10/Oct/08 12:34 AM
I am committing a set of fixes that seem to solve this and improve other cases:
  • A short circuit that tries the path as-is if it starts with a ./ or appears to be an absolute path (according to java.lang.File)
  • Logic to use current directory + load path entry in cases where the entry is a non-absolute path, and not do that if it appears to be an absolute path
  • Use only the load path entry + required name + suffix for the parsed _FILE_, trace, and so on

So far these changes all appear to be in line with actual Ruby behavior, and the related tracing specs pass now. I'm going to optimistically commit them so they get a little burn-in time before 1.1.5. I've also posted a "wanted" email to the rubyspec list for a set of specs for all permutations of load logic and their effects on loading, _FILE_/trace, and so on, since I'm not sure I'll have time to do any myself before 1.1.5 home stretch.


Charles Oliver Nutter added a comment - 10/Oct/08 12:37 AM
Committed fixes in r7854.