Segfault in ds_htable_lookup_bucket_by_hash

[rvanvelzen]

• Reproducible on multiple machines, but mine is running PHP 7.1.8-2+ubuntu16.04.1+deb.sury.org+4 (cli) (built: Aug 4 2017 13:04:12) ( NTS ) with php-ds 1.2.0

Slightly convoluted though representative test case (note that it does not always segfault - it also sometimes produces an infinite loop, and sometimes succeeds):

<?php

use Ds\Set;

$set = new Set();

$objects = [];
for ($ii = 0; $ii < 100; ++$ii) {
    $objects[] = $obj = new stdClass();
    $set->add($obj);
}

$set->clear();

foreach ($objects as $obj) {
    $set->add($obj);
}

foreach ($objects as $obj) {
    $set->add($obj);
}

var_dump($set);

valgrind output:

==9953== Memcheck, a memory error detector
==9953== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==9953== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==9953== Command: php ./_test/crashy-washy.php
==9953== 
--9953-- WARNING: Serious error when reading debug info
--9953-- When reading debug info from /usr/lib/x86_64-linux-gnu/libsasl2.so.2.0.25:
--9953-- Ignoring non-Dwarf2/3/4 block in .debug_info
--9953-- WARNING: Serious error when reading debug info
--9953-- When reading debug info from /usr/lib/x86_64-linux-gnu/libsasl2.so.2.0.25:
--9953-- Last block truncated in .debug_info; ignoring
--9953-- WARNING: Serious error when reading debug info
--9953-- When reading debug info from /usr/lib/x86_64-linux-gnu/libsasl2.so.2.0.25:
--9953-- parse_CU_Header: is neither DWARF2 nor DWARF3 nor DWARF4
==9953== Invalid read of size 4
==9953==    at 0x191BF531: ds_htable_lookup_bucket_by_hash (ds_htable.c:354)
==9953==    by 0x191C0354: ds_htable_lookup_or_next (ds_htable.c:673)
==9953==    by 0x191C03F4: ds_htable_put (ds_htable.c:691)
==9953==    by 0x191C215E: ds_set_add (ds_set.c:58)
==9953==    by 0x191C218A: ds_set_add_va (ds_set.c:64)
==9953==    by 0x191CFFA8: zim_Set_add (php_set_ce.c:52)
==9953==    by 0x418739: ZEND_DO_FCALL_SPEC_RETVAL_UNUSED_HANDLER (zend_vm_execute.h:972)
==9953==    by 0x3BF89A: execute_ex (zend_vm_execute.h:429)
==9953==    by 0x41A91F: zend_execute (zend_vm_execute.h:474)
==9953==    by 0x375FE2: zend_execute_scripts (zend.c:1476)
==9953==    by 0x31265F: php_execute_script (main.c:2537)
==9953==    by 0x41CBA6: do_cli (php_cli.c:993)
==9953==  Address 0x10990b12c is not stack'd, malloc'd or (recently) free'd
==9953== 
==9953== 
==9953== Process terminating with default action of signal 11 (SIGSEGV)
==9953==  Access not within mapped region at address 0x10990B12C
==9953==    at 0x191BF531: ds_htable_lookup_bucket_by_hash (ds_htable.c:354)
==9953==    by 0x191C0354: ds_htable_lookup_or_next (ds_htable.c:673)
==9953==    by 0x191C03F4: ds_htable_put (ds_htable.c:691)
==9953==    by 0x191C215E: ds_set_add (ds_set.c:58)
==9953==    by 0x191C218A: ds_set_add_va (ds_set.c:64)
==9953==    by 0x191CFFA8: zim_Set_add (php_set_ce.c:52)
==9953==    by 0x418739: ZEND_DO_FCALL_SPEC_RETVAL_UNUSED_HANDLER (zend_vm_execute.h:972)
==9953==    by 0x3BF89A: execute_ex (zend_vm_execute.h:429)
==9953==    by 0x41A91F: zend_execute (zend_vm_execute.h:474)
==9953==    by 0x375FE2: zend_execute_scripts (zend.c:1476)
==9953==    by 0x31265F: php_execute_script (main.c:2537)
==9953==    by 0x41CBA6: do_cli (php_cli.c:993)
==9953==  If you believe this happened as a result of a stack
==9953==  overflow in your program's main thread (unlikely but
==9953==  possible), you can try to increase the size of the
==9953==  main thread stack using the --main-stacksize= flag.
==9953==  The main thread stack size used in this run was 8388608.
==9953== 
==9953== HEAP SUMMARY:
==9953==     in use at exit: 3,395,862 bytes in 28,036 blocks
==9953==   total heap usage: 34,445 allocs, 6,409 frees, 4,830,094 bytes allocated
==9953== 
==9953== LEAK SUMMARY:
==9953==    definitely lost: 0 bytes in 0 blocks
==9953==    indirectly lost: 0 bytes in 0 blocks
==9953==      possibly lost: 2,318,120 bytes in 18,496 blocks
==9953==    still reachable: 1,077,742 bytes in 9,540 blocks
==9953==         suppressed: 0 bytes in 0 blocks
==9953== Rerun with --leak-check=full to see details of leaked memory
==9953== 
==9953== For counts of detected and suppressed errors, rerun with: -v
==9953== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault (core dumped)

(partial) gdb output:

(gdb) run
Starting program: /usr/bin/php ./_test/crashy-washy.php
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x00007fffe3c2f531 in ds_htable_lookup_bucket_by_hash (table=0x7fffe322a820, key=0x7ffff3813240, hash=513461591) at /home/richard/PhpstormProjects/php-ds/src/ds/ds_htable.c:354
354	        if (DS_HTABLE_BUCKET_HASH(bucket) == hash) {
(gdb) bt full
#0  0x00007fffe3c2f531 in ds_htable_lookup_bucket_by_hash (table=0x7fffe322a820, key=0x7ffff3813240, hash=513461591) at /home/richard/PhpstormProjects/php-ds/src/ds/ds_htable.c:354
        bucket = 0x8003f7921220
        index = 538976377

If I can provide anything more, please let me know.

[rtheunissen]

Released as v1.2.2 🎉

[rvanvelzen]

Thanks!