aerscript/Aer

Fork 0

Class destructor is not called automatically #47

New Issue

Closed

opened 2019-03-18 12:56:02 +01:00 by belliash · 7 comments

belliash commented

2019-03-18 12:56:02 +01:00

Owner

AerScript Information

Aer Version (or commit ref): d4992ff4ba
Operating System: Linux
System Architecture (eg. arm, x86_64, ...): x86_64

Your problem description

Class destructor is not called automatically, see example code:

<?php
class X {
    function __construct() {
            echo 'Constructor';
    }
    function __destruct() {
            echo 'Destructor';
    }
}
$x = new X();
?>

Above code gives the same result in PH7. This bug is derived from upstream project.

Expected results

'ConstructorDestructor' should appear.

Current results

'Constructor' appears only, what means that destructor is not called.

# AerScript Information - Aer Version (or commit ref): d4992ff4ba - Operating System: Linux - System Architecture (eg. arm, x86_64, ...): x86_64 # Your problem description Class destructor is not called automatically, see example code: <?php class X { function __construct() { echo 'Constructor'; } function __destruct() { echo 'Destructor'; } } $x = new X(); ?> Above code gives the same result in PH7. This bug is derived from upstream project. # Expected results 'ConstructorDestructor' should appear. # Current results 'Constructor' appears only, what means that destructor is not called.

belliash added the

bug

label 2019-03-18 12:56:02 +01:00

belliash commented

2019-03-18 13:14:55 +01:00

Author

Owner

Additionally, we have broken the unset() function, as it is calling the __destruct() method in PH7.

belliash commented

2019-03-19 10:09:19 +01:00

Author

Owner

unset() builtin function seems broken partially since bd4d146d0a. Looks like it was never working for variables defined with a specified data type. If no data type is specified then unset() is still working.

Seems, there is some difference between:

$x = new Obj();

and

object $x = new Obj();

unset() builtin function seems broken partially since bd4d146d0a. Looks like it was never working for variables defined with a specified data type. If no data type is specified then unset() is still working. Seems, there is some difference between: $x = new Obj(); and object $x = new Obj();

belliash commented

2019-03-19 10:30:11 +01:00

Author

Owner

object $x;
$x = new Obj();

Above version is not affected.

object $x; $x = new Obj(); Above version is not affected.

belliash commented

2019-03-19 10:31:06 +01:00

Author

Owner

This is related to missed OP_POP call when assigning a value during variable declaration.

belliash referenced this issue from a commit

2019-03-19 10:38:12 +01:00

Partially fix #47, static variables are still affected.

belliash referenced this issue from a commit

2019-03-19 10:42:58 +01:00

Abort on SXERR_ABORT, #47.

belliash referenced this issue from a commit

2019-03-19 12:52:41 +01:00

Enable garbage collector for Program class. This also partially fixes #47, as from now Program::__destruct() will be called automatically.

belliash commented

2019-03-19 13:07:32 +01:00

Author

Owner

Fixed everything, what got broken within 'typehinting' branch.
Static variables (both in methods/closure and class attributes) were never destroyed properly in PH7. Fixing this bug will lead to:

fixing a garbage collector and freeing more memory,
automatically calling a destructor if available (when static variable was an object)

Fixed everything, what got broken within 'typehinting' branch. Static variables (both in methods/closure and class attributes) were never destroyed properly in PH7. Fixing this bug will lead to: * fixing a garbage collector and freeing more memory, * automatically calling a destructor if available (when static variable was an object)

belliash commented

2019-04-17 17:43:25 +02:00

Author

Owner

Segmentation fault fixed in 407bcf5a29.

Segmentation fault fixed in 407bcf5a29.

belliash commented

2019-06-29 16:08:42 +02:00

Author

Owner

Fixed in 171456beb4.
Test extended in 4afcbc0815 confirms, it is working.

Fixed in 171456beb4. Test extended in 4afcbc0815 confirms, it is working.