ID: 19529
Comment by: justin@sonicity.com
Reported By: sroussey@network54.com
Status: Assigned
Bug Type: MySQL related
Operating System: Linux 2.4.18
PHP Version: 4.2.3
Assigned To: georg
New Comment:
A forum I'm helping with also ran into this problem (the site runs
vbulletin). I'm trying to track down exactly when it started
happening. I can say that with apache 1.3.26 and php 4.2.1 and mysql
4.23.49, it didn't happen, nor with apache2.0.43+php4.2.3+mysql4.23.49.
It definately does happen with apache 1.3.27+php4.2.3+mysql4.23.53,
leading me to believe that it's an issue with something that changed in
mysql since last spring, but unless I misread, that contradicts some
other reports here. Disabling vbulletin's persistent connection usage
eliminated the errors, of which there were tons.
Previous Comments:
------------------------------------------------------------------------
[2002-10-10 19:21:14] zak@php.net
Interesting stuff. I am heading out on the road for about
a month. I will follow up with this as soon as I get
stable network access again.
------------------------------------------------------------------------
[2002-10-10 15:03:07] derick@php.net
reassigning
------------------------------------------------------------------------
[2002-10-10 13:07:13] sroussey@network54.com
OK, no need to wait. Getting the errors already with 3.23.49a.
I looked at the change in CVS and it only frees a memory leak from
unbuffered queries.
------------------------------------------------------------------------
[2002-10-10 13:04:54] sroussey@network54.com
PS: In this bug system, should I be using Add Comment rather than Edit
Submission? I keep reseting the Status and I don't mean to. Maybe the
bug system should add whatever is the current choice is to the list
available.
------------------------------------------------------------------------
[2002-10-10 13:01:28] sroussey@network54.com
Recent CVS does not help 4.0.2 over the long term (24 hours). I woke up
and the log was full of the error. Will try 3.23.49a for 24 hours and
report back.
As far as explicitly calling mysql_free_result(), yikes! Trying to find
any missing will be a pain!
I guess the real way to deal with this is (yuck) track all the result
sets and dispose of any left over when the connection is being reset.
Therefore getting the order right.
Unless we can reset the connenction last. Is there a way to order the
callbacks?
------------------------------------------------------------------------
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
http://bugs.php.net/19529
--
Edit this bug report at http://bugs.php.net/?id=19529&edit=1