Bug #77922 [Com]: Segmentation fault in PHP 7.3.4 when running phpunit

From: Date: Tue, 30 Jul 2019 23:27:13 +0000
Subject: Bug #77922 [Com]: Segmentation fault in PHP 7.3.4 when running phpunit
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-222020@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=77922&edit=1

 ID:                 77922
 Comment by:         andrew at nicols dot co dot uk
 Reported by:        enumag at gmail dot com
 Summary:            Segmentation fault in PHP 7.3.4 when running phpunit
 Status:             Open
 Type:               Bug
 Package:            Unknown/Other Function
 Operating System:   Ubuntu
 PHP Version:        7.3.4
 Block user comment: N
 Private report:     N

 New Comment:

We are still seeing this in a repeatable fashion on PHP 7.3.7, only it has now progressed from
hitting just SQLServer to MySQLi too.

Have a coredump, and will generate valgrind if it's useful.
As others have said, only happens on a full run.
Moodle (same as stronk7)


Previous Comments:
------------------------------------------------------------------------
[2019-06-03 14:29:52] stronk7 at moodle dot com

Just for the records, we are also facing a similar problem with PHP 7.3 and our phpunit tests.The
very same stuff passes without problems with 7.1 and 7.2.

Have been able to consistently reproduce the problem both with debian9 (dockerized) and macos x
mojave.

...........................................................  7906 / 13354 ( 59%)
...Segmentation fault: 11 (`core' generado)

In our case, it's curious because the problem is only reproducible when we are using the sqlsrv
extension (tests are passing perfectly with any other db), but this maybe a factor, not the cause,
as far as our backtrace is pretty similar the originally reported here (mac one follows):

(lldb) bt all
* thread #1, stop reason = signal SIGSTOP
  * frame #0: 0x0000000109da5ade php`zend_mm_alloc_small + 206
    frame #1: 0x0000000109da304d php`zend_mm_alloc_heap + 301
    frame #2: 0x0000000109da3fe6 php`_emalloc + 182
    frame #3: 0x0000000109d9481c php`zend_string_alloc + 124
    frame #4: 0x0000000109d7fecf php`zend_string_init + 31
    frame #5: 0x0000000109d82488 php`lex_scan + 3000
    frame #6: 0x0000000109dab4c4 php`zendlex + 68
    frame #7: 0x0000000109d787ee php`zendparse + 878
    frame #8: 0x0000000109d8090c php`zend_compile + 92
    frame #9: 0x0000000109d80882 php`compile_file + 146
    frame #10: 0x0000000109ad1fa4 php`phar_compile_file + 1204
    frame #11: 0x0000000109d80b6a php`compile_filename + 218
    frame #12: 0x0000000109ee7484 php`zend_include_or_eval + 884
    frame #13: 0x0000000109e80a6f php`ZEND_INCLUDE_OR_EVAL_SPEC_TMPVAR_HANDLER + 63
    frame #14: 0x0000000109e54434 php`execute_ex + 100
    frame #15: 0x0000000109dc956a php`zend_call_function + 2826
    frame #16: 0x0000000109e435d7 php`zend_std_call_getter + 247
    frame #17: 0x0000000109e42cb6 php`zend_std_read_property + 1350
    frame #18: 0x0000000109e89268 php`ZEND_FETCH_OBJ_R_SPEC_CV_CONST_HANDLER + 1928
    frame #19: 0x0000000109e54434 php`execute_ex + 100
    frame #20: 0x0000000109e5463a php`zend_execute + 234
    frame #21: 0x0000000109de6fa2 php`zend_execute_scripts + 594
    frame #22: 0x0000000109d39103 php`php_execute_script + 1139
    frame #23: 0x0000000109ef5440 php`do_cli + 3440
    frame #24: 0x0000000109ef4401 php`main + 1633
    frame #25: 0x00007fff785543d5 libdyld.dylib`start + 1
    frame #26: 0x00007fff785543d5 libdyld.dylib`start + 1

Also, like the original reporter... the fault only happens when we run all the tests, running only
the "breaking" one doesn't break. And taking rid of the "breaking" one
makes the whole run to pass.

So, we know it only happens for us with sqlsrv, we know which exact test case causes it (pretty
innocent one, I'd say) and it's only reproducible running all tests.

Not sure if all the above helps, but that's what we have been able to find till now, so far.

Ciao :-)

------------------------------------------------------------------------
[2019-05-21 10:09:02] wskorodecki at gmail dot com

I'm facing the same problem on PHP 7.3.5 on Archlinux but my stacktrace is different.
Interesting here is that the error does not occur when I execute "phpunit -v" outside our
Symfony-based project, that has a "tests" directory containing several tests based on
PHPUnit.

$ php -v
PHP 7.3.5 (cli) (built: Apr 30 2019 21:05:09) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.5, Copyright (c) 1998-2018 Zend Technologies
    with Zend OPcache v7.3.5, Copyright (c) 1999-2018, by Zend Technologies

$ phpunit --version
PHPUnit 8.0.1 by Sebastian Bergmann and contributors.

$ php -m
[PHP Modules]
Core
ctype
curl
date
dom
ds
fileinfo
filter
ftp
gd
hash
iconv
igbinary
intl
json
libxml
mbstring
mysqlnd
odbc
openssl
pcntl
pcre
PDO
pdo_mysql
pdo_sqlite
Phar
posix
readline
redis
Reflection
session
SimpleXML
soap
SPL
standard
tokenizer
xml
xmlreader
xmlwriter
Zend OPcache
zip
zlib

[Zend Modules]
Zend OPcache

$ phpunit -v
Segmentation fault (core dumped)

$ coredumpctl info 20528
           PID: 20528 (php)
           UID: 1000 (wojtek)
           GID: 985 (users)
        Signal: 11 (SEGV)
     Timestamp: Tue 2019-05-21 08:26:09 CEST (42s ago)
  Command Line: php /usr/local/bin/phpunit -v
    Executable: /usr/bin/php
 Control Group: /user.slice/user-1000.slice/session-2.scope
          Unit: session-2.scope
         Slice: user-1000.slice
       Session: 2
     Owner UID: 1000 (wojtek)
       Boot ID: 526298d71d1a4cb6bf2294d12eea5611
    Machine ID: f372dea6fef44dc1ad344b6b92e63878
      Hostname: archlinux-ws
       Storage:
/var/lib/systemd/coredump/core.php.1000.526298d71d1a4cb6bf2294d12eea5611.20528.1558419969000000.lz4
       Message: Process 20528 (php) of user 1000 dumped core.
                
                Stack trace of thread 20528:
                #0  0x000055e6a0409bd0 n/a (php)
                #1  0x000055e6a05857c5 execute_ex (php)
                #2  0x000055e6a058b836 zend_execute (php)
                #3  0x000055e6a050455a zend_execute_scripts (php)
                #4  0x000055e6a04a4489 php_execute_script (php)
                #5  0x000055e6a058de36 n/a (php)
                #6  0x000055e6a028f067 n/a (php)
                #7  0x00007f51c5576ce3 __libc_start_main (libc.so.6)
                #8  0x000055e6a028f74e _start (php)

------------------------------------------------------------------------
[2019-05-04 09:21:39] enumag at gmail dot com

Note: This bug still exists in PHP 7.3.5.

------------------------------------------------------------------------
[2019-04-24 18:59:02] enumag at gmail dot com

How do we fix it then? Is there anything else I can do to help? This is currently blocking us from
upgrading to PHP 7.3.

------------------------------------------------------------------------
[2019-04-24 13:46:08] nikic@php.net

Thanks! The first non-spurious warning is:


==32207== Invalid read of size 4
==32207==    at 0x3C7A2E: gc_mark_grey (zend_gc.c:901)
==32207==    by 0x3C7A2E: gc_mark_roots (zend_gc.c:960)
==32207==    by 0x3C7A2E: zend_gc_collect_cycles (zend_gc.c:1443)
==32207==    by 0x3C68B7: gc_possible_root_when_full (zend_gc.c:577)
==32207==    by 0x42C233: zend_object_release (zend_objects_API.h:79)
==32207==    by 0x42C233: execute_ex (zend_vm_execute.h:55359)
==32207==    by 0x42FCB2: zend_execute (zend_vm_execute.h:60881)
==32207==    by 0x3A0E21: zend_execute_scripts (zend.c:1568)
==32207==    by 0x340E6F: php_execute_script (main.c:2630)
==32207==    by 0x43218B: do_cli (php_cli.c:997)
==32207==    by 0x1F890A: main (php_cli.c:1389)
==32207==  Address 0x1d757ae4 is 4 bytes inside a block of size 40 free'd
==32207==    at 0x4C30D3B: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==32207==    by 0x3CA5F0: zend_string_release (zend_string.h:277)
==32207==    by 0x3CA5F0: zend_new_interned_string_request (zend_string.c:232)
==32207==    by 0x3827D1: zend_begin_method_decl (zend_compile.c:5817)
==32207==    by 0x38F3B5: zend_compile_func_decl (zend_compile.c:6037)
==32207==    by 0x38D109: zend_compile_stmt (zend_compile.c:8277)
==32207==    by 0x38E326: zend_compile_stmt_list (zend_compile.c:5434)
==32207==    by 0x38CFF1: zend_compile_stmt (zend_compile.c:8221)
==32207==    by 0x38E681: zend_compile_class_decl (zend_compile.c:6491)
==32207==    by 0x38D117: zend_compile_stmt (zend_compile.c:8289)
==32207==    by 0x38FED4: zend_compile_top_stmt (zend_compile.c:8195)
==32207==    by 0x38FEC0: zend_compile_top_stmt (zend_compile.c:8190)
==32207==    by 0x368558: zend_compile (zend_language_scanner.l:602)
==32207==  Block was alloc'd at
==32207==    at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==32207==    by 0x377168: __zend_malloc (zend_alloc.c:2903)
==32207==    by 0x398444: zend_string_alloc (zend_string.h:133)
==32207==    by 0x398444: zend_string_tolower_ex (zend_operators.c:2677)
==32207==    by 0x3827C5: zend_begin_method_decl (zend_compile.c:5816)
==32207==    by 0x38F3B5: zend_compile_func_decl (zend_compile.c:6037)
==32207==    by 0x38D109: zend_compile_stmt (zend_compile.c:8277)
==32207==    by 0x38E326: zend_compile_stmt_list (zend_compile.c:5434)
==32207==    by 0x38CFF1: zend_compile_stmt (zend_compile.c:8221)
==32207==    by 0x38E681: zend_compile_class_decl (zend_compile.c:6491)
==32207==    by 0x38D117: zend_compile_stmt (zend_compile.c:8289)
==32207==    by 0x38FED4: zend_compile_top_stmt (zend_compile.c:8195)
==32207== by 0x38FEC0: zend_compile_top_stmt (zend_compile.c:8190)

The warning indicates a use-after-free of https://github.com/php/php-src/blob/191e15309fce3df7839e52b1f488b0be83fa8561/Zend/zend_compile.c#L5816.
That seems rather unlikely, so it's probably hitting that piece of memory by coincidence :/

------------------------------------------------------------------------


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=77922


--
Edit this bug report at https://bugs.php.net/bug.php?id=77922&edit=1


Thread (16 messages)

« previous php.bugs (#222020) next »