Examples: https://www.dropbox.com/s/c5cs2rz1zcssk3r/CrashTest.zip
StackTrace: https://www.dropbox.com/s/saff1d5z5z2vpon/PHPStackTraceSetLocale.png?dl=0

When adding this code before ts_resource(0); the crash remains but looks a little bit different. 
_configthreadlocale(_ENABLE_PER_THREAD_LOCALE);

MSDN: https://msdn.microsoft.com/de-de/library/26c0tb7x.aspx
We a calling this function in SAPI.c in sapi_startup. AFAIK this function is only called for the "main" thread. 
If i read the MSDN right, we need to call this function in all worker threads aswell. Neither one of the SAPIs does this!?

It's great you constantly aim improving the situation with TS builds :)

It looks correct to call configtreadlocale only once in the main thread. That's also what is being done in the snippet from the doc page. However, from the doc page:
[QUOTE]
These functions affect the behavior of setlocale, _tsetlocale, _wsetlocale, _beginthread, and _beginthreadex. If another method is used to create threads, the locale settings have no effect on those threads.
[/QUOTE]

I'm currently unaware whether std::thread() is using _beginthread(), maybe you could trace it? But if it doesn't, setlocale() will be clearly not thread safe so would require locking. 

FYI we use vc11 with PHP5 currently, and vc14 with 7.0. vc12 could possibly have build issues with PHP < 7 and in any case there are no dep libs builds for it.

Cheers.

I have another upcoming ZTS bugreport :) and thanks for your time and effort!

std::thread seems to properly use beginthread. Nevertheless i updated the example just to be sure. And i linked to threadlocale.obj to ensure that locales for each thread are enabled. I also compiled the PHP7 example with Visual Studio 2015 Update 1. The error remains :) Can you have a look if you can reproduce it aswell?

Updated Example:
unsigned __stdcall phpThread(void* params)
{
	ts_resource(0);

	while (true) {
		zend_file_handle file_handle;
		file_handle.type = ZEND_HANDLE_FILENAME;
		file_handle.filename = "date.php";
		file_handle.handle.fp = NULL;
		file_handle.opened_path = NULL;
		file_handle.free_filename = 0;

		if (php_request_startup(TSRMLS_C) == FAILURE) {
			//std::cout << "ERR" << std::endl;
			php_request_shutdown(NULL);
			continue;
		}

		if (php_execute_script(&file_handle TSRMLS_CC) == FAILURE)
			break;

		//std::cout << "RUN" << std::endl;
		php_request_shutdown(NULL);
	}

	std::cout << "DIED" << std::endl;

	return 0;
}

int main(int argc, const char * argv[]) {

	tsrm_startup(128, 1, 0, NULL);
	sapi_startup(&php_embed_module);

	php_embed_module.ini_entries = "date.timezone=Europe/Berlin\n\0";

	if (php_embed_module.startup(&php_embed_module) == FAILURE) {
		throw std::runtime_error("Could not start PHP!");
	}

	for (int i = 0; i < 10; i++) {
		_beginthreadex(NULL, 0, phpThread, NULL, 0, NULL);
		//std::thread([]{phpThread(NULL);}).detach();
	}

	while (true);

	return 0;
}

I used your latest variant and have some crash, too. But it's not about set locale

>	php7ts.dll!zend_hash_graceful_reverse_destroy(_zend_array * ht=0x0000020f71c909a0) Line 1489	C
 	php7ts.dll!shutdown_executor() Line 278	C
 	php7ts.dll!zend_deactivate() Line 969	C
 	php7ts.dll!php_request_shutdown(void * dummy=0x0000000000000000) Line 1826	C
 	bug71596.exe!phpThread(void * params=0x0000000000000000) Line 130	C++
 	bug71596.exe!thread_start<unsigned int (__cdecl*)(void * __ptr64)>(void * const parameter=0x00007ff621d579c4) Line 115	C++

It's incomplete yet, have to recompile a debug build to get more info on that. It currently shows a crash while destroying the symbol table on some RSHUTDOWN. This might or might not be related to your locale crash.

Btw, what is the content of your date.php, i was just putting some date("i"); in there from what i saw in your bt.

Thanks.

In my first comment i have attached a full project, if that helps.

Contents of date.php:
<?

//ini_set( 'date.timezone', 'Europe/Berlin' );
//date_default_timezone_set( 'Europe/Berlin' );
date("Ymd");

Oh yes, thanks. I was just using the code you posted directly into the thread :) so had nearly the same date() call.

I was finally able to reproduce crashes in setlocale, seems it was only passing by luck previously. I was reading through the docs again, there is another page where the docs are more clear https://msdn.microsoft.com/en-us/library/ms235302.aspx . Looks like what you told in the description is right. This is contradicting another doc page and the code snippet there a bit, telling that the _configthreadlocale has to be called in every thread.

If you apply this patch, rebuild PHP and the test program, do you see any setlocale crashes?

diff --git a/main/SAPI.c b/main/SAPI.c
index 9781f18..4084f7e 100644
--- a/main/SAPI.c
+++ b/main/SAPI.c
@@ -437,6 +437,9 @@ SAPI_API void sapi_activate_headers_only(void)

 SAPI_API void sapi_activate(void)
 {
+#if defined(PHP_WIN32) && defined(ZTS)
+       _configthreadlocale(_ENABLE_PER_THREAD_LOCALE);
+#endif
        zend_llist_init(&SG(sapi_headers).headers, sizeof(sapi_header_struct), (void (*)(void *)) sapi_free_header, 0);
        SG(sapi_headers).send_default_content_type = 1;

With this in, the crash i've posted previously remains. But the setlocale one disappears. You've mentioned previously that adding _configthreadlocale call to every thread changes your backtrace. How does it look like?

Thanks.

Thanks! That works flawlessly. 
Tested and works for 5.6.18 aswell, if you want to backport the patch.

Regarding the other issue: I was not able to reproduce the crash using a debug build. I saw it once in the release version... but had no good backtrace. If it happens again with a good backtrace i will post it.

Regarding my statement that the backtrace changed: I think it was only looking a bit different, but was also due to the setlocale bug. It never had to do anything with the shutdown crash.

Thanks very much for the follow up. I'll apply this one to 5.6 then. Bug #71129 is certainly an issue as well, but an unrelated one. Probably it's good so, fixing them step by step and testing good.

Thanks!

Applied in 632fc51d98494565a71ae97a81bd7d440dbb116a.

Thanks.