php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #36034 Order of destructor calls seems wrong.
Submitted: 2006-01-16 17:18 UTC Modified: 2006-01-17 00:30 UTC
From: ian_c_web at thejolly dot demon dot co dot uk Assigned:
Status: Not a bug Package: Scripting Engine problem
PHP Version: * OS: *
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: ian_c_web at thejolly dot demon dot co dot uk
New email:
PHP Version: OS:

 

 [2006-01-16 17:18 UTC] ian_c_web at thejolly dot demon dot co dot uk 
Description:
------------
I have a class that abstracts a database connection, which returns a 'recordset' class for certain operations.

The destructor of the recordset class calls the necessary free functions, which were issuing a 'warning: connection closed', which turned out to be related to the database object going out of scope first, and having it's destructor called. So I added a pointer to the database in the recordset, thinking this would keep the database in scope until the recordset was destroyed, but this did not seem to work. 

If I assigned the recordset to null (hence forcing destruction) everything works as required.

I think this is a scoping issue within PHP itself, as it seems to be calling the destructor on the db object too early, although it doesn't seem to actually be destroying the object. (I can still refer to public variables within the object.)

Reproduce code:
---------------
http://thejolly.demon.co.uk/~ian/phptest.php.txt

Expected result:
----------------
SpecificApp construct.
Application construct.
Database construct. (test: 5)
ResultSet construct.
ResultSet destruct. 
Database destruct. (test: 34)
Application destruct.


Actual result:
--------------
SpecificApp construct.
Application construct.
Database construct. (test: 5)
ResultSet construct.
Application destruct.
Database destruct. (test: 34)
ResultSet destruct.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2006-01-16 18:48 UTC] tony2001@php.net 
The engine doesn't know about "result sets" and "database objects", all it knows is that they are objects and they should be destroyed, so it's your responsibility to call resultset destructors before database destructors.
No bug here, this is expected behaviour.
 [2006-01-16 23:04 UTC] ian_c_web at thejolly dot demon dot co dot uk 
The bug is nothing to do with databases, it infact occured as I was trying to correctly close a result set.

The issue is with an object being destroyed when still referenced. If you take a look at the example I provided you will see there is no database code involved, however the destructors are still not called in the expected order. (The 'Database' object's destructor is called whilst it is still referenced by the 'Recordset' object.)

Please note the names I have used are purely semantic, there is no actual database code involved.
 [2006-01-16 23:27 UTC] sniper@php.net 
Come up with a real script first. No bug here, you're trying to assing a non existing variable. Ever heard about "error_reporting(E_ALL);" ??
 [2006-01-16 23:38 UTC] ian_c_web at thejolly dot demon dot co dot uk 
Oops, my cut and paste badness.

Still doesn't work as expected though, the 'Database' object is still being destroyed first.

(Example script updated.)

PS, no, didn't know about 'error_reporting(E_ALL);', cheers, that will be most useful.
 [2006-01-17 00:30 UTC] helly@php.net 
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

You cannot rely on any order of destruction in shutdown sequence. All you can do is ensuring yourself that all related variables are set NULL or are being unset() prior to script end. If you do that in correct order then php calls the destructors in correct order.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Thu Apr 25 05:01:33 2024 UTC