Unassigning myself, there's a deeper rabbit hole than expected. The fix I attempted for the attached test to give the expected result is causing memory leaks in other tests.
Also, related issue: $rsrc += 1; leaks the resource.


--TEST--
Bug #75393 (Crash when assign-adding an array to an object)
--FILE--
<?php

try {
        $o = new stdClass;
        $o += [];
} catch (\Error $e) {
        var_dump($e->getMessage(), $o);
}

?>
--EXPECTF--

Notice: Object of class stdClass could not be converted to int in %s on line %d
string(25) "Unsupported operand types"
object(stdClass)#1 (0) {
}

I can not reproduce this....

this seems already be fixed: https://3v4l.org/oF3Al

@laruence: It doesn't crash with master, yes. But it still does with PHP 7.0 and  7.1.

Also $o must not be int(1), but must be an instanceof stdClass afterwards.

why not?

<?php
$o = new Stdclass();
var_dump((int)$o);

output:
PHP Notice:  Object of class stdClass could not be converted to int in /tmp/1.php on line 3
int(1)

and for:
$o += []

we preparing operands first, then trying to do add, then result in unsupported operand, which seems reasonable to me

of course I also understand why it should be an stdclass instance, it also make sense, but it will make the codes complex, and this is really a rarely wrong case, so I think choose the easy way is a good chioce here.

Similarly:

php -r 'set_error_handler(function() { throw new \Exception; }); $a = "2"; $a .= "a"; try { $a+=1; } catch (\Exception $e) { } var_dump($a);'
int(3)

(instead of string(2) "2a")

(turns out the crash has already been fixed in the most recent git, but not yet in the last release. - renaming thus.)

Triage: Segfault fixed in supported versions, but the incorrect type conversion still takes place.

This seems to be fixed as of PHP 8.0.0[1], and I don't think a
backport makes much sense at this point in time.  Or am I missiung
something?

[1] <https://3v4l.org/M8f4X>

Yeah, looks good now. Let's consider it fixed and not change the semantics of existing old versions.