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
Describe the bug, including details regarding any error messages, version, and platform.
Hello,
I found a data race in databricks-sql-go. A root cause of data race is timestamp fields of arrow.FixedWidthTypes and the function GetToTimeFunc() of arrow.TimestampType.
A test to reproduce a data race:
import (
"sync"
"testing"
"github.com/apache/arrow/go/v15/arrow"
)
func TestArrowDataRace(t *testing.T) {
var (
wg sync.WaitGroup
w = make(chan bool)
routineNum = 10
)
wg.Add(routineNum)
for i := 0; i < routineNum; i++ {
go func() {
defer wg.Done()
<-w
_, _ = arrow.FixedWidthTypes.Timestamp_s.(*arrow.TimestampType).GetToTimeFunc()
}()
}
close(w)
wg.Wait()
}
A command to run this test with data race detector:
go test -race -run TestArrowDataRace .
A go version is 1.21.
The same issue is in Apache Arrow Go v12.
A root cause of data race is not initialised field loc of arrow.TimestampType. It initialised in the first call of function arrow.TimestampType :: GetZone().
Component(s)
Go
The text was updated successfully, but these errors were encountered:
zeroshade
changed the title
Data race of calling GetToTimeFunc of fixed timestamp data type
[Go] Data race of calling GetToTimeFunc of fixed timestamp data type
Nov 20, 2023
### Rationale for this change
Adding RWMutex to protect `loc` in `TimestampType` and fix the race condition.
### Are these changes tested?
Yes, a unit test is added which is covered by the CI which runs with `-race`.
### Are there any user-facing changes?
Copying `TimestampType` will now be problematic and linters will show it as an error. In theory this shouldn't be a problem as most uses of TimestampType should be utilizing pointers to it rather than the value directly.
* Closes: #38795
Lead-authored-by: Matt Topol <zotthewizard@gmail.com>
Co-authored-by: Benjamin Kietzman <bengilgit@gmail.com>
Co-authored-by: Ben Harkins <60872452+benibus@users.noreply.github.com>
Signed-off-by: Benjamin Kietzman <bengilgit@gmail.com>
### Rationale for this change
Adding RWMutex to protect `loc` in `TimestampType` and fix the race condition.
### Are these changes tested?
Yes, a unit test is added which is covered by the CI which runs with `-race`.
### Are there any user-facing changes?
Copying `TimestampType` will now be problematic and linters will show it as an error. In theory this shouldn't be a problem as most uses of TimestampType should be utilizing pointers to it rather than the value directly.
* Closes: apache#38795
Lead-authored-by: Matt Topol <zotthewizard@gmail.com>
Co-authored-by: Benjamin Kietzman <bengilgit@gmail.com>
Co-authored-by: Ben Harkins <60872452+benibus@users.noreply.github.com>
Signed-off-by: Benjamin Kietzman <bengilgit@gmail.com>
Describe the bug, including details regarding any error messages, version, and platform.
Hello,
I found a data race in
databricks-sql-go
. A root cause of data race is timestamp fields ofarrow.FixedWidthTypes
and the functionGetToTimeFunc()
ofarrow.TimestampType
.A test to reproduce a data race:
A command to run this test with data race detector:
A go version is 1.21.
The same issue is in Apache Arrow Go v12.
A root cause of data race is not initialised field
loc
ofarrow.TimestampType
. It initialised in the first call of functionarrow.TimestampType :: GetZone()
.Component(s)
Go
The text was updated successfully, but these errors were encountered: