Bug #69411 [Com]: Segmentation fault in _pcre_jit_compile
| From: | berdir@php.net | 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