Ticket #14854 (closed defect: fixed)
wxFileSystemWatcher: unexpectedly getting inotify events after IN_IGNORED
|Reported by:||dghart||Owned by:|
I inadvertently discovered a way to stress-test the wxGTK wxFileSystemWatcher: run your wxLogTrace-enabled app inside konsole, then set a watch on the file to which konsole logs. Lots of IN_ACCESS events get produced.
This revealed three problems with the current code:
First, IN_Q_OVERFLOW events have a wd of -1, which will currently trigger the 'unknown watch descriptor' wxFAIL_MSG before the 'warnings' section is reached. Also, in the patch committed as r72986, I forgot to 'return' after catching an error or warning; so the event continues to be processed. Both of these errors are fixed in patch1.diff.
Second, I've received occasional non-IN_Q_OVERFLOW events with a wd of -1. Presumably other warnings/errors will have this wd, but for me they've all been IN_ACCESS or IN_CREATE. I don't know why it happens, but patch2.diff adds a wxLogWarning for them.
Third, and rarer, are IN_ACCESS events that arrive just _after_ the wd's IN_IGNORED event. This means that the wd is no longer in the stale-descriptors map, so the wxFAIL_MSG is triggered. I don't know why this can happen but it seems quite sensitive to the amount of tracing that gets logged, so there may be a race condition somewhere. I can't see one in the wx code; perhaps it's in inotify itself.
One fix would be to delay removing the wd after IN_IGNORED, i.e. derive from wxEvtHandler, post an wxEvent when IN_IGNORED arrives and do the removal in the handler. I've successfully tested that here and I could create a patch; but you may feel it's an overreaction to a rare situation.
Meanwhile patch3.diff just changes the wxFAIL_MSG to a less-intrusive wxLogWarning.