Bug #78930 [Com]: PDO Sqlite not close connection after destruction (windows only)

Edit report at https://bugs.php.net/bug.php?id=78930&edit=1 ID: 78930 Comment by: julien dot boudry at gmail dot com Reported by: julien dot boudry at gmail dot com Summary: PDO Sqlite not close connection after destruction (windows only) Status: Not a bug Type: Bug Package: PDO SQLite Operating System: Windows only PHP Version: 7.4.0 Block user comment: N Private report: N New Comment: Thank you for your support. We actually put our finger on at least one point that doesn't make sense, so I'll let you reformulate it it in a new ticket. You have more skills than I do to do it well ;-) Previous Comments: ------------------------------------------------------------------------ [2019-12-08 20:32:56] requinix@php.net I can't explain why the presence of a destructor, even an empty one, changes the behavior, or why it is apparently new to 7.4, so that could be a bug... but I feel we've digressed too far from the original purpose of this ticket, so I'll draw up a simpler repro script and create a new bug report. It may be a matter for documentation. That aside, general programming practice with destructors is that, if you use them, you must clean up after yourself as necessary, and if I unset($this->myTest) in the destructor (like PHP would have done itself) then it works. Regarding cycles, 1. If your code is too complicated to maintain then you need to refactor. 2. gc_collect_cycles() isn't a hack - it's the answer. Cyclic references are a problem for any garbage collector, and the effort required to find those cycles is too much for PHP to tackle aggressively like it does noncyclic references; after all, the engine is designed to be used for short-lived requests where having a few KB of unreclaimed memory for a couple milliseconds is not a problem. As a developer, when you build larger and larger applications you become more and more responsible for how it runs - you can't expect PHP to solve all your problems for you because it looks like a high-level language. ------------------------------------------------------------------------ [2019-12-08 20:08:24] julien dot boudry at gmail dot com Okay, I see and it works in this simple example. But if the use of gc_collect_cycles() already appears a bit like a hack. That the addition of the presence of a destructor changes the way properties are cleaned still seems to me to be counter-intuitive (and not documented to my knowledge). Now, in a much more complex code like the one I initially had a problem with. With many circular references and destructors everywhere. The problem is then more serious. I had already tried the gc_collect_cycles() without success. But I can't clean all the properties by hand, because it makes the code unnecessarily verbose, but also because the call order of the destroyers is not guaranteed "in any order during the shutdown sequence. " (from official doc.) and that point produce others problems. ------------------------------------------------------------------------ [2019-12-08 19:55:59] requinix@php.net I see now, the behavior is a bit different. That prepared statement you created is keeping the SQLite resource in use. You have to unset $base as well as $prepare. ------------------------------------------------------------------------ [2019-12-08 19:39:41] julien dot boudry at gmail dot com You're right, exactly the same, it's working. But. If I had a destructor (and change a visibility), it fails again. Look only the last revision here (or the last version). https://gist.github.com/julien-boudry/6672e4e98e48b14fc6a6871942a6ef2b/revisions ------------------------------------------------------------------------ [2019-12-08 19:27:53] requinix@php.net > Even if I add gc_collect_cycles(); just before last line with unlink call. It's not > working better. > I do not seem to have any convincing solution for my use case. Adding gc_collect_cycles() works for me. Are you running the *exact* code you posted but with a gc_collect_cycles(); added immediately before the unlink()? ------------------------------------------------------------------------ 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=78930 -- Edit this bug report at https://bugs.php.net/bug.php?id=78930&edit=1