See also http://bugs.php.net/bug.php?id=69371 on how to debug our test runner.

what I got is: 

Test summary
------------

Drupal\migrate_drupal\Tests\d6\MigrateDrupal6Test              1 passes             1 exceptions

The segfault only happens at the end of the test for me.

Can you add a --verbose --color to see what exception you get?

Sounds like it's failing on something and never gets far enough. Thanks for looking into this!

I can join an IRC channel, or you can find me in #drupal-contribute to discuss this.

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'

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?

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

what about if you add -d pcre.jit=0 to it?

let's make sure it's not a pcre jit issue first..

thanks

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...

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?

Note that there is an issue with pcre too, just not in this test. InstallerTranslationTest, as commented above does seem to segfault there.

Not sure what I should do now, possibly open two separate issues?

hmm, I was really upset that I can not make the test run as you described...

I am using the drupal 8.0.x branch. the last commit is:

commit b75b691a47eea31515d336065e8a3ec53423e0bd
Author: Alex Pott <alex.a.pott@googlemail.com>
Date:   Thu Apr 9 18:53:33 2015 +0100

    Issue #2463417 by rpayanm, cilefen, hussainweb: Clean-up remaining test members in module tests - ensure property de
finition and use of camelCase naming convention


And here is what I got while running it with --verbose:

$  /home/huixinchen/local/php-trunk/bin/php core/scripts/run-tests.sh --url http://d8/ --color --verbose --sqlite /tmp/test.sqlite --dburl sqlite://tmp/db.sqlite --class "Drupal\migrate_drupal\Tests\d6\MigrateDrupal6Test"

Drupal test run
---------------

Tests to be run:
  - Drupal\migrate_drupal\Tests\d6\MigrateDrupal6Test

Test run started:
  Saturday, April 11, 2015 - 09:52

Test summary
------------

Drupal\migrate_drupal\Tests\d6\MigrateDrupal6Test              1 passes             1 exceptions

Test run duration: 42 sec

Detailed test results
---------------------


---- Drupal\migrate_drupal\Tests\d6\MigrateDrupal6Test ----


Status    Group      Filename          Line Function
--------------------------------------------------------------------------------
Pass      Other      MigrateTestBase.p   52 Drupal\migrate\Tests\MigrateTestBas
    Enabled modules: action, aggregator, block, book, comment, contact,
    block_content, datetime, dblog, entity_reference, file, forum, image, link,
    locale, menu_ui, node, options, search, simpletest, statistics, syslog,
    taxonomy, telephone, text, update, views, migrate_drupal, migrate
Exception Uncaught e Connection.php     609 Drupal\Core\Database\Connection->ha
    Drupal\Core\Database\DatabaseExceptionWrapper: SQLSTATE[HY000]: General
    error: 1 table &quot;content_field_multivalue&quot; has more than one
    primary key: CREATE TABLE {content_field_multivalue} (
    vid INTEGER PRIMARY KEY AUTOINCREMENT CHECK (vid&gt;= 0),
    nid INTEGER NOT NULL CHECK (nid&gt;= 0) DEFAULT &#039;0&#039;,
    field_multivalue_value NUMERIC NULL DEFAULT NULL,
    delta INTEGER NOT NULL CHECK (delta&gt;= 0) DEFAULT &#039;0&#039;,
     PRIMARY KEY (delta)
    );
    ; Array
    (
    )
     in Drupal\migrate_drupal\Tests\Dump\DrupalDumpBase-&gt;createTable() (line
    53 of
    /home/huixinchen/drupal/core/modules/migrate_drupal/src/Tests/Dump/DrupalDumpBase.php).
    Drupal\Core\Database\Connection->handleQueryException(Object, 'CREATE TABLE
    {content_field_multivalue} (
    vid INTEGER PRIMARY KEY AUTOINCREMENT CHECK (vid&gt;= 0),
    nid INTEGER NOT NULL CHECK (nid&gt;= 0) DEFAULT '0',
    field_multivalue_value NUMERIC NULL DEFAULT NULL,
    delta INTEGER NOT NULL CHECK (delta&gt;= 0) DEFAULT '0',
     PRIMARY KEY (delta)
    );
    ', Array, Array)
    Drupal\Core\Database\Driver\sqlite\Connection->handleQueryException(Object,
    'CREATE TABLE {content_field_multivalue} (
    vid INTEGER PRIMARY KEY AUTOINCREMENT CHECK (vid&gt;= 0),
    nid INTEGER NOT NULL CHECK (nid&gt;= 0) DEFAULT '0',
    field_multivalue_value NUMERIC NULL DEFAULT NULL,
    delta INTEGER NOT NULL CHECK (delta&gt;= 0) DEFAULT '0',
     PRIMARY KEY (delta)
    );
    ', Array, Array)
    Drupal\Core\Database\Connection->query('CREATE TABLE
    {content_field_multivalue} (
    vid INTEGER PRIMARY KEY AUTOINCREMENT CHECK (vid&gt;= 0),
    nid INTEGER NOT NULL CHECK (nid&gt;= 0) DEFAULT '0',
    field_multivalue_value NUMERIC NULL DEFAULT NULL,
    delta INTEGER NOT NULL CHECK (delta&gt;= 0) DEFAULT '0',
     PRIMARY KEY (delta)
    );
    ')
    Drupal\Core\Database\Schema->createTable('content_field_multivalue', Array)
    Drupal\migrate_drupal\Tests\Dump\DrupalDumpBase->createTable('content_field_multivalue',
    Array)
    Drupal\migrate_drupal\Tests\Table\d6\ContentFieldMultivalue->load()
    Drupal\migrate\Tests\MigrateTestBase->loadDumps(Array)
    Drupal\migrate_drupal\Tests\MigrateFullDrupalTestBase->testDrupal()
    Drupal\simpletest\TestBase->run(Array)
    simpletest_script_run_one_test('1',
    'Drupal\migrate_drupal\Tests\d6\MigrateDrupal6Test')


did I do something wrong?

Just a note: strange malloc errors could be caused by buffer overflows. Malloc stores descriptors of allocated/unused memory in the memory, and when a buffer overflow happens, that data might be damaged. Especially on buffer underflows, since this data is usually before the allocated block. However, the crash happens only when the malloc/free is called again.

I recommend to use valgrind. If you use any kind of jit, don't forget --smc-check=all.

Sorry, didn't see the comments here before.

https://bugs.php.net/bug.php?id=69484 might have fixed the curl related segfault that I've seen here.

You're running the migrate tests with sqlite, they are currently not working, try the same with mysql. However, as I said in the other issue, that one might have fixed this problem and we actually committed a workaround for this test.

The _pcre_jit_compile segfaults might still exist, but they are not stable, so they don't happen all the time. I will get back to this...

> The _pcre_jit_compile segfaults might still exist, but they are
> not stable, so they don't happen all the time. I will get back
> to this...

Any news, Sascha? In doubt, try with newer PCRE.

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.