Attempt to unlock a mutex which is locked by another thread

[sfcgeorge]

Switched a test suite with a few hundred specs to Cuprite, mostly working fine (well done and thank you!)

There's 1 weird error we get. The spec passes normally, but if we turn on js_errors: true we get this:

Failures:

  1) Enthusiast an enthusiast successfully books an activity that disallows kids
     Failure/Error: dashboard_page.browse_activities.click
     
     ThreadError:
       Attempt to unlock a mutex which is locked by another thread
     # ./spec/features/enthusiasts/books_an_activity_spec.rb:151:in `navigate_to_booking_page'
     # ./spec/features/enthusiasts/books_an_activity_spec.rb:36:in `block (2 levels) in <main>'
     # -e:1:in `<main>'
     # ------------------
     # --- Caused by: ---
     # Capybara::Cuprite::JavaScriptError:
     #   r
     #   ./spec/features/enthusiasts/books_an_activity_spec.rb:151:in `navigate_to_booking_page'

Mutex seems like a Ruby thing not a JS thing, yet a JS error is being raised. And the JS error is just the letter "r"?

The scenario is just logging in, being redirected to the dashboard, then clicking a link. On clicking the link this error happens.

For now I've worked around like so:

begin
  click_on 'Search'
  # visit '/search' # same error
rescue ThreadError
  puts 'Rescuing erroneous Cuprite JS error on search page'
end

[route]

Yea that's weird, do you js_errors: true set?

[sfcgeorge]

Yep that's what I mean, I get this issue with js_errors: true, with js_errors: false the spec passes fine. Or with the rescue it passes as well.

As it's just 1 page it could be something specific to our app, but I thought I'd open the issue in case anyone else gets the same error and googles it.

[ximus]

i think i had such a cryptic mutex error myself. I had tracked it down. The issue for me occurred when the page took longer to load than the cuprite timeout configured, then it would throw such an error.

It's a little far for me to remember well, but I had reproduced it by create a fresh rails app, then putting an infinite sleep in a controller action then trying to load that action using cuprite.

[route]

@ximus mind creating a repo so I could take a look?

[ximus]

https://github.com/ximus/cuprite-mutex-error-poc

[route]

@ximus @sfcgeorge I removed all possible deadlocks in the last release. Code is no longer uses plain Ruby mutex and condition var, we now use concurrent-ruby primitives, more over there's always timeout (5 seconds by default) for slow responses. Could you guys please check again that massive refactoring?

[route]

@ximus I ran your application locally and it worked fine on both my machines:

Failures:

  1) test test
     Failure/Error: visit root_path
     
     Capybara::Cuprite::JavaScriptError:
       Error: foo error
           at HTMLDocument.<anonymous> (http://127.0.0.1:33605/:16:11)
     # ./spec/features/test_spec.rb:5:in `block (2 levels) in <top (required)>'

Finished in 6.37 seconds (files took 0.40761 seconds to load)
1 example, 1 failure

Failed examples:

rspec ./spec/features/test_spec.rb:4 # test test

Mutex was fully eliminated from cuprite, if you guys could check that this error doesn't exist anymore I would appreciate it. Thanks!

[ximus]

confirmed that toggling from 0.6.0 to 0.7.0 does fix the error. I know get:

1) test test
     Failure/Error: visit root_path

     Ferrum::TimeoutError:
       Timed out waiting for response. It's possible that this happened because something took a very long time (for example a page load was slow). If so, setting the :timeout option to a higher value might help.
     # ./spec/features/test_spec.rb:5:in `block (2 levels) in <top (required)>'

interesting note. I initially wasn't able to reproduce this. Then I tried downgrading to the ruby version I used during my initial POC. Turns out I can't reproduce the original error at ruby 2.6.3 but only when i used 2.5.1. Anyways, irrelevant now that mutexes are gone.

[route]

Thanks I'm glad it worked!