Panic in windows on loopevent
imsodin opened this issue · comments
From syncthing/syncthing#7063:
The panic happened without any user intervention. Syncthing had just been doing its job, and I only found the log file later.
The log comes from Syncthing v1.10.0 (x86-32) running in Windows 10 Enterprise 2016 LTSB x86.
panic: runtime error: invalid memory address or nil pointer dereference [signal 0xc0000005 code=0x0 addr=0x0 pc=0xbe295e] goroutine 184 [running]: github.com/syncthing/notify.(*readdcw).loopevent(0x12c881e0, 0x62, 0x139f7880) github.com/syncthing/notify@v0.0.0-20190709140112-69c7a957d3e2/watcher_readdcw.go:400 +0x3e github.com/syncthing/notify.(*readdcw).loop(0x12c881e0) github.com/syncthing/notify@v0.0.0-20190709140112-69c7a957d3e2/watcher_readdcw.go:362 +0xb7 created by github.com/syncthing/notify.(*readdcw).lazyinit github.com/syncthing/notify@v0.0.0-20190709140112-69c7a957d3e2/watcher_readdcw.go:335 +0xa2
Unfortunately it sounds like it isn't clear when/how it happens. However maybe the trace already points at what might be the culprit. I'll report back if any more details come up.
@imsodin thanks for submitting this issue! I don't have access to that particular Windows version and it seems it's not easily reproducible anyway. However, it could be the case that we receive incomplete status when the machine is being woken up.
I created a #192 that does two things:
- should prevent
notifyfrom panicking when this issue occurs again, - should give us more info on what's happening in the system(yet only in debug mode).
Note, that when the Overlapped structure does not include our extended(grip) object, we won't be able to retrieve any events. Thus, the check I added will not result in filesystem notifications loss.
Thanks a lot for the speedy resolution. I guessed that it will be hard to reproduce/get to the bottom, but hoped you'd see what might cause it anyway and/or a general mitigation - and you did, awesome :)