Faulting module name: ODBC32.dll

[dga26]

Hi,
I have posted this bug on php.net portal : https://bugs.php.net/bug.php?id=74710
I can send you more stacktrace or analysis informations from debugdiag or procmon explorer..

The most important to keep is :
i use pdo_sqlsrv pre-release from latest 4.2.0 (https://github.com/Microsoft/msphpsql/releases/tag/v4.2.0-preview) and test many before.

Everytime php-cgi process failed with
Faulting application path: C:\PHP\php-cgi.exe
Faulting module path: C:\Windows\SYSTEM32\ODBC32.dll

Do you have any idea about this bug?

Regards

David

[ulvii]

Hi @dga26 ,

I would suggest to setup a clean VM, try to run the script using php-cli (command line). If the issue still persists, please post the steps to recreate your environment, such as OS, MSODBCSQL version, PHP configure options ( php -i | grep "Configure Command" ) and any other details that you think are relevant.

Please also make sure that, you provide a php script that reproduces the crash.

[dga26]

Hi @ulvii

Thanks for your answer.
Sorry i can't reinstall this clean vm (from customer install))
I send you the php -i result (i replace private data by xxx)

I notice that i try without any other php extension and the problem is the same

The release windows vm is :

php.txt

[dga26]

Php side debug with full informations

[ulvii]

Hi @dga26 ,

1. Are you running into this issue when pdo_sqlsrv is not loaded?
2. Have you tried updating odbc32.dll to make sure that it is not corrupted?
3. When does your application crash? Is there a particular php script that causes the issue? If this a PDO_SQLSRV bug, I will need a repro script to investigate it.

[dga26]

Hi @ulvii

I try with pdo_mysql on MySQL database and no issue.

Have you any link to up odbc32.dll? I search on many ms website but the only package I found was mdac2.8 not ready for win server 2012 r2...

Sure for the last point I agree with you but at this time I am not able to give you a script because it appears when I m clicking along our website randomly but always before a web redirect with header location

[dga26]

I suppose it's related to the end of php script.

The things I tried is to make pure exit after sending headers
When I exit the script it crashed randomly.
When I make a database query after sending headers but before script exit, I never had this issue

A very strange behavior

[ulvii]

@dga26 ,

odbc32.dll is an OS component on newer versions of Windows so there is no separate download for it. If it is damaged, you will need to restore it from backup or the distribution disk.

Please let me know, when you are able to provide a repro script.

[dga26]

@ulvii thanks

i try with another dll without success.

A new step i try is about pdo_sqlsrv log severity (-1)
When i reproduce my issue the last log is 1:
[15-Jun-2017 13:01:04 Europe/Paris] pdo_sqlsrv: entering rshutdown
[15-Jun-2017 13:01:04 Europe/Paris] pdo_sqlsrv_dbh_close: entering
[15-Jun-2017 13:01:04 Europe/Paris] pdo_sqlsrv_stmt_dtor: entering

when no issue the last lines are inverted
[15-Jun-2017 13:01:04 Europe/Paris] pdo_sqlsrv: entering rshutdown
[15-Jun-2017 13:01:04 Europe/Paris] pdo_sqlsrv_stmt_dtor: entering
[15-Jun-2017 13:01:04 Europe/Paris] pdo_sqlsrv_dbh_close: entering

..;any idea?

[dga26]

Hi @ulvii

news from windbg debug ...

the final issue is always the same inside windows log events. more information for you with windbg !analyse step as follow

Microsoft (R) Windows Debugger Version 6.3.9600.17298 X86
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\ProgramData\Microsoft\Windows\WER\ReportQueue\AppCrash_php-cgi.exe_3e1e5b3cc8993ef1d2fef1733d7c39ddd12296b_1518642f_cab_06a153eb\memory.hdmp]
User Mini Dump File: Only registers, stack and portions of memory are available


************* Symbol Path validation summary **************
Response                         Time (ms)     Location
Deferred                                       SRV*c:\Symbols*http://msdl.microsoft.com/download/symbols
Symbol search path is: SRV*c:\Symbols*http://msdl.microsoft.com/download/symbols
Executable search path is: 
Windows 8 Version 9600 MP (4 procs) Free x86 compatible
Product: Server, suite: TerminalServer SingleUserTS
Built by: 6.3.9600.18217 (winblue_ltsb.160124-0053)
Machine Name:
Debug session time: Wed Jun 21 16:26:44.000 2017 (UTC + 2:00)
System Uptime: 0 days 7:00:54.187
Process Uptime: 0 days 0:07:55.000
................................................................
....................................
Loading unloaded module list
..
This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
(65c.878): Access violation - code c0000005 (first/second chance not available)
eax=00000000 ebx=00000000 ecx=32a26c98 edx=00000001 esi=00000003 edi=00000003
eip=77dbc8ac esp=06aae134 ebp=06aae2bc iopl=0         nv up ei pl nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000202
ntdll!NtWaitForMultipleObjects+0xc:
77dbc8ac c21400          ret     14h
0:000> !analyze -v
*******************************************************************************
*                                                                             *
*                        Exception Analysis                                   *
*                                                                             *
*******************************************************************************

*** ERROR: Symbol file could not be found.  Defaulted to export symbols for php_pdo_sqlsrv.dll - 
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for php7.dll - 
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for php-cgi.exe - 
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for msodbcsql13.dll - 

FAULTING_IP: 
odbc32!FreeStmt+2e
6ff928ee 833e03          cmp     dword ptr [esi],3

EXCEPTION_RECORD:  ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 6ff928ee (odbc32!FreeStmt+0x0000002e)
   ExceptionCode: c0000005 (Access violation)
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 00000000
   Parameter[1]: 32a26c98
Attempt to read from address 32a26c98

CONTEXT:  00000000 -- (.cxr 0x0;r)
eax=00000000 ebx=00000000 ecx=32a26c98 edx=00000001 esi=00000003 edi=00000003
eip=77dbc8ac esp=06aae134 ebp=06aae2bc iopl=0         nv up ei pl nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000202
ntdll!NtWaitForMultipleObjects+0xc:
77dbc8ac c21400          ret     14h

DEFAULT_BUCKET_ID:  INVALID_POINTER_READ

PROCESS_NAME:  php-cgi.exe

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.

EXCEPTION_PARAMETER1:  00000000

EXCEPTION_PARAMETER2:  32a26c98

READ_ADDRESS:  32a26c98 

FOLLOWUP_IP: 
odbc32!FreeStmt+2e
6ff928ee 833e03          cmp     dword ptr [esi],3

NTGLOBALFLAG:  2000000

APPLICATION_VERIFIER_FLAGS:  0

APP:  php-cgi.exe

ANALYSIS_VERSION: 6.3.9600.17336 (debuggers(dbg).150226-1500) x86fre

FAULTING_THREAD:  00000878

PRIMARY_PROBLEM_CLASS:  INVALID_POINTER_READ

BUGCHECK_STR:  APPLICATION_FAULT_INVALID_POINTER_READ

LAST_CONTROL_TRANSFER:  from 6ffc5eae to 6ff928ee

STACK_TEXT:  
06aaee1c 6ffc5eae 000003ee 1eb31a00 70049e90 odbc32!FreeStmt+0x2e
06aaee64 7004cc1e 00000003 32a26c98 aa4eb313 odbc32!SQLFreeHandle+0x77
WARNING: Stack unwind information not available. Following frames may be wrong.
06aaee94 700562bf aa4eb337 1eb31a00 06aaf840 php_pdo_sqlsrv+0xcc1e
06aaeeb0 70054ab8 70054ab0 70056870 00000000 php_pdo_sqlsrv!get_module+0x11ef
06aaef20 70a6bcea 06aaf840 00000000 56433230 php_pdo_sqlsrv+0x14ab8
06aaef58 707a0e98 00000002 32a3ccc0 00000132 php7!zend_objects_store_del+0xea
06aaef6c 70041ab1 aa4eb213 31f6c800 31ed5ad0 php7!efree+0x78
06aaef80 707a0e98 06aaf840 31ec3a80 aaa5e491 php_pdo_sqlsrv+0x1ab1
06aaef94 70a7cc79 1eb319b8 31f6c800 31f6cc88 php7!efree+0x78
06aaefcc 70b4eb17 0c2531f0 70b4ead0 31f6c800 php7!libiconv_set_relocation_prefix+0x239
06aaefdc 70a9bd89 31f6c800 00000e88 0000009b php7!zend_object_std_dtor+0x47
06aaeff8 707aa781 70e2e244 00000001 00000000 php7!libiconv_set_relocation_prefix+0x1f349
06aaf00c 77687719 06aaf784 06aaf784 06aaf784 php7!zend_ptr_stack_apply+0x2b1
06aaf03c 77e62965 0a650738 0a696eec 77e625e2 KERNELBASE!DeleteTimerQueueTimer+0x22
06aaf068 70f2693a 06aaf090 00000000 00000e88 ntdll!RtlpStdLockRelease+0x14
06aaf0a8 70f277be 06aaf090 00000000 00000e88 verifier!AVrfpDphPostProcessing+0x1a
77e622f0 2118a1ec c08577e8 75ff0974 19e85008 verifier!AVrfpDphFindBusyMemoryAndRemoveFromBusyList+0xbe
77e622fc 19e85008 5d000002 900004c2 90909090 0x2118a1ec
77e62300 5d000002 900004c2 90909090 8b55ff8b 0x19e85008
77e62304 900004c2 90909090 8b55ff8b 18a151ec 0x5d000002
77e62308 90909090 8b55ff8b 18a151ec 8577e821 0x900004c2
77e6230c 8b55ff8b 18a151ec 8577e821 ff0974c0 0x90909090
77e62310 18a151ec 8577e821 ff0974c0 e8500875 0x8b55ff8b
77e62314 8577e821 ff0974c0 e8500875 00000248 0x18a151ec
77e62318 ff0974c0 e8500875 00000248 04c25d59 0x8577e821
77e6231c e8500875 00000248 04c25d59 90909000 0xff0974c0
77e62320 00000000 04c25d59 90909000 90909090 0xe8500875


STACK_COMMAND:  ~0s; .ecxr ; kb

SYMBOL_STACK_INDEX:  0

SYMBOL_NAME:  odbc32!FreeStmt+2e

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: odbc32

IMAGE_NAME:  odbc32.dll

DEBUG_FLR_IMAGE_TIMESTAMP:  545046b6

FAILURE_BUCKET_ID:  INVALID_POINTER_READ_c0000005_odbc32.dll!FreeStmt

BUCKET_ID:  APPLICATION_FAULT_INVALID_POINTER_READ_odbc32!FreeStmt+2e

ANALYSIS_SOURCE:  UM

FAILURE_ID_HASH_STRING:  um:invalid_pointer_read_c0000005_odbc32.dll!freestmt

FAILURE_ID_HASH:  {b97a4ff8-9008-6025-c994-1b05df6cf082}

Followup: MachineOwner
---------

[dga26]

hi @ulvii

For information
i try today with latest 4.3.0 rc1..same issue

[ulvii]

Hi @dga26 ,

Your application is trying to free a statement that has already been freed. The debug information that you have posted is from Driver Manager, which does not really help me to identify where the issue is happening. I am assuming you downloaded the latest dlls from PECL. You will also find .pdb files inside that package. Please load them with WinDbg and check if you get any SQLSRV related output.

[dga26]

Hi @ulvii

about "php_pdo_sqlsrv!std::`dynamic atexit destructor for '_Fac_tidy_reg''+0xa222"

FAULTING_IP: 
odbc32!FreeStmt+2e
6fbb28ee 833e03          cmp     dword ptr [esi],3

EXCEPTION_RECORD:  ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 6fbb28ee (odbc32!FreeStmt+0x0000002e)
   ExceptionCode: c0000005 (Access violation)
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 00000000
   Parameter[1]: 32a32c98
Attempt to read from address 32a32c98

CONTEXT:  00000000 -- (.cxr 0x0;r)
eax=00000000 ebx=00000000 ecx=32a32c98 edx=00000001 esi=00000003 edi=00000003
eip=77dac8ac esp=069ee134 ebp=069ee2bc iopl=0         nv up ei pl nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000202
ntdll!NtWaitForMultipleObjects+0xc:
77dac8ac c21400          ret     14h

DEFAULT_BUCKET_ID:  INVALID_POINTER_READ

PROCESS_NAME:  php-cgi.exe

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.

EXCEPTION_PARAMETER1:  00000000

EXCEPTION_PARAMETER2:  32a32c98

READ_ADDRESS:  32a32c98 

FOLLOWUP_IP: 
odbc32!FreeStmt+2e
6fbb28ee 833e03          cmp     dword ptr [esi],3

NTGLOBALFLAG:  2000000

APPLICATION_VERIFIER_FLAGS:  0

APP:  php-cgi.exe

ANALYSIS_VERSION: 6.3.9600.17336 (debuggers(dbg).150226-1500) x86fre

FAULTING_THREAD:  00000c20

PRIMARY_PROBLEM_CLASS:  INVALID_POINTER_READ

BUGCHECK_STR:  APPLICATION_FAULT_INVALID_POINTER_READ

LAST_CONTROL_TRANSFER:  from 6fbe5eae to 6fbb28ee

STACK_TEXT:  
069eee20 6fbe5eae 000003ee 338af200 700c0e20 odbc32!FreeStmt+0x2e
069eee68 6fc777e0 00000003 32a32c98 fe49ddf0 odbc32!SQLFreeHandle+0x77
069eee94 6fc85162 fe49dda4 33827280 338af200 php_pdo_sqlsrv!pdo_sqlsrv_stmt_set_attr+0xb0
069eeec0 6fc832a8 338af200 6fc85714 00000000 php_pdo_sqlsrv!std::`dynamic atexit destructor for '_Fac_tidy_reg''+0xa222
069eef28 7038bcea 069ef844 00000000 56433230 php_pdo_sqlsrv!std::`dynamic atexit destructor for '_Fac_tidy_reg''+0x8368
WARNING: Stack unwind information not available. Following frames may be wrong.
069eef5c 700c0e98 fe440e35 069eef98 00000132 php7!zend_objects_store_del+0xea
00000000 00000000 00000000 00000000 00000000 php7!efree+0x78


STACK_COMMAND:  ~0s; .ecxr ; kb

SYMBOL_STACK_INDEX:  0

SYMBOL_NAME:  odbc32!FreeStmt+2e

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: odbc32

IMAGE_NAME:  odbc32.dll

DEBUG_FLR_IMAGE_TIMESTAMP:  545046b6

FAILURE_BUCKET_ID:  INVALID_POINTER_READ_c0000005_odbc32.dll!FreeStmt

BUCKET_ID:  APPLICATION_FAULT_INVALID_POINTER_READ_odbc32!FreeStmt+2e

ANALYSIS_SOURCE:  UM

FAILURE_ID_HASH_STRING:  um:invalid_pointer_read_c0000005_odbc32.dll!freestmt

FAILURE_ID_HASH:  {b97a4ff8-9008-6025-c994-1b05df6cf082}

Followup: MachineOwner

[Hadis-Knj]

@dga26 This issue could be a potential bug, and we are interested to look closely into it. To be able to proceed with investigation on this issue we need php repo script in the format of <?php your repo script ?>, would you please send us the repo script?

[dga26]

hi @Hadis-Fard, @ulvii

We are in our application using adodb (lens) to interface app and database plugged with pdo_sqlsrv driver.
I remove all __destruct job and register_shutdown_function without success.

I cannot send you the whole application but i'll try to minimize the code to reproduce a very special case...only reproducible by the interface with the same scheme

Thanks for your answers

[dga26]

hi @Hadis-Fard, @ulvii

2 new business cases on same windows event root error, sure nobody post another similar issue ?

The problem seems to appear since a long date but we never see that before.

Faulting application name: php-cgi.exe, version: 7.0.19.0, time stamp: xx
Faulting module name: ODBC32.dll, version: 6.3.9600.17415, time stamp: xx
Exception code: 0xc0000005
Fault offset: 0x000028ee

Regards

[dga26]

hi @Hadis-Fard, @ulvii

We are forced to downgrade php version to 5.6, this problem made us too much trouble and takes to much time to investigate.

We also view and find bugs over php 7.0.20 so don't want to take much risks

I'll tried to investigate more soon on virtual machine, if you have any information don't hesitate;)

Regards

[psuplat]

Same here.

Brand new Server2012R2 with php7.1

Faulting application name: php-cgi.exe, version: 7.1.1.0, time stamp: 0x587fb655
Faulting module name: ODBC32.dll, version: 6.3.9600.17415, time stamp: 0x5450504d
Exception code: 0xc0000005
Fault offset: 0x00000000000034e1
Faulting process id: 0x1848
Faulting application start time: 0x01d2f4e1fd5ddfe4
Faulting application path: C:\Program Files\PHP\v7.1\php-cgi.exe
Faulting module path: C:\Windows\SYSTEM32\ODBC32.dll
Report Id: 3b6b879a-60d5-11e7-80c8-005056b53611
Faulting package full name: 
Faulting package-relative application ID: 

Same as above I had to downgrade to v 5.6 to make the pages work.

[dga26]

hi @Hadis-Fard, @ulvii

Any idea about this issue since your last post ?
We are very surprised that nobody was impacted by this issue.

Thanks @psuplat for the feedback, we hope others can bring any other information.

I have made all the test i am able to do, i can't waist more time debugging to help you.

Regards

[Hadis-Knj]

@dga26 @psuplat We cannot reproduce this issue in our test lab. From the logs posted it seems the issue happens in Free statement, and to reproduce the issue we need to know the queries your are executing, the APIs used to execute the queries and the order of them. It would be great if you could give us a minimized PHP repo script, so we can proceed with the investigation on this issue.

[dga26]

@Hadis-Fard

i'll try to compute a windows vm with minimal stack for you but i'm not sure to reproduce with only few php (i've tried before)

thanks for reply

[dga26]

Hi
i have no time to reproduce more but i try the new release and pre-release on the same env and the issue is already here

Nobody send you any feedback about that ?
It's a big big problem for us we were forced to downgrade our app on php 5.6 to work well

Regards

[dga26]

Hi

Another user with the same issue..we are very embarassed with this problem...on a recent PHP release 7.1.7 and apache

https://bugs.php.net/bug.php?id=74710&edit=2

Regards

[david-puglielli]

I must reiterate that this is extremely difficult to investigate without a repro script, and we have never seen it in our test lab. If @dga26 cannot provide one, perhaps @psuplat can? Anything at all that can produce this error, no matter how simple or complicated, will help us track down the problem.

[dga26]

Hi

good news !

after many tries .. we succeed to reproduce with very simple code (not good code sure but 100% efficient ;) )

Fails

When

<?php
$user = 'xx';
$password = 'xx';
$myDb = new PDO('sqlsrv:server=xxx;database=xxx;', $user, $password);
$myDb->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
if ($myDb->beginTransaction()) {
    $myDb->query('SELECT CURDATE');
}
?>

Then

Faulting application name: php-cgi.exe, version: 7.0.20.0, time stamp: 0x5937200f
Faulting module name: ODBC32.dll, version: 6.3.9600.17415, time stamp: 0x545046b6
Exception code: 0xc0000005
Fault offset: 0x000028ee
Faulting process id: 0x1e28
Faulting application start time: 0x01d33b5aea70a424
Faulting application path: C:\PHP\php-cgi.exe
Faulting module path: C:\Windows\SYSTEM32\ODBC32.dll
Report Id: 285666f7-a74e-11e7-80ca-0050568c6901
Faulting package full name: 
Faulting package-relative application ID: 

Succeed with normal exception:

When :

<?php
$user = 'xx';
$password = 'xx';
$myDb = new PDO('sqlsrv:server=xxx;database=xxx;', $user, $password);
$myDb->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
if ($myDb->beginTransaction()) {
    $myDb->exec('SELECT CURDATE');
}
?>

Then

Uncaught PDOException: SQLSTATE[42S22]: [Microsoft][ODBC Driver 13 for SQL Server][SQL Server]Invalid column name 'CURDATE

Succeed too with

<?php

$user = 'xx';
$password = 'xx';
$myDb = new PDO('sqlsrv:server=xx;database=xx;', $user, $password);
$myDb->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
if ($myDb->beginTransaction()) {
	$stmt = $myDb->prepare('SELECT CURDATE');
        $stmt->execute();
}
?>

Regards

Sure i'm not using transaction as normal case but the error doesn't raise correctly

[dga26]

@david-puglielli
for more information about my debug, when i switch between pdo_sqlsrv for php 5.6 i have the good exception message using Pdo::query.
switching again on php 7, then odbc32.dll error

When i remove Pdo::beginTransaction query the exception is well-raised in both cases

Regards

[ezison]

Hello.

I have the same problem.

It may not be a fundamental solution, but isn't it settled by turning off use in a connection pool?

(example)

<?php
$user = 'xx';
$password = 'xx';
$myDb = new PDO('sqlsrv:ConnectionPooling=0; server=xxx;database=xxx;', $user, $password);
$myDb->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
if ($myDb->beginTransaction()) {
    $myDb->query('SELECT CURDATE');
}
?>

I haven't tried this yet.

Thanks.

[seanvree]

same issue here:

Faulting application name: php-cgi.exe, version: 7.1.7.0, time stamp: 0x595e6ac5
Faulting module name: KERNELBASE.dll, version: 10.0.15063.608, time stamp: 0x943cbf8b
Exception code: 0xc0000005
Fault offset: 0x0000000000069e08
Faulting process id: 0x739c
Faulting application start time: 0x01d3413b346f49c0
Faulting application path: C:\Program Files\PHP\v7.1\php-cgi.exe
Faulting module path: C:\WINDOWS\System32\KERNELBASE.dll
Report Id: 2c8a1298-9a12-41ba-a11a-c2b7640c7aef
Faulting package full name: 
Faulting package-relative application ID: 

[dga26]

Hi @david-puglielli or @ulvii

Any news about this issue ? I see many guys are waking up around my initial post ;)

To help during your tests i notice that the issue raised everytime on win server 2012 r2
Everytime i tried on local win 10 minimal stack (apache 2.4 or iis) php 7.0.x i have to make a loop over 1000 iterations to reproduce.

Regards

[yitam]

Thank you @bstoney for the clear steps. We will investigate and get back to you.

[yitam]

Hi @bstoney

Assuming IIS is used, I'm unable to reproduce the issue using zendframework/zend-db or PDO directly. Tested in Win 10, Win Server 2016 and Win Server 2012 R2, with PHP 7.2.7 instead of PHP 7.2.8 (I doubt this will make a difference).

Please see the screenshot attached. For Composer, I do not use developer mode nor proxy.

[bstoney]

Sorry, I should have mentioned that I did not see this issue when using php_cgi and IIS, though I cannot be sure it doesn't. Hopefully if you run the test above using the command line .\vendor\bin\phpunit Tests\Test.php you will see the error. It looks to me like the error only happens as the php process exits, which might explain why it is not seen with IIS. I have retested with php 7.2.7, just in case, and still get the error.

[yitam]

Hi @bstoney , so run the php script using phpunit in command line? How did you install PHP 7.2? Downloaded the zip file or built it from source? If the latter case, did you build in debug mode?

[yitam]

Yes @bstoney I can reproduce the issue with phpunit in command line with PHP 7.2.7 in Windows 10 (I haven't yet tried the other Windows platforms). Will do some investigation and get back to you.

[bstoney]

@yitam PHP 7.2 was installed from the downloaded zip file. I have reproduced it in PHP 7.2.7 and 7.2.8 on Windows Server 2012 R2 and Windows Server 2016. I have found that explicitly setting any references to a PDOStatement object to null before php exits avoids the error. At least for the case I have found :)

[yitam]

Thanks @bstoney
I also noted that it won't crash if I made the following changes:

        // 1. if $select is unset after this or the variable has a diff name here
        $select = new \Zend\Db\Sql\Select();

        $sql = new Sql($this->adapter);
        // 2. if the following line is replaced by the next two commented lines
        $select = $sql->select()->from('sysobjects');
        // $select = $sql->select();
        // $select->from('sysobjects');

Just wondering, this line is not really necessary, is it?
$select = new \Zend\Db\Sql\Select();

Anyway, any other info you can provide will help. Thank you!

[bstoney]

That is correct, $select = new \Zend\Db\Sql\Select(); is not needed I just found that it caused the error to occur.

I am beginning to think that this error might be caused by some underlying variable reference tracking or garbage tracking issue in PHP 7.2. Your tests would hint that this is the case, particularly as you say it does not happen if the variable is unset. However I don't really have enough expertise in how PHP manages references to be sure.

[yitam]

Hi @bstoney I could finally track exactly why it crashed -- freeing a SQLHANDLE when it had already been freed earlier. However, the cause(s) remain unclear to me, and my suspicions are similar to what you said. Thanks for your input. Please stay tuned.

[yitam]

Hello @bstoney

I have tested the fix with both 64bit and 32bit of PHP 7.2 and verified that the problem no longer occurs.

Also tested with PHP 7.1, even though the problem only happens with PHP 7.2.

The fix will be available in the next preview release. Thank you for your inputs.

[bstoney]

Thanks heaps @yitam, I will verify the fix as soon as the next preview is available. I really appreciate your efforts.

[dga26]

Hi @yitam,

Thanks for your reply and @bstoney to.
We try with release 5.3 to, issue is again rising.

I try to rollback odbc driver to older (11 2011.xxx.xx) version because no problem comes on development environment with this one ... without success on production in our customer server.

We tried to identify any differences between material and system configuration.

Finally we are updating our sources to match php 7.2 version and update pdo_sqlsrv, seeing @bstoney post we are a bit afraid by issue is still happening.

Be sure we make effort to send you any input or reproduce script to investigate.

Regards

[yitam]

Thanks @dga26. Please let us know how often you encounter this issue, and yes, if you have any input or script to help us investigate that will be great.

[dga26]

Hi @yitam,

Good news from us !
Yesterday using opcache.fast_shutdown = 0 instead of 1 the issue disappear..

Win server 2012
Php version 7.0.30
Pdo_sqlsrv 5.3

Regards

Full php.ini conf

Bad
[opcache]
opcache.enable=1
opcache.memory_consumption=128
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=4000
opcache.revalidate_freq=60
opcache.fast_shutdown=1
opcache.enable_cli=1

Good
[opcache]
opcache.enable=1
opcache.memory_consumption=128
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=4000
opcache.revalidate_freq=60
opcache.fast_shutdown=0
opcache.enable_cli=1

[yitam]

Interesting! Thanks @dga26 for the new info. We will keep this issue open regardless for more investigation on our side.

[yitam]

Hi @dga26

Based on the php opcache fast-shutdown reference,

This directive has been removed in PHP 7.2.0. A variant of the fast shutdown sequence has been integrated into PHP and will be automatically used if possible.

However, we did not encounter any crash issues when testing our latest drivers 5.3.0 with PHP 7.2 with simple queries using IIS as the web server.

We repeated the tests against PHP 7.0 and 7.1 by enabling the fast_shutdown flags. No crash either.

If possible, please consider providing your typical queries / scenarios that you experienced crashes before.

[dga26]

hi @yitam ,

same problem today on windows server 2016, php 7.2.9....
so sad..

[yitam]

Thanks @dga26 for getting back to us. We suspect it's a similar issue with the one reported by @bstoney above (also only happened with php 7.2*). We are planning to release a preview with the fix for that, so please stay tuned.

In the meantime, you might want to send us some typical queries that you run on a regular basis. That would help us investigate.

[yitam]

Hi @dga26 and @bstoney , just so you know, 5.4.0-preview is released today. Please let us know when you have a chance to verify the fix.

[bstoney]

Thanks @yitam , my tests are all passing with 5.4.0-preview. 👍

[dga26]

Thanks @bstoney and @yitam

We'll try to launch our test suite and manual check asap.

Regards

[aramis74]

Thanks @yitam , we had the same problems (with php 7.2.9 and sqlsrv 5,3,0). With 5.4.0-preview our tests are all passing.

[yitam]

Wonderful news, @bstoney and @aramis74 ! Thanks for letting us know. :)
@dga26 please keep us posted.

[dga26]

Hi @yitam ,

Seems to be good for us after few install. Thanks a lot for your job @david-puglielli @yitam and others like me.
Do you planned any release for that because front of customer, tag preview is not symbol to quality :(

Regards

[yitam]

Thanks for the good news @dga26 ! Our plan is to continue working on some feature requests and adding new features for the production release. We can't promise you a date yet but please stay tuned.

I'll close this issue, and please feel free to reopen if the same problem resurfaces.