Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Go] Data race of calling GetToTimeFunc of fixed timestamp data type #38795

Closed
7phs opened this issue Nov 20, 2023 · 0 comments · Fixed by #38797
Closed

[Go] Data race of calling GetToTimeFunc of fixed timestamp data type #38795

7phs opened this issue Nov 20, 2023 · 0 comments · Fixed by #38797
Assignees
Milestone

Comments

@7phs
Copy link

7phs commented Nov 20, 2023

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

@7phs 7phs added the Type: bug label Nov 20, 2023
@zeroshade 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
zeroshade added a commit to zeroshade/arrow that referenced this issue Nov 20, 2023
bkietz added a commit that referenced this issue Nov 27, 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>
@bkietz bkietz added this to the 15.0.0 milestone Nov 27, 2023
dgreiss pushed a commit to dgreiss/arrow that referenced this issue Feb 19, 2024
### 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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants