MYSQL_ATTR_INIT_COMMAND causing "The FastCGI process exited unexpectedly"

[HeavenCore]

Description

We have some PHP code that has ran fine for years under PHP 7 / IIS / FastCGI

When updating to PHP 8.1.9 we're getting "The FastCGI process exited unexpectedly"

After digging through the code we have identified the issue as follows:

When using PDO::MYSQL_ATTR_INIT_COMMAND in the new PDO() constructor - FastCGI just dies

		$options = [
			PDO::ATTR_ERRMODE            => PDO::ERRMODE_EXCEPTION,
			PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC,
			PDO::ATTR_EMULATE_PREPARES   => false,
			PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES utf8mb4;"
		];

            $this->m_db = new PDO(
                $m_PDOConnectionString,
                $Username,
                $Password,
                $options
            );

Resulted in this output:

C:\Program Files (x86)\PHP\v8.1.9.dev\php-cgi.exe - The FastCGI process exited unexpectedly

But I expected this output instead:

N/A - expected DB connection to open as normal

Only thing i can find in the windows event log is as follows:

Faulting application name: php-cgi.exe, version: 8.1.9.0, time stamp: 0x62e93213
Faulting module name: php8.dll, version: 8.1.9.0, time stamp: 0x62e93aac
Exception code: 0xc0000005
Fault offset: 0x00008fac
Faulting process id: 0x4d4
Faulting application start time: 0x01d8b3db35c39991
Faulting application path: C:\Program Files (x86)\PHP\v8.1.9.dev\php-cgi.exe
Faulting module path: C:\Program Files (x86)\PHP\v8.1.9.dev\php8.dll
Report Id: 3737167c-6b9f-48b2-bdfb-74baff4570ec
Faulting package full name: 
Faulting package-relative application ID: 

Removing MYSQL_ATTR_INIT_COMMAND solves the prooblem and everything starts working again.

The systax we're using here, i.e. "SET NAMES utf8mb4;" is a valid MySQL command which we've tested in mySQL workbench etc

Is this related to #9143 i wonder?

PHP Version

8.1.9

Operating System

Windows Server 2019

[cmb69]

I cannot reproduce this segfault. Could you please try to generate a stack backtrace?

[HeavenCore]

Good Morning,

Backtrace below as requested:

Error

In php-cgi.exe_220823_081756.dmp the assembly instruction at php8!emalloc+5c in C:\Program Files (x86)\PHP\v8.1.9.dev\php8.dll from The PHP Group has caused an access violation exception (0xC0000005) when trying to read from memory location 0x0f003b34 on thread 0

Faulting Thread

Entry Point: php_cgi!mainCRTStartup

php8!emalloc+5c [D:\a\php-ftw\php-ftw\php\vs16\x86\php-8.1.9\Zend\zend_alloc.c @ 2541 + 45]	0000009	fba90c0	0000000	f300014	D:\a\php-ftw\php-ftw\php\vs16\x86\php-8.1.9\Zend\zend_alloc.c @ 2541 + 45
php8!_mysqlnd_pestrndup+58 [D:\a\php-ftw\php-ftw\php\vs16\x86\php-8.1.9\ext\mysqlnd\mysqlnd_alloc.c @ 306]	f353080	0000009	0000000	f300014	D:\a\php-ftw\php-ftw\php\vs16\x86\php-8.1.9\ext\mysqlnd\mysqlnd_alloc.c @ 306
php8!mysqlnd_set_persistent_string+52 [D:\a\php-ftw\php-ftw\php\vs16\x86\php-8.1.9\ext\mysqlnd\mysqlnd_alloc.h @ 93 + 2]	f300014	f353080	0000009	0000000	D:\a\php-ftw\php-ftw\php\vs16\x86\php-8.1.9\ext\mysqlnd\mysqlnd_alloc.h @ 93 + 2
php8!mysqlnd_mysqlnd_conn_data_connect_pub+553 [D:\a\php-ftw\php-ftw\php\vs16\x86\php-8.1.9\ext\mysqlnd\mysqlnd_connection.c @ 677]	f300008	f353080	0000009	f353070	D:\a\php-ftw\php-ftw\php\vs16\x86\php-8.1.9\ext\mysqlnd\mysqlnd_connection.c @ 677
php8!mysqlnd_mysqlnd_conn_connect_pub+a2 [D:\a\php-ftw\php-ftw\php\vs16\x86\php-8.1.9\ext\mysqlnd\mysqlnd_connection.c @ 768 + 2]	f2ac9f8	f353080	0000009	f353070	D:\a\php-ftw\php-ftw\php\vs16\x86\php-8.1.9\ext\mysqlnd\mysqlnd_connection.c @ 768 + 2
php8!mysqlnd_connection_connect+131 [D:\a\php-ftw\php-ftw\php\vs16\x86\php-8.1.9\ext\mysqlnd\mysqlnd_connection.c @ 2325 + 2]	f2ac9f8	f353080	f353070	f2adaf0	D:\a\php-ftw\php-ftw\php\vs16\x86\php-8.1.9\ext\mysqlnd\mysqlnd_connection.c @ 2325 + 2
php_pdo_mysql!pdo_mysql_handle_factory+8c5 [D:\a\php-ftw\php-ftw\php\vs16\x86\php-8.1.9\ext\pdo_mysql\mysql_driver.c @ 937 + 24]	f2b0a00	f215f30	0000000	fd07b90	D:\a\php-ftw\php-ftw\php\vs16\x86\php-8.1.9\ext\pdo_mysql\mysql_driver.c @ 937 + 24
php8!zim_PDO___construct+62d [D:\a\php-ftw\php-ftw\php\vs16\x86\php-8.1.9\ext\pdo\pdo_dbh.c @ 386 + 2]	f31578c	faf5ff0	f3ad1d0	f215c00	D:\a\php-ftw\php-ftw\php\vs16\x86\php-8.1.9\ext\pdo\pdo_dbh.c @ 386 + 2
php8!ZEND_DO_FCALL_SPEC_RETVAL_UNUSED_HANDLER+64 [D:\a\php-ftw\php-ftw\php\vs16\x86\php-8.1.9\Zend\zend_vm_execute.h @ 1779]	f214010	faf73d0	0000000	0000000	D:\a\php-ftw\php-ftw\php\vs16\x86\php-8.1.9\Zend\zend_vm_execute.h @ 1779
php8!execute_ex+96 [D:\a\php-ftw\php-ftw\php\vs16\x86\php-8.1.9\Zend\zend_vm_execute.h @ 55562 + 4]	f214010	f26b240	f2790a0	6c2c160	D:\a\php-ftw\php-ftw\php\vs16\x86\php-8.1.9\Zend\zend_vm_execute.h @ 55562 + 4
php8!zend_execute+11d [D:\a\php-ftw\php-ftw\php\vs16\x86\php-8.1.9\Zend\zend_vm_execute.h @ 60125]	f2790a0	0000000	0000000	0000000	D:\a\php-ftw\php-ftw\php\vs16\x86\php-8.1.9\Zend\zend_vm_execute.h @ 60125
php8!zend_execute_scripts+157 [D:\a\php-ftw\php-ftw\php\vs16\x86\php-8.1.9\Zend\zend.c @ 1790 + 9]	0000008	0000000	0000003	0000000	D:\a\php-ftw\php-ftw\php\vs16\x86\php-8.1.9\Zend\zend.c @ 1790 + 9
php8!php_execute_script+238 [D:\a\php-ftw\php-ftw\php\vs16\x86\php-8.1.9\main\main.c @ 2539 + f]	6c2eb20	08d34c0	08cd828	06c9000	D:\a\php-ftw\php-ftw\php\vs16\x86\php-8.1.9\main\main.c @ 2539 + f
php_cgi!main+12e5 [D:\a\php-ftw\php-ftw\php\vs16\x86\php-8.1.9\sapi\cgi\cgi_main.c @ 2525 + a]	0000001	08cd828	08d34c0	3445a40	D:\a\php-ftw\php-ftw\php\vs16\x86\php-8.1.9\sapi\cgi\cgi_main.c @ 2525 + a
php_cgi!__scrt_common_main_seh+fa [D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 288 + 1c]	06c9000	7990400	6c2fd78	7bc77fd	D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 288 + 1c
kernel32!BaseThreadInitThunk+19	06c9000	d18ad98	0000000	0000000
ntdll!RtlGetAppContainerNamedObjectPath+ed	fffffff	7be714b	0000000	0000000
ntdll!RtlGetAppContainerNamedObjectPath+bd	0c12cb0	06c9000	0000000	0000000

[HeavenCore]

Above trace was produced by un-commenting the following:

PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES utf8mb4;"

in the following code block:

$options = [
	PDO::ATTR_ERRMODE            => PDO::ERRMODE_EXCEPTION,
	PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC,
	PDO::ATTR_EMULATE_PREPARES   => false,
	//PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES utf8mb4;"
];

$this->m_db = new PDO(
	$m_PDOConnectionString,
	$Username,
	$Password,
	$options
);

WIth this line commented out the application compiles and runs normally.

[cmb69]

Thank you for the backtrace! This is likely not the root cause, but may just be a cause of a prior memory mismanagement. I'm not able to find anything, though, especially something related to the MYSQL_ATTR_INIT_COMMAND.

At least the backtrace shows that this happens with a 32bit build; can you also reproduce the issue with a 64bit build?

[HeavenCore]

wow, that's very interesting - i've been unable to recreate the issue in x64 - so yep, appears to be an x86 issue only :)

I'll advise the customer to use x64 going forward.

I suspect you're correct, perhaps it's not reserving enough memory for the PDO option array or something, i.e. it's the number of options in the array as opposed to the array items themselves? That's outside my area of expertise though - looking forward to hearing from a clever person as to what the actual issue is in x86.

OffTopic: is there any plans to kill x86 PHP?

[cmb69]

I'll advise the customer to use x64 going forward.

That is generally a good idea (as of PHP 7.0.0 on Windows). :)

OffTopic: is there any plans to kill x86 PHP?

It has been suggested a few times, but probably that won't happen soon (one argument is support for embedded devices etc.)

[hormus]

@HeavenCore

<?php

//mysql extension was deprecated in PHP 5.5.0, and it was removed in PHP 7.0.0. Use MYSQLI extension or PDO extension or PDO_MYSQL extension
$check = \PDO::getAvailableDrivers();
if(in_array('mysql', $check)) {
$options = [
			\PDO::ATTR_ERRMODE            => \PDO::ERRMODE_EXCEPTION,
			\PDO::ATTR_DEFAULT_FETCH_MODE => \PDO::FETCH_ASSOC,
			\PDO::ATTR_EMULATE_PREPARES   => false,
			1002 => "SET NAMES 'utf8mb4' COLLATE 'utf8mb4_general_ci';"
		];
$one = 0;
if(defined('PDO::MYSQL_ATTR_INIT_COMMAND')) {
//$one 0 or 1 only with MYSQLND enabled (MYSQL Native Driver) for php < 5.3.6 and start from php 5.3.1. not recommended as of php > 5.3.6 use DSN charset=charset_name
$one = 1;
}
var_dump($options, $one);
} else {
echo 'don\'t support mysql';
}

//DSN PHP >= 5.3.6 optional charset=utf8mb4
?>

Expected Result 1:
array(4) { [3]=> int(2) [19]=> int(2) [20]=> bool(false) [1002]=> string(49) "SET NAMES 'utf8mb4' COLLATE 'utf8mb4_general_ci';" } int(1)

Or expected result 2:
array(4) { [3]=> int(2) [19]=> int(2) [20]=> bool(false) [1002]=> string(49) "SET NAMES 'utf8mb4' COLLATE 'utf8mb4_general_ci';" } int(0)

[HeavenCore]

@hormus I realise that mysql was depreciated and removed, but thats' not to be confused with the PDO mySQL driver, they're completley different beasts.

Also, that constant is still perfectly valid in the latest PDO documentationn:

https://www.php.net/manual/en/ref.pdo-mysql.php

And note the mysql connection string is still using mysql: in their PDO documentation:

https://www.php.net/manual/en/pdo.construct.php

and finally, the code works perfectly fine in PHP 8.1.9 x64 (it was just x86 that segfaulted) - so I really doubt its a depreciation issue.

Edit: and even if it was a depreciation issue / constant not existing, it shouldnt segfault, it should show a compilation error and line number