Panic on Mac OS X when debugging

[NightBlaze]

Before reporting an issue, please ensure you are using the latest release of fsnotify.

Which operating system (GOOS) and version are you using?

OS:
ProductName: Mac OS X
ProductVersion: 10.12.5
BuildVersion: 16F73

Go:
go version go1.8.3 darwin/amd64

Delve:
Delve Debugger
Version: 1.0.0-rc.1
Build:

IDE:
Visual Studio Code
Ver 1.14.1 (1.14.1)
2648980a697a4c8fb5777dcfb2ab110cec8a2f58
2017-07-13T19:05:02.227Z

Please describe the issue that occurred.

When execution continues after stop at breakpoint then panic raised at kqueue.go -> read(kq int, events []unix.Kevent_t, timeout *unix.Timespec)

Are you able to reproduce the issue? Please provide steps to reproduce and a code sample if possible.

1. I use sample code from https://github.com/fsnotify/fsnotify/blob/master/example_test.go
2. Set up breakpoint at any place
3. Trigger breakpoint
4. When step over or continue execution then panic raised

panic: runtime error: slice bounds out of range

goroutine 8 [running]:
bitbucket.org/project/vendor/github.com/fsnotify/fsnotify.read(0x8, 0xc4202e0e88, 0xa, 0xa, 0x1708c50, 0xc4202e0e88, 0x0, 0xa, 0x0, 0x0)

/path_to_project/vendor/github.com/fsnotify/fsnotify/kqueue.go:498 +0x2fe
bitbucket.org/litkiosk/litkiosk_server/vendor/github.com/fsnotify/fsnotify.(*Watcher).readEvents(0xc42001c360)

/path_to_project/vendor/github.com/fsnotify/fsnotify/kqueue.go:284 +0xda
created by bitbucket.org/litkiosk/litkiosk_server/vendor/github.com/fsnotify/fsnotify.NewWatcher

/path_to_project/vendor/github.com/fsnotify/fsnotify/kqueue.go:62 +0x2c8

I added log in this function

func read(kq int, events []unix.Kevent_t, timeout *unix.Timespec) ([]unix.Kevent_t, error) {
	n, err := unix.Kevent(kq, nil, events, timeout)
	if err != nil {
		return nil, err
	}
	fmt.Println("n", n, "len", len(events), "cap", cap(events))
	return events[0:n], nil
}

and it prints

n 0 len 10 cap 10
n 0 len 10 cap 10
n 0 len 10 cap 10
n 0 len 10 cap 10
2017/07/15 12:00:40 debugger.go:505: continuing
n 33554795 len 10 cap 10

[joatmon]

I have been able to work around the panic by making the following modification in kqueue.go:

func min(x, y int) int {
	if x < y {
		return x
	}
	return y
}

// read retrieves pending events, or waits until an event occurs.
// A timeout of nil blocks indefinitely, while 0 polls the queue.
func read(kq int, events []unix.Kevent_t, timeout *unix.Timespec) ([]unix.Kevent_t, error) {
	n, err := unix.Kevent(kq, nil, events, timeout)
	if err != nil {
		return nil, err
	}
	n = min(n, len(events) - 1)   // new
	return events[0:n], nil
}

[xrfinbupt]

@glyn https://github.com/windmilleng/fsnotify the branch have done

[vinkdong]

+1 I have added some code to avoid this issue on my local machine

kquene.go

func read(kq int, events []unix.Kevent_t, timeout *unix.Timespec) ([]unix.Kevent_t, error) {
	n, err := unix.Kevent(kq, nil, events, timeout)
	if err != nil {
		return nil, err
	}
+	if len(events) < n {
+		n = 0
+	}
	return events[0:n], nil
}

[arp242]

I tried to reproduce this on FreeBSD, but wasn't able to. I used the CLI I added in #463 where I replaced the chan at the end with:

for {
    time.Sleep(100*time.Millisecond)
}

Then I ran dlv and set a breakpoint on that sleep:

% dlv debug ./cmd/fsnotify -- .
(dlv) break test cmd/fsnotify/main.go:68

And created events in another terminal (not sure this is needed):

% repeat 1000000; touch asd

Things seem to work when I keep continue-ing and I see the events, so either my steps are wrong, it appears only on macOS and not FreeBSD, or it was a bug in delve that has since been fixed.

---

The problem is that I don't know what the best fix is: if n is a very large number should it return nothing or as many events as possible? The eventBuffer is pre-allocated, so the proposed fix before of n = min(n, len(events) - 1) isn't necessarily correct (in fact, it's almost certainly incorrect).

The return value of 33554795 is very odd; is it consistently that value, or a random number?

[arp242]

I'll close this now assuming this is no longer an issue; please comment if it still is with steps to reproduce and we can open, investigate, and fix.