Search code examples
rubyfirefoxwatirgeckodriver

Watir crashes if I loop several times on the same pages


I've automated the upload of some evidences to a compliance intranet where I work (I cannot provide details) with watir.

I've done something as simple as opening a firefox session to that intranet and than a loop that goes through each server I pass as command line argument. It searches for that server using a form does that clicks it has to do in order to upload the evidence (a zip file).

ARGV.each do|server|
  shotname = "#{download_directory}/foo_#{server}.png"
    b.goto 'https://compl.intra.secret.com/index.php'

    l = b.link text: 'Systems'
    l.wait_until_present
    l.exists?
    l.click

  ....
  ....
end

As soon as I execute the script with few servers, CPU goes at 100%, but it reaches the end without issues, but if I pass about 20 servers as my arguments, ruby crashes really bad with this stacktrace

stack backtrace:: Failed to find value field (Selenium::WebDriver::Error::UnknownError)
        from    0:           0x4edb3c - backtrace::backtrace::trace::hc4bd56a2f176de7e
        from    1:           0x4edb72 - backtrace::capture::Backtrace::new::he3b2a15d39027c46
        from    2:           0x4409a1 - webdriver::error::WebDriverError::new::h81babdd86c977032
        from    3:           0x44b2c7 - geckodriver::marionette::MarionetteSession::response::ha4a2fbbdd9abe262
        from    4:           0x429f1a - <webdriver::server::Dispatcher<T, U>>::run::h2119c674d7b88193
        from    5:           0x4029b9 - std::sys_common::backtrace::__rust_begin_short_backtrace::h21d98a9ff86d4c25
        from    6:           0x40be65 - std::panicking::try::do_call::h5cff0c9b18cfdbba
        from    7:           0x5e6a6c - panic_unwind::__rust_maybe_catch_panic
        from                         at /checkout/src/libpanic_unwind/lib.rs:99
        from    8:           0x41eb22 - <F as alloc::boxed::FnBox<A>>::call_box::h413eb1d9d9f1c473
        from    9:           0x5df13b - alloc::boxed::{{impl}}::call_once<(),()>
        from                         at /checkout/src/liballoc/boxed.rs:692
        from                          - std::sys_common::thread::start_thread
        from                         at /checkout/src/libstd/sys_common/thread.rs:21
        from                          - std::sys::imp::thread::{{impl}}::new::thread_start
        from                         at /checkout/src/libstd/sys/unix/thread.rs:84
        from /home/antenore/.gem/ruby/2.4.0/gems/selenium-webdriver-3.8.0/lib/selenium/webdriver/remote/response.rb:69:in `assert_ok'

My code it's less than acceptable, but I was wondering if it may be also a bug and if you have any advices in order to optimize a loop like the one I've described.

I didn't try to run the script without the headless extension.

Thanks a lot!!!

System:

Fedora release 26 (Twenty Six)

Gems used/installed:

watir (6.10.3)
watir-screenshot-stitch (0.6.5)
headless (2.3.1)

Others:

geckodriver 0.19.1 Firefox 57.0.1


Solution

  • As advised by the geckdriver developers:

    Support is best in Firefox 55 and greater, although generally the more recent the Firefox version, the better the experience as they have more bug fixes and features. Some features will only be available in the most recent Firefox versions, and we strongly advise using the latest Firefox Nightly with geckodriver.

    With the last geckdriver release (my case), is always better to use the last version of Firefox.

    The main reason for this, always quoting hteir GitHub README

    geckodriver is not yet feature complete. This means that it does not yet offer full conformance with the WebDriver standard or complete compatibility with Selenium. You can track the implementation status of the latest Firefox Nightly on MDN. We also keep track of known Selenium, remote protocol, and specification problems in our issue tracker.

    In fact, in my specific case, updating to Firefox 58.0.1, the latest release available on Fedora 26, fixed my problem.

    Therefore, as rule of dumb, you must always use both latest version of geckdriver and Pirefox whenever possible, or at least follows the reccomandations of each release notes (if any).

    Thanks to @Sam @JustinKo and @FrankSchmitt for their precious support.