Bug #69820 [Ver]: CLI crashes at start with various extensions enabled

Edit report at https://bugs.php.net/bug.php?id=69820&edit=1 ID: 69820 Updated by: ab@php.net Reported by: maikgreubel at gmail dot com Summary: CLI crashes at start with various extensions enabled Status: Verified Type: Bug Package: Reproducible crash Operating System: Windows 7 64bit PHP Version: 7.0.0alpha1 Assigned To: ab Block user comment: N Private report: N New Comment: @maikgreubel, or alternatively - just check this snapshot http://windows.php.net/downloads/snaps/ostc/69814/ (built from the latest master). Thanks. Previous Comments: ------------------------------------------------------------------------ [2015-06-14 10:31:03] maikgreubel at gmail dot com Going back to qa-build binary and debugging. + &p->val 0x000000000417bf80 {value={lval=112 dval=5.533535233422e-322#DEN counted=0x0000000000000070 {refcount=...} ...} ...} _zval_struct * apply_func 0x000007fede71c480 {php7ts.dll!zend_startup_module_zval(_zval_struct *)} int (_zval_struct *) * + ht 0x000007fedeecdb00 {php7ts.dll!_zend_array module_registry} {gc={refcount=1 u={v={type=7 '\a' flags=...} ...} } ...} _zend_array * + ht->arData 0x00000000060a2800 {val={value={lval=68645888 dval=3.391557498907e-316#DEN counted=0x0000000004177400 {...} ...} ...} ...} _Bucket * ht->nNumUsed 33 unsigned int idx 8 unsigned int + p 0x000000000417bf80 {val={value={lval=112 dval=5.533535233422e-322#DEN counted=0x0000000000000070 {refcount=...} ...} ...} ...} _Bucket * + p->val {value={lval=112 dval=5.533535233422e-322#DEN counted=0x0000000000000070 {refcount=??? u={v={type=??? ...} ...} } ...} ...} _zval_struct result 0 int Due to optimization I can not add conditional breakpoint at for-loop iteration of HashTable in zend_hash_apply to find out, which module entry causes the problem. I try to investigate the scope where the module_registry HashTable is filled with entries and what happens between initialization of HT and the module activation. ------------------------------------------------------------------------ [2015-06-14 10:25:40] ab@php.net @maikgreubel, yeah, see bug #69823. My insight about ext/hash was correct. I think we're done here. Please fetch the latest master to check this. Thanks. ------------------------------------------------------------------------ [2015-06-14 10:01:32] ab@php.net Thanks for the followup. Yeah, --enable-pgi is a part of the PGO build scenario, not needed if you don't do it. But something strange happens. Yesterday I was able to reproduce your initial report using x64\Release_TS\php.exe -n -d extension_dir=x64\Release_TS -d extension=php_fileinfo.dll -d extension=php_mbstring.dll -d extension=php_pdo_mysql.dll -d extension=php_pdo_sqlite.dll But this doesn't crash when I've fetched and rebuilt today. Not doing PGO build as well. But that's why i guess it's not an optimization issue, still quite strange. Maybe you can repro it with this configure line? cscript /nologo configure.js "--enable-snapshot-build" "--enable-debug-pack" "--enable-com-dotnet=shared" That picks up literally everything. But of course, maybe that's just PGO, so probably were worth to check it (but need setup for scenarios). Also, it might be a vc14 issue as it's still RC. Whereby I seem have not received any vc14 updates over the night. Thanks. ------------------------------------------------------------------------ [2015-06-14 08:27:03] maikgreubel at gmail dot com I added the deps from deps-7.0-vc14-x64.7z and compiled with the same options than qa build. The result is not runnable due to missing pgort140.dll. So I disabled --enable-pgi and got no crash with the same extensions enabled in php.ini. I also enabled more extensions: extension=php_fileinfo.dll extension=php_mbstring.dll extension=php_mysqli.dll extension=php_pdo_mysql.dll extension=php_pdo_sqlite.dll extension=php_shmop.dll extension=php_sockets.dll And still no crash. Optimizitation issue? ------------------------------------------------------------------------ [2015-06-13 22:29:03] ab@php.net Ok, this is ... interesting. But seems you don't use the deps package vor vc14 (available at windows.php.net/downloads). I use them, and the behavior i've described depends on ext/hash. But this could mean to me - we have something terrible in the dependency libraries, and that screws the memory at some point. Can you tell the same after you've fetched the vc14 deps and they're available for your build? Btw, do you have the same crash when enabling all the available exts? Thanks. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=69820 -- Edit this bug report at https://bugs.php.net/bug.php?id=69820&edit=1