From 9a7276dffc7bf87104408f74ecae3b34bf6d769d Mon Sep 17 00:00:00 2001 From: Richard Townsend Date: Wed, 24 Jul 2019 16:16:53 +0100 Subject: [PATCH] fix: remove TLS destruction (#19365) Building with dchecks_always_on=true in release configuration seems to introduce flakiness because the TLS is double-freed. Amending the check seems to fix the flakiness. --- shell/app/atom_main.cc | 17 ----------------- 1 file changed, 17 deletions(-) diff --git a/shell/app/atom_main.cc b/shell/app/atom_main.cc index e58a68b016e6..e09c23d73339 100644 --- a/shell/app/atom_main.cc +++ b/shell/app/atom_main.cc @@ -134,23 +134,6 @@ int APIENTRY wWinMain(HINSTANCE instance, HINSTANCE, wchar_t* cmd, int) { if (run_as_node || !IsEnvSet("ELECTRON_NO_ATTACH_CONSOLE")) base::RouteStdioToConsole(false); -#ifndef DEBUG - // Chromium has its own TLS subsystem which supports automatic destruction - // of thread-local data, and also depends on memory allocation routines - // provided by the CRT. The problem is that the auto-destruction mechanism - // uses a hidden feature of the OS loader which calls a callback on thread - // exit, but only after all loaded DLLs have been detached. Since the CRT is - // also a DLL, it happens that by the time Chromium's `OnThreadExit` function - // is called, the heap functions, though still in memory, no longer perform - // their duties, and when Chromium calls `free` on its buffer, it triggers - // an access violation error. - // We work around this problem by invoking Chromium's `OnThreadExit` in time - // from within the CRT's atexit facility, ensuring the heap functions are - // still active. The second invocation from the OS loader will be a no-op. - extern void NTAPI OnThreadExit(PVOID module, DWORD reason, PVOID reserved); - atexit([]() { OnThreadExit(nullptr, DLL_THREAD_DETACH, nullptr); }); -#endif - std::vector argv(arguments.argc); std::transform(arguments.argv, arguments.argv + arguments.argc, argv.begin(), [](auto& a) { return _strdup(base::WideToUTF8(a).c_str()); });