Page 1 of 1

FAR3 build 1800 - occasional freezes on exit

Posted: Fri 14 Mar, 2014 15:27
by pepak
FAR3 build 1800 occasionally freezes on me. I have yet to discover the precise cause, but it seems to occur more frequently if I have two FAR instances (A and B) running and decide to quit one (A). From time to time A freezes in the console window and remains there for a long time (possibly forever? not sure) or until I kill it in task manager. In this state, if I switch to B and use a folder shortcut to change directory, then B also freezes (again, possibly forever). If I run yet another instance (C) in this state, it will freeze before getting to the regular blue FAR window. But as soon as I kill all instances frozen in this manner, next instance will work just fine.

I suspect the freezes might be related to SQlite locking, but I have no idea how to verify it. I used ProcMon on instance C (from the example above) and it seemed to always freeze at the same point, but I am not so sure the ProcMon's output would be very helpful in determining the exact place. I will try to save it the next time I get into this situation, just to be certain.

Re: FAR3 build 1800 - occasional freezes on exit

Posted: Tue 01 Apr, 2014 12:44
by pepak
Some more info:

- One instance of FAR Manager freezes while closing. As far as I can tell, this happens before any plugin gets a chance to respond to ExitFarW.
- From that moment, other running instances will freeze if I try to exit them, if I try to read FAR settings (such as directory shortcuts), if they try to read some plugin's config, and possibly in other situations.
- If I try to run a new instance of FAR Manager, it will freeze during startup.
- If I close all running (or frozen) instances of FAR, the lock disappears and I can once again start new instances.

I did some experimenting with running the new instances in this situation:

- As I said before, if I run a new instance, it freezes.
- But it also freezes if I copy the whole FAR 3 installation to a new location (a real copy, no junctions/links/etc. concerned; far.exe.ini specifies profile locations in %FARHOME%\Profile, so it's not even a case of profile files being locked for exclusive access).
- If I also delete all plugins, FAR still freezes.
- If I also delete the profile, FAR still freezes.
- If I also delete far.exe.ini (moving the profile dir to its default location in C:\Users, where no FAR profile is located originally), FAR will create Profile\PluginsData (empty), Profile\associations.db, Profile\colors.db, Profile\generalconfig.db and Profile\pluginhotkeys.db and then freeze. All four .db files remain locked for deletion or writing, though they can be read.
- Process Monitor shows that the last access to Windows-managed resources was reading the whole far.exe.ini into memory. Before that, there were a great many accesses to colors.db, localconfig.db, generalconfig.db (newest -> oldest). Before those, some reads of HKLM\Software\Microsoft\SQMClient were performed (no idea what that is, but it seems some more registry reads are mixed in with more work with generalconfig.db, so perhaps these registry acesses signify reading of default values for some settings). Before that, an attempt was made to read Default.farconfig, which didn't exist.

I can upload the Process Monitor log file which shows what happens to one FAR instance when it tries to start. Would that possibly help?