#14863 closed defect (fixed)

wxFileSystemWatcher: inappropriate assert with IN_MOVE_FROM

Reported by: dghart Owned by:
Priority: normal Milestone: 2.9.5
Component: base Version: stable-latest
Keywords: wxFileSystemWatcher IN_MOVE_FROM Cc:
Blocked By: Blocking:
Patch: yes

Description

There is a problem with wxFSWatcherImplUnix::ProcessRenames. I found this when an assert was reproducibly triggered in my app, but rather than trying to describe that complex situation I'll talk about a simple one.

When ProcessNativeEvent() finds an IN_MOVE_FROM it adds its cookie to the m_cookies map. If a corresponding IN_MOVE_TO arrives soon after, both are dealt with correctly and the cookie removed. Then ProcessRenames() is called. Despite its name I think it's meant to deal with isolated IN_MOVE_FROMs, such as should occur when a file is moved from a watched dir to an unwatched one.

ProcessRenames() uses the event.wd to look up the watch in m_watchMap. The problem comes when, as in my situation, the watch has just been removed. The wd will probably be in the stale-descriptors list, but ProcessRenames() doesn't look there. Instead it asserts; then aborts without erasing the cookie, so the same assert will be triggered for every future ProcessRenames() call.

My first thought was to check the stale-descriptors list too. However there won't be any corresponding wxFSWatchEntry as this isn't cached there; and anyway, if the wd is there it means that the watch has been removed and the owner doesn't care any longer. So the patch just erases the unused cookie, without asserting.

Attachments (1)

ProcessRenames.diff download (1.7 KB) - added by dghart 21 months ago.

Download all attachments as: .zip

Change History (2)

Changed 21 months ago by dghart

comment:1 Changed 21 months ago by VZ

  • Resolution set to fixed
  • Status changed from new to closed

(In [73065]) Don't assert when stopping watching a just renamed file.

(Almost) silently ignore renames of the files which we don't watch any longer
instead of asserting if this happens.

Closes #14863.

Note: See TracTickets for help on using tickets.