|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #52393 __destructor of parameter object called on return
Submitted: 2010-07-21 20:23 UTC Modified: 2010-07-27 12:35 UTC
From: r dot spliet at student dot tudelft dot nl Assigned:
Status: Closed Package: Class/Object related
PHP Version: 5.3.2 OS: Fedora 13
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.
Block user comment
Status: Assign to:
Bug Type:
From: r dot spliet at student dot tudelft dot nl
New email:
PHP Version: OS:


 [2010-07-21 20:23 UTC] r dot spliet at student dot tudelft dot nl
The situation is as following:
class mysqlControl holds a MySQL connection. This class has a __destruct() method to close this connection properly
Class x has one of these mysqlControl objects as a private variable.
Class y has a method to represent itself in a MySQL way, and needs to escape a string. For this it needs the mysqlControl that class X holds.

Now what happens is that Class x calls Class y's method to represent itself in some form that's useful to query MySQL. As a parameter to y's method X gives it's mysqlControl. Before y's method actually starts executing, mysqlControl's destructor is called. This means the connection is closed, and everything breaks.

Expected result:
I expected method y to not call mysqlControl's destructor but just uses the mysqlControl given and forgets about it.

Actual result:
mysqlControl's destructor gets called, breaking the mysql_real_escape_string() method before it could be used by class Y's method.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2010-07-27 01:05 UTC]
-Status: Open +Status: Feedback
 [2010-07-27 01:05 UTC]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with <?php and ends with ?>,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.

 [2010-07-27 12:35 UTC] r dot spliet at student dot tudelft dot nl
-Status: Feedback +Status: Closed
 [2010-07-27 12:35 UTC] r dot spliet at student dot tudelft dot nl
My apologies. My problems were not related to class destruction on itself, but on the behaviour of mysql_connect(). A different object's destructor was (correctly) called, leading to the confusion. debug_print_backtrace() confirmed PHP's behaviour is correct and documented.
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun May 26 02:01:30 2024 UTC