You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This meant that you could use the By utility within go routines within a test suite, if for example, you wanted to use a waitgroup to wait for multiple conditions in tandem.
In version 2.5.0, running tests with the ginkgo binary those same tests now report a data race because the By reporter is now writing events not under lock.
Digging in, I believe the issue is because emit is writing changes to the DefaultReporter not under lock.
So either we need to adjust the handleSpecEvent to use the suite selective lock to emit the event to the reported under lock or we need to fix the DefaultReporter so that it isn't racy here
The text was updated successfully, but these errors were encountered:
JoelSpeed
changed the title
Race condition introduced in v2.5.0
Race condition introduced in By in v2.5.0
Feb 8, 2023
I believe db83f33 has introduced a race condition in the
By
utility in the core DSL.In version 2.4.0,
By
was implemented directly into core_dsl.go and used AddReportEntry (which adds report untries under lock) and then GinkgoWriter.Println (which writes to the output under lock) to add the report entry and then write the output.This meant that you could use the
By
utility within go routines within a test suite, if for example, you wanted to use a waitgroup to wait for multiple conditions in tandem.In version 2.5.0, running tests with the ginkgo binary those same tests now report a data race because the
By
reporter is now writing events not under lock.By
is now implemented in suite.go and callssuite.handleSpecEvent
which appends the event for the report entry under lock but then calls thereporter.EmitSpecEvent
which in the DefaultReporter is causing a race when not used under lock.Digging in, I believe the issue is because emit is writing changes to the
DefaultReporter
not under lock.So either we need to adjust the
handleSpecEvent
to use the suite selective lock to emit the event to the reported under lock or we need to fix theDefaultReporter
so that it isn't racy hereThe text was updated successfully, but these errors were encountered: