Edit report at https://bugs.php.net/bug.php?id=72175&edit=1
ID: 72175
Updated by: nikic@php.net
Reported by: netvicious at gmail dot com
Summary: Impossibility of creatiing multiple connections to
Interbase with php 7.0
-Status: Assigned
+Status: Open
Type: Bug
Package: InterBase related
Operating System: Ubuntu 16.04 LTS
PHP Version: 7.0.6
-Assigned To: nikic
+Assigned To:
Block user comment: N
Private report: N
Previous Comments:
------------------------------------------------------------------------
[2017-01-23 12:57:42] netvicious at gmail dot com
Hi!
It seems we don't had any progress on this bug from a long time ago.
Nikic, the patch you published didn't worked and the question you did on 2016-07-10 obviously
it's yes, if we close the conx2 the conx1 should be kept as it was before.
But the problem it's not when we're closing links, the problem it's when we're
connecting a new link. On this process the old link it's closed. It seems to be using a
variable for the only one link supported instead of using a list and closing the correct index of
the link of the list.
If you do a simple echo with the link you can see the links are numbered
$conx = ibase_pconnect(DB_HOST . ":" . DB_NAME,DB_USER,DB_PWD,DB_CHARACTER) or
die(ibase_errcode() . ' ' . ibase_errmsg());
echo $conx . "<br/>\n";
$conx2 = ibase_pconnect(DB_HOST . ":" . DB_NAME,DB_USER,DB_PWD,DB_CHARACTER) or
die(ibase_errcode() . ' ' . ibase_errmsg());
echo $conx2 . "<br/>\n";
If the connections are ok you should get something like:
Resource id #1
Resource id #2
The system it's saving the connections in order.
The problem should be in some place where it checks if that link was previously connected to
database (or in the garbage collector).
A similar code should be on the mysql connections and other database drivers.
I know you tried to fix it, but I ask you to ask to other php developers which know a bit others
database drivers; because that piece of code should be very similar between drivers.
Regards,
------------------------------------------------------------------------
[2016-12-13 22:33:49] m dot muncke at computer1020 dot at
Hello,
I have this problem in freeBSD port ver. 7.0.11 and upgrading to 7.0.14 did not solve the issue. Can
we have a release estimate when this fix will be included?
Thank you
M.Muncke
------------------------------------------------------------------------
[2016-12-06 10:32:48] us at menatwork dot de
This bug is still present in version 7.1.0 for Windows
------------------------------------------------------------------------
[2016-07-11 09:22:49] netvicious at gmail dot com
Hi nikic, thanks for assigning the bug.
The code:
$link = ibase_connect($foo);
$link2 = ibase_connect($foo);
ibase_close($link2);
That functions are similar to mysqli, but changing the type of the DB
ibase_connect = mysqli_connect
ibase_close = mysqli_close
If you close $link2, $link should remain open and working.
The current problem it's when you're creating a new connection to a database which has
another connection opened before in the same script. The first one should remain open and working
instead of being closed as it's done with the current interbase module.
------------------------------------------------------------------------
[2016-07-10 11:44:17] nikic@php.net
The resource refcount management in ext/interbase is in general very broken. It uses
zend_list_delete() in *_close() functions, which is not memory safe, and adds additional refs
elsewhere to compensate.
I'm not even clear on how some parts of this are *supposed* to work. For example, what should
this code do?
$link = ibase_connect($foo);
$link2 = ibase_connect($foo);
ibase_close($link2);
Should this ibase_close() call close all of $link, $link2 and the default link? After all, all of
these share the same connection. If ibase_close($link2) should not close $link, then we can't
reuse the same connection for both (or need to introduce a double indirection). Or make
ibase_close() effectively a no-op.
------------------------------------------------------------------------
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=72175
--
Edit this bug report at https://bugs.php.net/bug.php?id=72175&edit=1