Sublime Text 4200 "process leak"

[IOI]

One day when I was going to log off my PC, I find several plugin_host-3.8.exe shown in taskmgr.exe. I was so surprised.

plugin_host-3.8.exe and crash_handler.exe are usually ended on the shutdown of sublime_text.exe; It is designed to be that, however, it occationally doesn’t.

And… it seems each plugin_host-3.8.exe comes with a crash_handler.exe

You may not easily observe this problem. But I would like to show how I reproduced this (also by some little chance).

With a fresh installation from official sublime_text_build_4200_x64.zip (portable);

Repeat: open the ST app, type/edit something on some draft text, then close ST,
until you observed plugin_host-3.8.exe process still exists after closed ST.

And sometimes the plugin host process doesn’t exit even do nothing in ST (just open ST and close it in few seconds).

Fortunately, It seems not lead to data damage/lost.

[bschaaf]

This is likely caused by a plugin or other third party software. You can confirm this by starting ST in safe mode.

The way a plugin would cause this is by spawning another process that it doesn’t stop for one reason or another.

[IOI]

No third party plugin installed, it’s fresh installation (simply unpacked).
And I can confirm no third party software is intervening (no thrid party DLLs in ST processes).

Here is some output by the process explorer:
(the stack of a thread of the “hanging” process plugin_host-3.8.exe)

ntoskrnl.exe!KeWaitForMultipleObjects+0xc0a
ntoskrnl.exe!KeAcquireSpinLockAtDpcLevel+0x712
ntoskrnl.exe!KeWaitForMutexObject+0x19f
ntoskrnl.exe!NtWaitForSingleObject+0xde
ntoskrnl.exe!KeSynchronizeExecution+0x3a23
ntdll.dll!ZwWaitForSingleObject+0xa
ntdll.dll!RtlDeNormalizeProcessParams+0x5a8
ntdll.dll!RtlDeNormalizeProcessParams+0x4a4
ntdll.dll!LdrGetProcedureAddressEx+0x2e4
ntdll.dll!LdrGetProcedureAddress+0x11
KernelBase.dll!GetProcAddress+0x60
!initialize_narrow_environment+0xfd
!W_Gettnames+0x997
!Gettnames+0x1f5
!Gettnames+0x99
!errno+0x408
!o__initialize_onexit_table+0xc3
!o__wcsicmp+0xa3d
!free_base+0x6a
!qsort_s+0x9b7
!_pctype_func+0x16f
!qsort_s+0x9f5
!__lc_locale_name_func+0x378
!setlocale+0x22
!Py_get_xoption+0x6c1
!Py_PreInitializeFromPyArgv+0x136
!Py_PreInitializeFromConfig+0xf1
!PyConfig_SetString+0xec
!PyConfig_SetBytesString+0x1f
!init_sublime_api+0x60fa
!init_sublime_api+0x47385
!init_sublime_api+0x18f107
kernel32.dll!BaseThreadInitThunk+0xd
ntdll.dll!RtlUserThreadStart+0x21

If the stack trace is correct, looks like some python API is calling the CRT locale APIs which is then (forever) waiting for some lock.
And note that all plugin_host-3.3.exe exited successfully.
So maybe it’s the python38.dll that caused the “hanging”, in some rare situation.

[bschaaf]

That stack trace looks like it’s stuck on initialization. That would mean the 3.8 plugin host isn’t functioning at all, is that what you’re observing in ST? Are menus like Preferences > Settings permanently grayed out?

[IOI]

In latest test, I see when “Goto” > “Goto Definition…”, “Goto Reference…” , “Jump Back”, “Jump Forward” is grayed out, then the 3.8 plugin host will not exit.

And I dont know why CRT function setlocale() is hanging there.

[bschaaf]

Do you have an anti-virus or similar program that might be interfering?

[IOI]

Neither exists. And if there were some program making plugin_host-3.8.exe hanging at setlocale(), I am afraid it must make a mess in my system.

setlocale() is not thread safe, and the “hanging” confirmed this.
So I guess there are data races.
Is it possible some other thread is started before the main thread calling PyConfig_SetBytesString(), and so there would be a risk of data races if CRT locale functions is called, directly or indirectly, by multiple threads in the meantime.

[bschaaf]

There’s no other threads created before we initialize python. Give that this is happening consistently for you and there aren’t hundreds of complaints about plugins not working, that strongly confirms that this is an issue specific to your setup.

What version of Windows are you using?

[IOI]

Windows 7 x64.

The “successful” host process have more modules loaded than the “hanging” process:

C_1252.NLS
cryptbase.dll
cryptsp.dll
kernel32.dll.mui
KernelBase.dll.mui
locale.nls
rsaenh.dll
SortDefault.nls

Now I see the “hanging point” is not inside the CRT, its in the NT Ldr module.
Maybe OpenSSL (dep. of python38.dll) is loading some DLL while PyConfig_SetBytesString() is calling setlocale() which calls LdrGetProcedureAddress() -> “data race”.

[bschaaf]

It could be this issue: https://bugs.python.org/issue26624, which seems to be a bug in windows. We will be dropping support for Windows 7 in the next release of Sublime Text, so unfortunately this won’t be fixed.

[IOI]

There’s no other threads created before we initialize python.

The main thread is started at !init_sublime_api+0x18f175.
There is another thead (started at !init_sublime_api+0x1b5cc) waiting for the same lock:

ntoskrnl.exe!KeWaitForMultipleObjects+0xc0a
ntoskrnl.exe!KeAcquireSpinLockAtDpcLevel+0x712
ntoskrnl.exe!KeWaitForMutexObject+0x19f
ntoskrnl.exe!NtWaitForSingleObject+0xde
ntoskrnl.exe!KeSynchronizeExecution+0x3a23
ntdll.dll!ZwWaitForSingleObject+0xa
ntdll.dll!RtlDeNormalizeProcessParams+0x5a8
ntdll.dll!RtlDeNormalizeProcessParams+0x4a4
!qsort_s+0x7ef
!qsort_s+0x1315
ntdll.dll!RtlUserThreadStart+0x1d9
ntdll.dll!LdrInitializeThunk+0x10f
ntdll.dll!LdrInitializeThunk+0xe