Hi Alex,
What is the deadlock, are you talking about an exception being thrown by the DB
deadlocking?
If you are talking about a cucumber / selenium "deadlock" as in it just sits
there waiting for something to appear, this can happen when the test suite is
moving too fast for updates to happen...
For example:
Given I am on the home page
( this site adds a "login" link once the remote user IP Address is
checked first)
And I follow "login"
Then I should be on my dashboard.
This will fail if the ajax call does not get the login link to appear before
the test tries to follow the login link.
A way to solve this is add an explicit expectation before the follow:
Given I am on the home page
Then I should see "login"
When I follow "login"
Then I should be on my dashboard.
This way, the system waits for the login link to appear before trying to follow
it.
Mikel
On 08/10/2010, at 12:32 AM, Alex Cooper wrote:
> Hi everybody,
>
> I uncovered a rather unnerving race condition at work (GetUp) today, and I'd
> love to know if anyone else has seen this.
>
> I've been getting a erratic, but reproducible lockups under ruby 1.9.2 and
> cucumber/capybara [1]. But under ruby 1.8.7 it's fine.
>
> This sucks, because we'd really like to use 1.9.2 for its much improved
> performance.
>
> The cucumber script does nothing special. Populate the DB, fill in some
> fields, press a button or two. Sometimes cucumber hangs midway through the
> test--but at different locations. This behavior is seen on other features,
> too, but it's mainly in the same few scenarios.
>
> Steps to reproduce:
> rvm use 1.8.7
> bundle exec cucumber features/example.feature [2]
> observe soothing green output
> rvm use 1.9.2
> bundle exec cucumber features/example.feature
> tear hair out when deadlock occurs [3]
>
> The kicker is that it happens in different places in the cucumber script, and
> there's no predictable pattern I can discern as to exactly which step (or
> type of step) will hang.
>
> I suspect deadlock, because output halts midway through a scenario, CPU drops
> to zero, memory usage remains stable, and Ruby no longer responds to SIGINT
> (which I think it normally would).
>
> So, my questions for the floor are, in increasing order of importance:
> Has anyone on the list experienced (and hopefully fixed) this problem?
> How would you approach tracking this bad boy down? (Preferably not involving
> MRI source code and gdb.)
> Which particular alcoholic beverage is preferred for drowning one's sorrows
> while debugging bugs like this?
>
> Cheers, and many thanks in advance,
>
> - alex.
>
> Notes:
> The environment is: Rails 3.0, Ruby 1.9.2, cucumber 0.9.0, cucumber-rails
> 0.3.2, webrick 1.3.1, postgres 8.4.4, OSX Snow Leopard
> There really is nothing special about this script--it just fills in inputs
> and pushes buttons.
> On different machines, deadlock occurs with different frequency. On my (slow)
> MBP with 2G memory, it happens about 70% of the time. On a colleague's older
> (but faster) machine, it locks up around 30% of the time.
>
> --
> Alex Cooper m: 0402 024 304 w: http://acooper.org/ t:
> @kuperov
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby or Rails Oceania" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/rails-oceania?hl=en.
--
You received this message because you are subscribed to the Google Groups "Ruby
or Rails Oceania" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/rails-oceania?hl=en.
