simplecov-0.8.1 with lockfile causes hangs on Windows

[holtrop]

We recently tried to upgrade to simplecov-0.8.1 and discovered that our builds began hanging for 1 hour and finally ended with messages like the following:

C:/Ruby193/lib/ruby/gems/1.9.1/gems/lockfile-2.1.0/lib/lockfile.rb:250:in `unlink': Permission denied - D:/BuildAgent/work/2db3d5008923a037/artifacts/coverage/.resultset.json.lockfile (Errno::EACCES)
from C:/Ruby193/lib/ruby/gems/1.9.1/gems/lockfile-2.1.0/lib/lockfile.rb:250:in `rescue in block (3 levels) in lock'
from C:/Ruby193/lib/ruby/gems/1.9.1/gems/lockfile-2.1.0/lib/lockfile.rb:211:in `block (3 levels) in lock'
from C:/Ruby193/lib/ruby/1.9.1/timeout.rb:54:in `timeout'
from C:/Ruby193/lib/ruby/gems/1.9.1/gems/lockfile-2.1.0/lib/lockfile.rb:206:in `block (2 levels) in lock'
from C:/Ruby193/lib/ruby/gems/1.9.1/gems/lockfile-2.1.0/lib/lockfile.rb:430:in `block in create_tmplock'
from C:/Ruby193/lib/ruby/gems/1.9.1/gems/lockfile-2.1.0/lib/lockfile.rb:488:in `create'
from C:/Ruby193/lib/ruby/gems/1.9.1/gems/lockfile-2.1.0/lib/lockfile.rb:422:in `create_tmplock'
from C:/Ruby193/lib/ruby/gems/1.9.1/gems/lockfile-2.1.0/lib/lockfile.rb:204:in `block in lock'
from C:/Ruby193/lib/ruby/gems/1.9.1/gems/lockfile-2.1.0/lib/lockfile.rb:517:in `block (2 levels) in attempt'
from C:/Ruby193/lib/ruby/gems/1.9.1/gems/lockfile-2.1.0/lib/lockfile.rb:517:in `catch'
from C:/Ruby193/lib/ruby/gems/1.9.1/gems/lockfile-2.1.0/lib/lockfile.rb:517:in `block in attempt'
from C:/Ruby193/lib/ruby/gems/1.9.1/gems/lockfile-2.1.0/lib/lockfile.rb:517:in `loop'
from C:/Ruby193/lib/ruby/gems/1.9.1/gems/lockfile-2.1.0/lib/lockfile.rb:517:in `attempt'
from C:/Ruby193/lib/ruby/gems/1.9.1/gems/lockfile-2.1.0/lib/lockfile.rb:201:in `lock'
from C:/Ruby193/lib/ruby/gems/1.9.1/gems/simplecov-0.8.1/lib/simplecov.rb:52:in `result'
from C:/Ruby193/lib/ruby/gems/1.9.1/gems/simplecov-0.8.1/lib/simplecov/configuration.rb:139:in `block in at_exit'
from C:/Ruby193/lib/ruby/gems/1.9.1/gems/simplecov-0.8.1/lib/simplecov/defaults.rb:54:in `call'
from C:/Ruby193/lib/ruby/gems/1.9.1/gems/simplecov-0.8.1/lib/simplecov/defaults.rb:54:in `block in <top (required)>'
C:/Ruby193/bin/ruby.exe -S rspec <spec-file-list> --color --format n --format h -o artifacts/spec_results.html failed

I'm not sure if this is just a lockfile problem, or if simplecov or lockfile have been tested to work on Windows or not.

[colszowka]

Ugh, how annoying. Though I do not use Windows, if simplecov fails there this is a bug. I am not too happy with the Lockfile gem dependency, since the gem has not seen updates in a long time and yields a lot of ruby warnings when the warnings level is set higher than the default.

If you have a couple minutes, could you maybe try to manipulate your local simplecov installation with the lock implementation as seen in #233? From your project, bundle show simplecov should give you the install path, then you can simply hack that bit of result_merger.rb as shown in the PR. You'll also need to remove the Lockfile stuff from here: https://github.com/colszowka/simplecov/blob/master/lib/simplecov.rb#L50-L55

It would be super-useful to know if that implementation works on Windows. That, and JRuby are the main reasons that get me suspicious this approach wouldn't work.

[holtrop]

I'm willing to try out a patch, but I'm not sure how to modify simplecov as you're describing. I don't see any changes to result_merger.rb in #233.

[colszowka]

I'm stupid - I meant to link #223, sorry for the confusion :(

[holtrop]

I believe this patch is what you were describing. With it in place (on top of simplecov-0.8.1) my project runs specs just fine without hanging.

diff -rupN a/lib/simplecov/result_merger.rb b/lib/simplecov/result_merger.rb
--- a/lib/simplecov/result_merger.rb    2013-11-13 12:21:04.000000000 -0500
+++ b/lib/simplecov/result_merger.rb    2013-11-14 11:28:53.000000000 -0500
@@ -13,7 +13,11 @@ module SimpleCov::ResultMerger
     # Loads the cached resultset from YAML and returns it as a Hash
     def resultset
       if stored_data
-        SimpleCov::JSON.parse(stored_data)
+        begin
+          SimpleCov::JSON.parse(stored_data)
+        rescue
+          {}
+        end
       else
         {}
       end
@@ -66,6 +70,7 @@ module SimpleCov::ResultMerger
       command_name, data = result.to_hash.first
       new_set[command_name] = data
       File.open(resultset_path, "w+") do |f|
+        f.flock(File::LOCK_EX)
         f.puts SimpleCov::JSON.dump(new_set)
       end
       true
diff -rupN a/lib/simplecov.rb b/lib/simplecov.rb
--- a/lib/simplecov.rb  2013-11-13 12:21:04.000000000 -0500
+++ b/lib/simplecov.rb  2013-11-14 11:29:54.000000000 -0500
@@ -47,12 +47,12 @@ module SimpleCov
       # If we're using merging of results, store the current result
       # first, then merge the results and return those
       if use_merging
-        lockfile = ::Lockfile.new ResultMerger.resultset_path + '.lockfile'
+#        lockfile = ::Lockfile.new ResultMerger.resultset_path + '.lockfile'

-        lockfile.lock do
+#        lockfile.lock do
           SimpleCov::ResultMerger.store_result(@result) if @result
           return SimpleCov::ResultMerger.merged_result
-        end
+#        end
       else
         return @result if defined? @result
       end

[jmcaffee]

I'm seeing the same issue and this fixes it as well.

Windows 7 x64 running in mSysGit bash shell.
ruby 1.9.3p392 (2013-02-22) [i386-mingw32]
simplecov (0.8.1)
rspec (2.14.1)

[jmthomas]

+1. Exact same configuration as @jmcaffee. Without this fix the Windows gem is hard broken.

[phs]

Tangentially related, I encounter a similar problem using vagrant, specifically on virtual box (ubuntu guest) with the synced folders feature. It apparently also does not look enough like a real filesystem for the lock file to work: instead it silently blocks forever on acquisition.

I personally don't need the merging feature and so I just disabled it with use_merging false, which works around the problem. However it would've been nice if at least there was some sort of timeout on the acquisition that could have printed a helpful warning.

[colszowka]

Just shipped 0.8.2 with this fix to Rubygems.org. Please let me know if this fixes things for you!

[holtrop]

I've upgraded to 0.8.2 and it does work properly.