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

[BUG] race condition in ReadSingleEvent #31

Open
capnspacehook opened this issue Aug 20, 2023 · 0 comments
Open

[BUG] race condition in ReadSingleEvent #31

capnspacehook opened this issue Aug 20, 2023 · 0 comments
Assignees
Labels

Comments

@capnspacehook
Copy link

What went wrong:
I tried to use read from Watcher.Events while multiple directories were being watched. Testing with the race detector, I found a race condition. FsEvents returned from Wather.ReadSingleEvent are directly casted using an unsafe.Pointer. Watcher.eventBuffer is reused between Wather.ReadSingleEvent calls, so when unix.Read writes to w.eventBuffer, it may write to the same memory of a previously returned FsEvents.

Steps to reproduce, or a short snippet of code that reproduces the problem:

Build https://github.com/tywkeene/go-fsevents/blob/master/examples/loop/loop.go with the race detector and trigger many file events quickly.

System and build environment information

Please run and paste the output of the following commands:

go version:
go version go1.21.0 linux/amd64

go env | grep "CGO_ENABLED\|GOOS":
GOOS='linux'
CGO_ENABLED='1'

uname -r:
6.4.6-76060406-generic

Additional context:
I think Wather.ReadSingleEvent should be removed and Watcher.Watch should be refactored so all events from a single unix.Read use a unique buffer. I'll see how easy this is and open a PR if it's doable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants