bug(developer): starting multiple instances of TIKE simultaneously causes `EFOpenError`
sentry-io opened this issue · 2 comments
Sentry Issue: KEYMAN-DEVELOPER-1PR
OS Version: Windows 10.0.19045 (4291)
Report Version: 104
Application Specific Information:
Exception EFOpenError in module tike.exe at 000797B7.
Cannot open file "C:\Users\AHSN LAPTOP\Documents\Keyman Developer\Projects\kuswa_s_keyboard\kuswa_s_keyboard.kpj". The process cannot access the file because it is being used by another process.
Thread 0
0 tike.exe 0x4797b7 System.Classes.TFileStream.Create (System.Classes.pas:9208)
1 tike.exe 0x47966c System.Classes.TFileStream.Create (System.Classes.pas:9178)
2 tike.exe 0x73845f Keyman.Developer.System.Project.ProjectFile.TProject.Load (Keyman.Developer.System.Project.ProjectFile.pas:844)
3 tike.exe 0xe99321 Keyman.Developer.UI.Project.ProjectFileUI.TProjectUI.Load (Keyman.Developer.UI.Project.ProjectFileUI.pas:164)
4 tike.exe 0x7380bd Keyman.Developer.System.Project.ProjectFile.TProject.Create (Keyman.Developer.System.Project.ProjectFile.pas:782)
5 tike.exe 0xe9914d Keyman.Developer.UI.Project.ProjectFileUI.TProjectUI.Create (Keyman.Developer.UI.Project.ProjectFileUI.pas:137)
6 tike.exe 0x8fef95 Keyman.Developer.UI.Project.ProjectUI.LoadGlobalProjectUI (Keyman.Developer.UI.Project.ProjectUI.pas:96)
7 tike.exe 0xe9264f UfrmMain.TfrmKeymanDeveloper.FormCreate (UfrmMain.pas:597)
8 tike.exe 0x7c326f JvDockControlForm.TJvDockBaseControl.DoFormOnCreate (JvDockControlForm.pas:2378)
9 tike.exe 0x679ace Vcl.Forms.TCustomForm.AfterConstruction (Vcl.Forms.pas:3722)
10 tike.exe 0x679a7f Vcl.Forms.TCustomForm.Create (Vcl.Forms.pas:3712)
11 tike.exe 0x685110 Vcl.Forms.TApplication.CreateForm (Vcl.Forms.pas:10866)
12 tike.exe 0xe9ca69 Keyman.Developer.System.Main.RunWithExceptionsHandled (Keyman.Developer.System.Main.pas:73)
13 tike.exe 0xe9c8f2 Keyman.Developer.System.Main.RunKeymanDeveloper (Keyman.Developer.System.Main.pas:43)
14 tike.exe 0xeb5388 tike.tike
15 KERNEL32.DLL 0x7755fcc8 BaseThreadInitThunk
16 ntdll.dll 0x77d07c5d _RtlUserThreadStart
17 ntdll.dll 0x77d07c2d _RtlUserThreadStart
17.0.325
I was able to replicate this by running tike && tike
at the command line -- indicating a race when two instances both try to load the project at the same time
This may require some rearchitecture of the TMultiProcessCoordinator
to remove its dependency on window enumeration, because we enumerate the running processes before we create the main window, which means two processes may each independently do the window enumeration, find no windows, and both end up becoming the 'first' process, attempting to load the last open project.
Or we could always create the window before calling the enumeration? (This may have other side-effects to consider.)
Or as a stop-gap, we could fall back to a null-project scenario in the case of file lock, which would reduce the incidence of this.