Bug #72489 [ReO]: PHP Crashes When Modifying Array Containing MySQLi Result Data

Edit report at https://bugs.php.net/bug.php?id=72489&edit=1 ID: 72489 User updated by: s7g2vp2 at yahoo dot co dot uk Reported by: s7g2vp2 at yahoo dot co dot uk Summary: PHP Crashes When Modifying Array Containing MySQLi Result Data Status: Re-Opened Type: Bug Package: MySQLi related Operating System: Windows Server 2012r2 PHP Version: 7.0.8 Block user comment: N Private report: N New Comment: Hi. Just checking to see if you now have everything to re-produce the bug. Thanks. Previous Comments: ------------------------------------------------------------------------ [2016-08-18 14:18:09] s7g2vp2 at yahoo dot co dot uk We have finally managed to reproduce the problem outside of our application. I have updated the case summary as the trigger turns out to be something different to what I originally thought. There appears to be more than one version of the problem as different code can trigger a crash in different places. I have included a sample script below which should allow you to reproduce the problem (tested on MS-Windows and Mac OS X). <?php $dbHost = "127.0.0.1"; $dbUserName = ""; $dbPassword = ""; $dbDatabase = ""; $dbObj = new mysqli($dbHost, $dbUserName, $dbPassword, $dbDatabase); $tableDropSQL = "DROP TABLE php7bug"; $dbObj->query($tableDropSQL); $tableCreateSQL = "CREATE TABLE php7bug (id INT(6) UNSIGNED AUTO_INCREMENT PRIMARY KEY, code VARCHAR(30) NOT NULL)"; if ($dbObj->query($tableCreateSQL) === TRUE) { echo "Table MyGuests created successfully\n"; $seedSQL = "INSERT INTO php7bug (code) VALUES ('code1');"; $seedSQL .= "INSERT INTO php7bug (code) VALUES ('code2');"; $seedSQL .= "INSERT INTO php7bug (code) VALUES ('code3');"; if ($dbObj->multi_query($seedSQL) === TRUE) { echo "New records created successfully\n"; } } $dbObj = new mysqli($dbHost, $dbUserName, $dbPassword, $dbDatabase); $expectedRecords = 3; $id = 1; $subRow = array(); if ($stmt2 = $dbObj->prepare("SELECT id, code FROM php7bug")) { $stmt2->attr_set(MYSQLI_STMT_ATTR_CURSOR_TYPE, MYSQLI_CURSOR_TYPE_READ_ONLY); if ($stmt2->execute()) { $stmt2->bind_result($subRow['id'], $subRow['code']); $count = 1; while ($stmt2->fetch()) { error_log("row: " . $count++ . " of " . $expectedRecords . "\n"); // DOESN'T CAUSE SEGFAULT // $subRow['code'] = array(); // DOESN'T CAUSE SEGFAULT // $subRow['code'] = array('id' => 1); // DOESN'T CAUSE SEGFAULT // $subRow['code'] = array('id' => $id); // CAUSES SEGFAULT - NEVER REACHES "Finished 1" $testArray = array('id' => $id); $subRow['code'] = $testArray; // CAUSES SEGFAULT - NEVER REACHES "Finished 2" // $subRow['code'] = array('id' => $id); // $testArray = array('id' => $id); // $subRow['code'] = $testArray; // CAUSES SEGFAULT - NEVER REACHES "Finished 1" // $metaData = array(); // $metaData['id'] = $id; // $subRow['code'] = $metaData; } } } echo "Finished 1\n"; // this is the line which crashes the script $newArray = array(); echo "Finished 2\n"; ?> ------------------------------------------------------------------------ [2016-08-18 13:47:42] cmb@php.net Re-opened on OP request. ------------------------------------------------------------------------ [2016-08-07 04:22:27] php-bugs at lists dot php dot net 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. ------------------------------------------------------------------------ [2016-07-28 10:53:07] ab@php.net Indeed, thanks for the hint. The symbols match now. Unfortunately it's still impossible to come to the crash cause :( Though, more info for you - the particular statement used for mysqli_prepare is SELECT * FROM METADATA WHERE (orderid = ?) AND (orderitemid = ?) AND (section = ?) AND (orderitemcomponentid = ?) The crash happens while preparing it. I would ask you to research the code around it to maybe extract a reproduce snippet. Another chance, which could possibly bring more info, were to create a dump while USE_ZEND_ALLOC=0 is set in the environment. That way the PHP memory manager is turned off, so some useful info could be delivered from CRT. Thanks. ------------------------------------------------------------------------ [2016-07-26 08:16:01] s7g2vp2 at yahoo dot co dot uk Hi. I used the build available from windows.php.net I'm sure I took the php 7.0.8 build and added the debug pack: php-debug-pack-7.0.8-Win32-VC14-x64.zip ------------------------------------------------------------------------ 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=72489 -- Edit this bug report at https://bugs.php.net/bug.php?id=72489&edit=1