230206 2021-09-12 20:45:03 -0700 WebKit2 crashes when initializing due to not-threadsafe call to _NSGetEnviron() 2021-09-17 16:48:56 -0700 1 1 1 Unclassified WebKit WebKit2 Safari Technology Preview iPhone / iPad iOS 14 RESOLVED INVALID InRadar P2 Major --- 1 jinhao.zhang webkit-unassigned ap kevin_neal kkinnunen webkit-bug-importer oldest_to_newest 1792839 0 jinhao.zhang 2021-09-12 20:45:03 -0700 When WebKit2 is to initialize, it calls _NSGetEnviron() to get all env variables. The code is as below: ( in file: Options.cpp, method: void Options::initialize() ) #if PLATFORM(COCOA) bool hasBadOptions = false; for (char** envp = *_NSGetEnviron(); *envp; envp++) { const char* env = *envp; if (!strncmp("JSC_", env, 4)) { if (!Options::setOption(&env[4])) { dataLog("ERROR: invalid option: ", *envp, "\n"); hasBadOptions = true; } } } However, _NSGetEnviron is not thread-safe. If there is another thread calling putenv(), there is a small chance that WebKit crashes due to invalid pointer sent to strncpm(). This is due to putenv() is using 'realloc' when necessary, which invalidates the old pointer values. 1792877 1 kkinnunen 2021-09-13 01:10:29 -0700 I think modifying environment is inherently single-threaded operation. Is there a place in WebKit which modifies the environment in such a way that causes WebKit to crash in this location during initialisation? 1792917 2 jinhao.zhang 2021-09-13 04:50:49 -0700 (In reply to Kimmo Kinnunen from comment #1) > I think modifying environment is inherently single-threaded operation. > Is there a place in WebKit which modifies the environment in such a way that > causes WebKit to crash in this location during initialisation? AFAIK there isn't. This crashing is due to some third party code naively called putenv() in non-main threads and caused racing condition issues while WebKit2 was initializing itself in main thread. 1793101 3 ap 2021-09-13 14:33:01 -0700 Given the above, is there a WebKit issue to track here? 1793203 4 kkinnunen 2021-09-13 23:07:59 -0700 (In reply to white from comment #2) > (In reply to Kimmo Kinnunen from comment #1) > > I think modifying environment is inherently single-threaded operation. > > Is there a place in WebKit which modifies the environment in such a way that > > causes WebKit to crash in this location during initialisation? > > AFAIK there isn't. > > This crashing is due to some third party code naively called putenv() in > non-main threads and caused racing condition issues while WebKit2 was > initializing itself in main thread. So spelled out what Alexey mentioned: There are two options: A) Third-party code modifies the environment in single-threaded manner or B) WebKit should never use the environment I believe this option is impossible to get correct: C) Third-party code modifies the environment in random threads at random points in time, WebKit uses the environment I think B would be a progression in many ways, one of which would be the bug you mention, but this is just an opinion. However, there is a lot of environment use in WebKit, so it might not be such an easy task for what it accomplishes. Also, other components could use the environment. This particular crash is a bit odd since intuitively the client process should not use JSC, and hence should not crash here. However, there is still the issue of other locations using the environment. 1793736 5 webkit-bug-importer 2021-09-15 09:56:20 -0700 <rdar://problem/83155440> 1794695 6 ap 2021-09-17 16:48:56 -0700 > Also, other components could use the environment. Other system frameworks certainly do use the environment. There is also a huge number of getenv calls in WebKit, not just this one _NSGetEnviron use in JavaScriptCore.