Bug #69411 [Com]: Segmentation fault in _pcre_jit_compile

From: Date: Sat, 11 Apr 2015 07:15:14 +0000
Subject: Bug #69411 [Com]: Segmentation fault in _pcre_jit_compile
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-191957@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=69411&edit=1 ID: 69411 Comment by: berdir@php.net Reported by: berdir@php.net Summary: Segmentation fault in _pcre_jit_compile Status: Assigned Type: Bug Package: PCRE related Operating System: Linux PHP Version: master-Git-2015-04-09 (Git) Assigned To: laruence Block user comment: N Private report: N New Comment: Very strange. MigrateDrupal6Test is a pretty special test, it basically executes a whole bunch of other tests together. So, this should also happen in one of the others. I checked and of all those tests, there is only a single one that does web requests, MigrateUserTest. But that one a) doesn't segfault on it's own and b) does absolutely nothing special. I confirm that the segfault doesn't happen if I comment out the relevant lines: --- a/core/modules/migrate_drupal/src/Tests/d6/MigrateUserTest.php +++ b/core/modules/migrate_drupal/src/Tests/d6/MigrateUserTest.php @@ -180,9 +180,9 @@ public function testUser() { // Use the UI to check if the password has been salted and re-hashed to // conform the Drupal >= 7. $credentials = array('name' => $source->name, 'pass' => $source->pass_plain); - $this->drupalPostForm('user/login', $credentials, t('Log in')); - $this->assertNoRaw(t('Sorry, unrecognized username or password. <a href="@password">Have you forgotten your password?</a>', array('@password' => \Drupal::url('user.pass', [], array('query' => array('name' => $source->name)))))); - $this->drupalLogout(); + //$this->drupalPostForm('user/login', $credentials, t('Log in')); + //$this->assertNoRaw(t('Sorry, unrecognized username or password. <a href="@password">Have you forgotten your password?</a>', array('@password' => \Drupal::url('user.pass', [], array('query' => array('name' => $source->name)))))); + //$this->drupalLogout(); I think I can rewrite that test to not do a form submission, then we can work around the problem, for now. Could this be a problem in curl itself? Previous Comments: ------------------------------------------------------------------------ [2015-04-11 07:04:49] berdir@php.net Hm, now I'm wondering if the backtrace was completely off. I've disabled that and it still segfaulted, but I didn't get an updated core dump, so I might have been looking at the wrong one before. I've started it with gdb now, and here's what I get: Program received signal SIGSEGV, Segmentation fault. __GI___libc_free (mem=0x90) at malloc.c:2929 2929 malloc.c: No such file or directory. (gdb) bt #0 __GI___libc_free (mem=0x90) at malloc.c:2929 #1 0x00007ffff574323c in ?? () from /usr/lib/x86_64-linux-gnu/libcurl.so.4 #2 0x00007ffff5744a78 in ?? () from /usr/lib/x86_64-linux-gnu/libcurl.so.4 #3 0x00007ffff5744bad in ?? () from /usr/lib/x86_64-linux-gnu/libcurl.so.4 #4 0x00007ffff57556fe in ?? () from /usr/lib/x86_64-linux-gnu/libcurl.so.4 #5 0x00007ffff5760d1d in curl_easy_cleanup () from /usr/lib/x86_64-linux-gnu/libcurl.so.4 #6 0x00000000005658d0 in _php_curl_close_ex (ch=0x7fffd8689d40) at /home/berdir/tools/php-src/ext/curl/interface.c:3196 #7 0x00000000007caee9 in zend_resource_dtor (res=res@entry=0x7fffd8c8e330) at /home/berdir/tools/php-src/Zend/zend_list.c:72 #8 0x00000000007caf63 in list_entry_destructor (zv=<optimized out>) at /home/berdir/tools/php-src/Zend/zend_list.c:183 #9 0x00000000007c7bcf in _zend_hash_del_el_ex (prev=<optimized out>, p=<optimized out>, idx=<optimized out>, ht=<optimized out>) at /home/berdir/tools/php-src/Zend/zend_hash.c:899 #10 zend_hash_index_del (ht=0x10acd58 <executor_globals+536>, h=<optimized out>) at /home/berdir/tools/php-src/Zend/zend_hash.c:1100 #11 0x00000000007ee906 in i_zval_ptr_dtor (zval_ptr=<optimized out>) at /home/berdir/tools/php-src/Zend/zend_variables.h:57 #12 zend_object_std_dtor (object=0x7fffd8681000) at /home/berdir/tools/php-src/Zend/zend_objects.c:61 #13 0x00000000007f3d62 in zend_objects_store_del (object=0x7fffd8681000) at /home/berdir/tools/php-src/Zend/zend_objects_API.c:181 #14 0x00000000007b3999 in i_zval_ptr_dtor (zval_ptr=0x0) at /home/berdir/tools/php-src/Zend/zend_variables.h:57 #15 _zval_dtor_func_for_ptr (p=0x90) at /home/berdir/tools/php-src/Zend/zend_variables.c:129 #16 0x00000000007c801b in i_zval_ptr_dtor (zval_ptr=0x7fffd8689fc8) at /home/berdir/tools/php-src/Zend/zend_variables.h:57 #17 zend_array_destroy (ht=0x7fffd866b9d8) at /home/berdir/tools/php-src/Zend/zend_hash.c:1179 #18 0x0000000000565939 in _php_curl_close_ex (ch=0x7fffd8689d40) at /home/berdir/tools/php-src/ext/curl/interface.c:3210 #19 0x00000000007caee9 in zend_resource_dtor (res=0x7fffd8c8e330) at /home/berdir/tools/php-src/Zend/zend_list.c:72 #20 0x00000000007caf33 in zend_close_rsrc (zv=<optimized out>) at /home/berdir/tools/php-src/Zend/zend_list.c:226 #21 0x00000000007c9452 in zend_hash_reverse_apply (ht=0x10acd58 <executor_globals+536>, apply_func=apply_func@entry=0x7caf20 <zend_close_rsrc>) at /home/berdir/tools/php-src/Zend/zend_hash.c:1435 #22 0x00000000007cb4dc in zend_close_rsrc_list (ht=<optimized out>) at /home/berdir/tools/php-src/Zend/zend_list.c:234 #23 0x00000000007a5d83 in shutdown_executor () at /home/berdir/tools/php-src/Zend/zend_execute_API.c:331 #24 0x00000000007b52fb in zend_deactivate () at /home/berdir/tools/php-src/Zend/zend.c:947 #25 0x0000000000757607 in php_request_shutdown (dummy=<optimized out>) at /home/berdir/tools/php-src/main/main.c:1806 #26 0x0000000000850c72 in do_cli (argc=144, argv=0xffffffff) at /home/berdir/tools/php-src/sapi/cli/php_cli.c:1135 #27 0x0000000000436900 in main (argc=144, argv=0xffffffff) at /home/berdir/tools/php-src/sapi/cli/php_cli.c:1334 This makes more sense to me, as I said, it happens after the test was executed successfully. Does this help? Seems to happen quite deep in curl itself... ------------------------------------------------------------------------ [2015-04-11 01:42:01] laruence@php.net what about if you add -d pcre.jit=0 to it? let's make sure it's not a pcre jit issue first.. thanks ------------------------------------------------------------------------ [2015-04-10 21:51:42] berdir@php.net Had a similar segfault, this time inside apache while running a different test, this one doesn't always happen. Test is Drupal\system\Tests\Installer\InstallerTranslationTest. I'm guessing it is related because it also happens inside _pcre_jit_compile() backtrace: https://gist.githubusercontent.com/Berdir/3fdfe825cfdda9e091f1/raw/1f3a0f988c35179a204f5de14d6e05129c437ae7/gistfile1.txt ------------------------------------------------------------------------ [2015-04-10 16:24:35] berdir@php.net Right, what happens if you add --verbose there? It should print out the exact exception that you get then. Might be a missing extension or something like that that prevents it from running the test. Can you run other tests? ------------------------------------------------------------------------ [2015-04-10 15:17:18] laruence@php.net here is what the commmand I run: '/home/huixinchen/local/php-trunk/bin/php' './core/scripts/run-tests.sh' --url 'http://d8/' --sqlite '/tmp/test.sqlite' --dburl 'sqlite://tmp/db.sqlite' --php '/home/huixinchen/local/php-trunk/bin/php' --test-id 1 --color --execute-test 'Drupal\migrate_drupal\Tests\d6\MigrateDrupal6Test' ------------------------------------------------------------------------ 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=69411 -- Edit this bug report at https://bugs.php.net/bug.php?id=69411&edit=1

« previous php.bugs (#191957) next »