Req #14613 [Asn->Bgs]: Implement Function/Feature Conformity Tests
Edit report at http://bugs.php.net/bug.php?id=14613&edit=1 ID: 14613 Updated by: z...@php.net Reported by:z...@php.net Summary:Implement Function/Feature Conformity Tests -Status: Assigned +Status: Bogus Type: Feature/Change Request Package:*General Issues Operating System: * PHP Version:* Assigned To: zak Block user comment: N Private report: N New Comment: Wow. Nearly ten years old. o.O I have no idea if this is currently relevant. If so, some brave soul should re-open the issue. Previous Comments: [2010-12-29 11:58:13] j...@php.net Ancient issue, will not close for now. Zak can do it himself.. [2001-12-20 02:14:56] z...@php.net Assigning it to myself so that I don't forget. Now I just have to get to the other bug reports that are assigned to me. :) [2001-12-20 02:14:02] z...@php.net I strongly believe that PHP needs to continue evolving and improving. However, I also recognise the importance of maintaining backwards compatibility. To help balance these two conflicting desires, I have been kicking around the idea of implementing a set of tests to help determine when the behavior of a function changes. The basic idea is to run the tests against the various version of PHP, compare the output and flag when differences crop up. Users would be able to run these tests using a make target. The data from these tests could be used by a utility program that walks a directory structure, reading php files and looking for functions/features that have changed behavior. I would like to call these 'Lemosian Conformity Tests' in honor of Manuel's consistent and vociferous work on preserving BC. :) While I don't like his approach, I agree that it is a valid concern. Personally, rather than being chained to BC, I would rather that we actively work to help users deal with changes more effectively. Additionally, these changes would help developers and the QA team spot unintentional changes to function behavior. -- Edit this bug report at http://bugs.php.net/bug.php?id=14613&edit=1
#25288 [Opn->Bgs]: Wrong JulianDayCount
ID: 25288 Updated by: [EMAIL PROTECTED] Reported By: josep dot gorro at trendcomms dot es -Status: Open +Status: Bogus Bug Type: Calendar related Operating System: WinNT PHP Version: 4.3.1 New Comment: The fault here lies with Excel. Julian Day Counts start at noon, rather than midnight. Combine this with the timezone of your computer and you likely have your first day of error. Excel also believes that February 29, 1900 is a valid day. This accounts for day two of your error. Previous Comments: [2003-08-28 06:25:20] josep dot gorro at trendcomms dot es Description: I'm generating a function to calculate a date in Julian day count to be used in excel spreadsheet. Always I obtain a 2 days difference. Is this a bug? Reproduce code: --- Expected result: Without the correction ($total=$jd1 - $jd2;) the result is: 2452880 8/28/2003 2415021 1/1/1900 Real counter: 37859 Whit the correction ($total=$jd1 - $jd2 + 2;) the result is: 2452880 8/28/2003 2415021 1/1/1900 Real counter: 37861 First one isn't correct, second one is fine. -- Edit this bug report at http://bugs.php.net/?id=25288&edit=1
#14562 [Asn->Csd]: dBase: Unable to obtain dBase file structure
ID: 14562 Updated by: [EMAIL PROTECTED] Reported By: tom dot polak at post dot sk -Status: Assigned +Status: Closed Bug Type: Feature/Change Request Operating System: Solaris PHP Version: 4.1.0 Assigned To: zak New Comment: Function dbase_get_header_info() has been added to the dbase extension. The function accepts a dbase connection handle as its sole argument and returns an array of associative arrays. The arrays are of the form: Array ( [0] => Array ( [name] => date [type] => date [length] => 8 [decimal places] => 0 [printf format] => %8s [record offset] => 1 ) [1] => Array ( [name] => name [type] => character [length] => 50 [decimal places] => 0 [printf format] => %-50s [record offset] => 9 ) ... The feature has been added to the CVS repository and will hopefully be included in the next major release of PHP after 4.3. Previous Comments: [2001-12-17 19:37:25] [EMAIL PROTECTED] I wrote a bit of sample code that may do what you want. Visit http://www.php-er.com/html/rn45re878.html - the first example for unpack() shows how to use unpack() to read the format of a dbf file. I will take a look at adding the functionality to PHP* in a few weeks. * As long as no one has a good reason for me not too. :) [2001-12-17 10:58:29] tom dot polak at post dot sk Hello, I would like to request feature for PHP dBase support functions. It will be helpfull, if will be possible to read dBase file header information, not only number of fields and its names. For dBase importing is also important data type, length and precision (if applicable). If you thing, that I can help you with this request, send me mail. Thank you. Best regards, Tomas Polak -- Edit this bug report at http://bugs.php.net/?id=14562&edit=1
#22346 [Asn->Csd]: Make fails: more undefined references to errno
ID: 22346 Updated by: [EMAIL PROTECTED] Reported By: erwthijs at hotmail dot com -Status: Assigned +Status: Closed Bug Type: MySQL related Operating System: Linux Red Hat 8.0 PHP Version: 4.3.2-dev Assigned To: zak New Comment: This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Ilia got to it before I did. Damn! It was such an easy fix too! :) Previous Comments: [2003-03-23 09:55:49] erik-sourcemage at home dot dot dot nl Same problem here, also with mysql and some other packaged. Probably caused by the new glibc-2.3.2. No problems when I compile with 2.3.1 glibc but 2.3.2 breaks php as well as mysql. [2003-03-21 12:25:36] [EMAIL PROTECTED] Will be fixed as soon as I can get the CVS checkout to build. :) [2003-03-21 10:13:31] ciano at borgosatollo dot it Ok, I fixed somehow the problem and got this compiled. I had to add the "#include " in the follwings files: php-4.3.1/ext/mysql/libmysql/my_lib.c php-4.3.1/ext/mysql/libmysql/my_malloc.c php-4.3.1/ext/mysql/libmysql/my_tempnam.c php-4.3.1/ext/mysql/libmysql/my_realloc.c php-4.3.1/ext/mysql/libmysql/my_delete.c php-4.3.1/ext/mysql/libmysql/my_error.c php-4.3.1/ext/mysql/libmysql/my_getwd.c php-4.3.1/ext/mysql/libmysql/my_once.c This seams to let me get to the end still haveing this warning: /home/lucio/php/php-4.3.1/ext/mysql/libmysql/my_tempnam.c:104: the use of `tempnam' is dangerous, better use `mkstemp' but i didn't change the sources further. [2003-03-21 09:57:50] ciano at borgosatollo dot it (sorry for the other post but I dind't find this one before) I'm compiling with this configure: "./configure --enable-calendar --with-zlib --with-bz2 --enable-ftp --with-ttf --with-mysql --with-mysql-sock --with-pgsql --enable-sockets --with-apxs2=/usr/local/apache2/bin/apxs" on a mdk9.0 and gcc 3.2.2 /bin/sh libtool --silent --mode=link gcc -export-dynamic -g -O2 -avoid-version -module ext/zlib/zlib.lo ext/zlib/zlib_fopen_wrapper.lo ext/bz2/bz2.lo ext/calendar/calendar.lo ext/calendar/dow.lo ext/calendar/french.lo ext/calendar/gregor.lo ext/calendar/jewish.lo ext/calendar/julian.lo ext/calendar/easter.lo ext/calendar/cal_unix.lo ext/ctype/ctype.lo ext/ftp/php_ftp.lo ext/ftp/ftp.lo ext/mysql/php_mysql.lo ext/mysql/libmysql/libmysql.lo ext/mysql/libmysql/errmsg.lo ext/mysql/libmysql/net.lo ext/mysql/libmysql/violite.lo ext/mysql/libmysql/password.lo ext/mysql/libmysql/my_init.lo ext/mysql/libmysql/my_lib.lo ext/mysql/libmysql/my_static.lo ext/mysql/libmysql/my_malloc.lo ext/mysql/libmysql/my_realloc.lo ext/mysql/libmysql/my_create.lo ext/mysql/libmysql/my_delete.lo ext/mysql/libmysql/my_tempnam.lo ext/mysql/libmysql/my_open.lo ext/mysql/libmysql/mf_casecnv.lo ext/mysql/libmysql/my_read.lo ext/mysql/libmysql/my_write.lo ext/mysql/libmysql/errors.lo ext/mysql/libmysql/my_error.lo ext/mysql/libmysql/my_getwd.lo ext/mysql/libmysql/my_div.lo ext/mysql/libmysql/mf_pack.lo ext/mysql/libmysql/my_messnc.lo ext/mysql/libmysql/mf_dirname.lo ext/mysql/libmysql/mf_fn_ext.lo ext/mysql/libmysql/mf_wcomp.lo ext/mysql/libmysql/typelib.lo ext/mysql/libmysql/safemalloc.lo ext/mysql/libmysql/my_alloc.lo ext/mysql/libmysql/mf_format.lo ext/mysql/libmysql/mf_path.lo ext/mysql/libmysql/mf_unixpath.lo ext/mysql/libmysql/my_fopen.lo ext/mysql/libmysql/mf_loadpath.lo ext/mysql/libmysql/my_pthread.lo ext/mysql/libmysql/my_thr_init.lo ext/mysql/libmysql/thr_mutex.lo ext/mysql/libmysql/mulalloc.lo ext/mysql/libmysql/string.lo ext/mysql/libmysql/default.lo ext/mysql/libmysql/my_compress.lo ext/mysql/libmysql/array.lo ext/mysql/libmysql/my_once.lo ext/mysql/libmysql/list.lo ext/mysql/libmysql/my_net.lo ext/mysql/libmysql/dbug.lo ext/mysql/libmysql/strmov.lo ext/mysql/libmysql/strxmov.lo ext/mysql/libmysql/strnmov.lo ext/mysql/libmysql/strmake.lo ext/mysql/libmysql/strend.lo ext/mysql/libmysql/strfill.lo ext/mysql/libmysql/is_prefix.lo ext/mysql/libmysql/int2str.lo ext/mysql/libmysql/str2int.lo ext/mysql/libmysql/strinstr.lo ext/mysql/libmysql/strcont.lo ext/mysql/libmysql/strcend.lo ext/mysql/libmysql/bchange.lo ext/mysql/libmysql/bmove.lo ext/mysql/libmysql/bmove_upp.lo ext/mysql/libmysql/longlong2str.lo ext/mysql/libmy
#22346 [NoF->Asn]: Make fails: more undefined references to errno
ID: 22346 Updated by: [EMAIL PROTECTED] Reported By: erwthijs at hotmail dot com -Status: No Feedback +Status: Assigned Bug Type: MySQL related Operating System: Linux Red Hat 8.0 PHP Version: 4.3.2-dev -Assigned To: +Assigned To: zak New Comment: Will be fixed as soon as I can get the CVS checkout to build. :) Previous Comments: [2003-03-21 10:13:31] ciano at borgosatollo dot it Ok, I fixed somehow the problem and got this compiled. I had to add the "#include " in the follwings files: php-4.3.1/ext/mysql/libmysql/my_lib.c php-4.3.1/ext/mysql/libmysql/my_malloc.c php-4.3.1/ext/mysql/libmysql/my_tempnam.c php-4.3.1/ext/mysql/libmysql/my_realloc.c php-4.3.1/ext/mysql/libmysql/my_delete.c php-4.3.1/ext/mysql/libmysql/my_error.c php-4.3.1/ext/mysql/libmysql/my_getwd.c php-4.3.1/ext/mysql/libmysql/my_once.c This seams to let me get to the end still haveing this warning: /home/lucio/php/php-4.3.1/ext/mysql/libmysql/my_tempnam.c:104: the use of `tempnam' is dangerous, better use `mkstemp' but i didn't change the sources further. [2003-03-21 09:57:50] ciano at borgosatollo dot it (sorry for the other post but I dind't find this one before) I'm compiling with this configure: "./configure --enable-calendar --with-zlib --with-bz2 --enable-ftp --with-ttf --with-mysql --with-mysql-sock --with-pgsql --enable-sockets --with-apxs2=/usr/local/apache2/bin/apxs" on a mdk9.0 and gcc 3.2.2 /bin/sh libtool --silent --mode=link gcc -export-dynamic -g -O2 -avoid-version -module ext/zlib/zlib.lo ext/zlib/zlib_fopen_wrapper.lo ext/bz2/bz2.lo ext/calendar/calendar.lo ext/calendar/dow.lo ext/calendar/french.lo ext/calendar/gregor.lo ext/calendar/jewish.lo ext/calendar/julian.lo ext/calendar/easter.lo ext/calendar/cal_unix.lo ext/ctype/ctype.lo ext/ftp/php_ftp.lo ext/ftp/ftp.lo ext/mysql/php_mysql.lo ext/mysql/libmysql/libmysql.lo ext/mysql/libmysql/errmsg.lo ext/mysql/libmysql/net.lo ext/mysql/libmysql/violite.lo ext/mysql/libmysql/password.lo ext/mysql/libmysql/my_init.lo ext/mysql/libmysql/my_lib.lo ext/mysql/libmysql/my_static.lo ext/mysql/libmysql/my_malloc.lo ext/mysql/libmysql/my_realloc.lo ext/mysql/libmysql/my_create.lo ext/mysql/libmysql/my_delete.lo ext/mysql/libmysql/my_tempnam.lo ext/mysql/libmysql/my_open.lo ext/mysql/libmysql/mf_casecnv.lo ext/mysql/libmysql/my_read.lo ext/mysql/libmysql/my_write.lo ext/mysql/libmysql/errors.lo ext/mysql/libmysql/my_error.lo ext/mysql/libmysql/my_getwd.lo ext/mysql/libmysql/my_div.lo ext/mysql/libmysql/mf_pack.lo ext/mysql/libmysql/my_messnc.lo ext/mysql/libmysql/mf_dirname.lo ext/mysql/libmysql/mf_fn_ext.lo ext/mysql/libmysql/mf_wcomp.lo ext/mysql/libmysql/typelib.lo ext/mysql/libmysql/safemalloc.lo ext/mysql/libmysql/my_alloc.lo ext/mysql/libmysql/mf_format.lo ext/mysql/libmysql/mf_path.lo ext/mysql/libmysql/mf_unixpath.lo ext/mysql/libmysql/my_fopen.lo ext/mysql/libmysql/mf_loadpath.lo ext/mysql/libmysql/my_pthread.lo ext/mysql/libmysql/my_thr_init.lo ext/mysql/libmysql/thr_mutex.lo ext/mysql/libmysql/mulalloc.lo ext/mysql/libmysql/string.lo ext/mysql/libmysql/default.lo ext/mysql/libmysql/my_compress.lo ext/mysql/libmysql/array.lo ext/mysql/libmysql/my_once.lo ext/mysql/libmysql/list.lo ext/mysql/libmysql/my_net.lo ext/mysql/libmysql/dbug.lo ext/mysql/libmysql/strmov.lo ext/mysql/libmysql/strxmov.lo ext/mysql/libmysql/strnmov.lo ext/mysql/libmysql/strmake.lo ext/mysql/libmysql/strend.lo ext/mysql/libmysql/strfill.lo ext/mysql/libmysql/is_prefix.lo ext/mysql/libmysql/int2str.lo ext/mysql/libmysql/str2int.lo ext/mysql/libmysql/strinstr.lo ext/mysql/libmysql/strcont.lo ext/mysql/libmysql/strcend.lo ext/mysql/libmysql/bchange.lo ext/mysql/libmysql/bmove.lo ext/mysql/libmysql/bmove_upp.lo ext/mysql/libmysql/longlong2str.lo ext/mysql/libmysql/strtoull.lo ext/mysql/libmysql/strtoll.lo ext/mysql/libmysql/charset.lo ext/mysql/libmysql/ctype.lo ext/overload/overload.lo ext/pcre/pcrelib/maketables.lo ext/pcre/pcrelib/get.lo ext/pcre/pcrelib/study.lo ext/pcre/pcrelib/pcre.lo ext/pcre/php_pcre.lo ext/pgsql/pgsql.lo ext/posix/posix.lo ext/session/session.lo ext/session/mod_files.lo ext/session/mod_mm.lo ext/session/mod_user.lo ext/sockets/sockets.lo ext/standard/array.lo ext/standard/base64.lo ext/standard/basic_functions.lo ext/standard/browscap.lo ext/standard/crc32.lo ext/standard/crypt.lo ext/standard/cyr_convert.lo ext/standard/datetime.lo ext/standard/dir.lo ext/standard/dl.lo ext/standard/dns.lo ext/standard/exec.lo ext/standard/file.lo ext/standard/filestat.lo ext/standard/flock_compat.lo ext/standard/formatted_print.lo ext/standard/fsock.lo ext/standard/head.lo ext/standard/html.lo ext/standard/image.lo ext/standard/info.lo ext/standard/iptc.lo ext/standard/lcg.lo ext/standard/link.lo ext/standard/mail.lo
#21537 [Bgs]: Need function parameters as entered
ID: 21537
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Feature/Change Request
Operating System: inux, Solaris, NT, Win2000
PHP Version: 4.3.0
New Comment:
Hi Peter,
One minor note here. The first argument is not converted
to type integer. Rather, it is trimmed of non-numerically
significant zeros.
function xxx($a,$b){
var_dump($a,$b);
}
xxx(2.0, "2.0");
Outputs:
float(2)
string(3) "2.0"
The type of the value is still float.
This behaviour might be difficult to change, considering
that it happens in all contexts - not just when formal
parameters are passed to a function.
$a = 2.0;
var_dump($a);
var_dump(2.0);
Outputs:
float(2);
float(2);
Cheers!
Previous Comments:
[2003-01-09 16:22:17] [EMAIL PROTECTED]
$a = 2.0;
$b = '2.0';
xxx($a, $b);
produces
2 2.0
2.0 is still converted to int(2) instead of float(2.0).
I need to know the exact input and thought the easiest way to check the
input would be to get the input as an unconverted string.
In the example of 2.0, a float of 2.0 would tell me the type and
accuracy. I would then get 3.10 as 3.10 instead of 3.1.
I have not tested floats with e notation or very long numbers. If
someone types a long number, I want to detect the long number,
recognise the number exceeds the accuracy of the default maths, and
switch to arbitrary precision mathematics.
I do not want to tell the person using my function or class, a whole
lot of rules about enclosing numbers in quotations when they contain
certain values.
[2003-01-09 00:48:35] [EMAIL PROTECTED]
You must be doing something else wrongly:
[derick@kossu derick]$ php bug21537.php
float(1)
float(1.8)
As you see it works fine...
Derick
[2003-01-08 22:04:12] [EMAIL PROTECTED]
When I write a function as
xxx(1.0, 1.8);
The function receives 1 and 1.8, not 1.0 and 1.8. I tried
get_func_arg() and other tricks but the 1.0 is converted to int(1)
before it available for processing.
Could we have a language construct named:
get_func_arg_untouched_virginal_string_as_entered()
which keeps the parameter as a string?
I need to keep some numeric data in the original input format so it can
be verified as typed and passed to other systems in the original
format.
--
Edit this bug report at http://bugs.php.net/?id=21537&edit=1
#20374 [Opn->Csd]: Performance enhancment for php_mysql_do_connect.
ID: 20374
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: Feature/Change Request
Operating System: Linux
PHP Version: 4.2.2
-Assigned To:
+Assigned To: zak
New Comment:
Thanks for the excellent and complete suggestion - it has been
implemented in CVS.
Previous Comments:
[2002-11-11 17:45:38] [EMAIL PROTECTED]
While investigating server performance I noticed that my queries per
second was unusually high, as well as my SHOW STATUS commands in MySQL.
After investigating through the source, I found the function
php_mysql_do_connect, which of course does connections. Within there,
line 602 of php_mysql.c for 4.2.2, I found a mysql_stat() where the
MySQL connection was tested, and upon failure would reconnect. My
suggestion for PHP, and what I am placing into my own source, is
instead of a mysql_stat, a mysql_ping is ran, if the API library is
above 3.22.3
(http://www.mysql.com/documentation/mysql/bychapter/index.html#News-3.22.3)
Per the MySQL documentation:
http://www.mysql.com/documentation/mysql/bychapter/manual_Clients.html#mysql_ping
int mysql_ping(MYSQL *mysql)
8.4.3.164 Description
Checks whether the connection to the server is working. If it has gone
down, an automatic reconnection is attempted.
This function can be used by clients that remain idle for a long while,
to check whether the server has closed the connection and reconnect if
necessary.
8.4.3.165 Return Values
Zero if the server is alive. Non-zero if an error occurred.
Since the libmysqlclient API will already reconnect, there is no need
for PHP to do this internally. If the API version is equal to or above
3.22.3, run a mysql_ping and upon failure, remove the connection from
the zend_hash and return failure. If it is below 3.22.3 (which is 3
years old), run the old source. I know this is not a huge change, but
it does make alittle difference in performance. Below is a test.c
example of how this functions:
#include
#include
#include
#include
int main (void) {
MYSQL mysql_connect;
MYSQL_RES *mysql_result;
MYSQL_ROW mysql_row;
my_ulonglong id;
int c;
mysql_init(&mysql_connect);
mysql_real_connect(&mysql_connect,"localhost","root","inT99hB$",
"mysql", 0, NULL, 0);
for (c = 0; c < 3; c++) {
sleep(2);
mysql_ping(&mysql_connect);
printf("Error: %s\n", mysql_error(&mysql_connect));
if (mysql_real_query(&mysql_connect,"SELECT
CONNECTION_ID()",sizeof("SELECT CONNECTION_ID()"))) {
printf("Error querying: %s\n",
mysql_error(&mysql_connect));
} else {
mysql_result =
mysql_store_result(&mysql_connect);
mysql_row = mysql_fetch_row(mysql_result);
id = strtoul(mysql_row[0], NULL, 0);
mysql_free_result(mysql_result);
printf("Id is %lu\n", id);
mysql_kill(&mysql_connect, id);
}
}
}
Example of php_mysql.c
#if MYSQL_VERSION_ID > 32230 /* let mysql_ping check connection and
auto reconnect */
if(mysql_ping(le->ptr)) {
php_error(E_WARNING, "MySQL: Link to
server lost, unable to reconnect");
zend_hash_del(&EG(persistent_list),
hashed_details, hashed_details_length+1);
efree(hashed_details);
MYSQL_DO_CONNECT_RETURN_FALSE();
}
#else
... normal code...
#endif
Bests,
nickg
--
Edit this bug report at http://bugs.php.net/?id=20374&edit=1
#19529 [Asn]: Occational "Commands out of sync" errors
ID: 19529 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Assigned Bug Type: MySQL related Operating System: Linux 2.4.18 PHP Version: 4.2.3 Assigned To: georg New Comment: 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. Previous Comments: [2002-10-10 15:03:07] [EMAIL PROTECTED] reassigning [2002-10-10 13:07:13] [EMAIL PROTECTED] 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] [EMAIL PROTECTED] 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] [EMAIL PROTECTED] 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? [2002-10-09 08:01:40] [EMAIL PROTECTED] A possible fix (based on discussions between Rasmus and the MySQL team) has just been committed to CVS. If the fix works praise Rasmus, if it fails, blame me! :) Please try the latest CVS version and see if the bug can be reproduced. Also, regarding the connect_timeout tests. If connect_timeout is set to -1, then we want to rely on the MySQL settings for this option, rather than attempting to override the option with a value set in PHP. 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
#19529 [Ana->Fbk]: Occational "Commands out of sync" errors
ID: 19529
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Analyzed
+Status: Feedback
Bug Type: MySQL related
Operating System: Linux 2.4.18
PHP Version: 4.2.3
Assigned To: georg
New Comment:
A possible fix (based on discussions between Rasmus and the MySQL team)
has just been committed to CVS. If the fix works praise Rasmus, if it
fails, blame me! :)
Please try the latest CVS version and see if the bug can be
reproduced.
Also, regarding the connect_timeout tests. If connect_timeout is set to
-1, then we want to rely on the MySQL settings for this option, rather
than attempting to override the option with a value set in PHP.
Previous Comments:
[2002-10-09 02:56:39] [EMAIL PROTECTED]
I think the real problem here is the order things happen in. A
ROLLBACK or an AUTOCOMMIT query do not return a result set and thus do
not need to be dealt with as you describe here. It is more likely that
there is an existing result set that has not be explicitly freed in the
PHP script and the PHP destructor for that result set is being called
after the call to restore_connection_default. That's when you would
get an out-of-sync error because the ROLLBACK is called with an
outstanding result set.
So, for those of you experiencing this problem, try explicitly calling
mysql_free_result() on your result sets.
[2002-10-08 21:10:15] [EMAIL PROTECTED]
MySQL is complaining about things not being cleaned up. This is because
any query that returns results (which one's don't -- any?) must get
them.
In case of an unbuffered query, we need to eat the rest of the rows
before exiting (like we do when a new query is run when an old
unbuffered query was not finished). I removed the warning in this case,
but you all can change it as you please.
The case that is hitting me (and EVERYONE out there using persistent
connections with current revs) is that there is a rollback. But there
is nothing to get the results of the rollback. This means, that the
next script to use this persistent connection will generally fail on
the first query, but might do alright on the others. For this reason, I
recommend anyone use PHP 4.2.3 (maybe earlier versions as well) to turn
off persistent connections for now.
Also, in CVS there is something to reset AUTOCOMMIT. It also did not
clean up and that causes additional issues. I removed it rather than
fixed it. Who says AUTOCOMMIT=1 should be the default for a certain
server? That is user configurable on the server side. Personally, I
like the idea of resetting all the variables that might have been
changed (including that one). There are a lot. No good way to do it
right now.
Oh, what else? Ah.. the code in CVS for mysql.connection.timeout. That
rocks! However, it sets the default to zero and then checks for -1 as a
sign not to include the option. Oops. So the default timeout value is
set to nothing when the user doesn't do anything. That is a
unpredictable change in behavior.
I have some changes below. My first time even looking at this code, so
look for any mistakes.
static int _restore_connection_defaults(zend_rsrc_list_entry *rsrc
TSRMLS_DC)
{
php_mysql_conn *link;
charquery[128];
charuser[128];
charpasswd[128];
/* check if its a persistent link */
if (Z_TYPE_P(rsrc) != le_plink)
return 0;
link = (php_mysql_conn *) rsrc->ptr;
if (link->active_result_id) do {
int type;
MYSQL_RES *mysql_result;
mysql_result = (MYSQL_RES *)
zend_list_find(link->active_result_id, &type);
if (mysql_result && type==le_result) {
if (!mysql_eof(mysql_result)) {
while (mysql_fetch_row(mysql_result));
}
zend_list_delete(link->active_result_id);
link->active_result_id = 0;
}
} while(0);
/* rollback possible transactions */
strcpy (query, "ROLLBACK");
if (mysql_real_query(&link->conn, query, strlen(query)) !=0 ) {
MYSQL_RES *mysql_result=mysql_store_result(&link->conn);
mysql_free_result(mysql_result);
}
/* unset the current selected db */
#if MYSQL_VERSION_ID > 32329
strcpy (user, (char *)(&link->conn)->user);
strcpy (passwd, (char *)(&link->conn)->passwd);
mysql_change_user(&link->conn, user, passwd, "");
#endif
return 0;
}
And change the two copies of this:
if (connect_timeout != -1)
to
if (connect_timeout <= 0)
My 2 cents for the day.
[2002-10-07 07:02:42] [EMAIL PROTECTED]
Removing the ROLLBACK seems to have fixed the problem for me too.
Reading the MySQL docs on the error message in question, it wo
#15375 [Csd->Opn]: safe_mode wrappers fail for MySQL (other exts?)
ID: 15375 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Closed +Status: Open Bug Type: MySQL related Operating System: All PHP Version: 4.1.1 Assigned To: zak New Comment: I should re-examine this one as well. Previous Comments: [2002-02-10 14:18:35] [EMAIL PROTECTED] A fix for this behavior should appear within the next few releases of the MySQL 4.0.x series. I will update this bug when the fix is implemented. [2002-02-05 12:24:48] [EMAIL PROTECTED] I generally agree on Rasmus' feedback on the issue, so i'll leave it closed. However, since this naturally works with remote mysql-servers, setting up a server where you have the create-permission isnt really much of a hazzle. [2002-02-05 10:15:39] [EMAIL PROTECTED] It works even if you are connecting to remote mysql server over tcp/ip, so I don't think this is only mysql related issue. [2002-02-05 09:53:36] [EMAIL PROTECTED] Verified that the exploit allows any file readable by the MySQL server to be viewed via this technique. Note that forbidding the MySQL user CREATE permission does make the exploit less convenient for the attacker. The MySQL dev team is looking at ways to reduce this risk via MySQL permission behavior in the server. Given Rasmus' feedback on the issue, I am closing this as a PHP bug. Hopefully, the MySQL dev team should be able eliminate or reduce this risk. If we can't completely resolve it, I will re-examine this bug. --zak@[mysql|php].com [2002-02-05 09:53:11] [EMAIL PROTECTED] Verified that the exploit allows any file readable by the MySQL server to be viewed via this technique. Note that forbidding the MySQL user CREATE permission does make the exploit less convenient for the attacker. The MySQL dev team is looking at ways to reduce this risk via MySQL permission behavior in the server. Given Rasmus' feedback on the issue, I am closing this as a PHP bug. Hopefully, the MySQL dev team should be able eliminate or reduce this risk. If we can't completely resolve it, I will re-examine this bug. --zak@[mysql|php].com 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/15375 -- Edit this bug report at http://bugs.php.net/?id=15375&edit=1
#11993 [Csd->Opn]: mysql_close closes incorrect db handler
ID: 11993 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Closed +Status: Open Bug Type: MySQL related Operating System: Debian 2.19 PHP Version: 4.1.0 Assigned To: zak New Comment: I need to check out how this behaves in the current CVS Previous Comments: [2002-07-10 05:18:52] [EMAIL PROTECTED] If you want to have always a new link, specify the optional parameter new_link, which is implemented since version 4.2.0. See also: http://www.php.net/manual/en/function.mysql-connect.php [2001-12-31 19:15:55] [EMAIL PROTECTED] doh. [2001-12-31 18:56:34] [EMAIL PROTECTED] I will take a look at this. [2001-12-13 11:13:44] [EMAIL PROTECTED] sorry, i can not try with php4.1.0RC3. I tried out with the latest php4.1.0, and no changes, the problem still exists. ati [2001-12-13 06:26:24] [EMAIL PROTECTED] No feedback. Closing. 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/11993 -- Edit this bug report at http://bugs.php.net/?id=11993&edit=1
#14860 [NoF->Asn]: PHP segfault in mysql driver
ID: 14860 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: No Feedback +Status: Assigned Bug Type: MySQL related Operating System: Solaris 8 PHP Version: 4.1.1 -Assigned To: +Assigned To: zak New Comment: Assigning all open mysql bugs to myself for 4.3 QA cycle. Previous Comments: [2002-08-08 01:00:13] [EMAIL PROTECTED] No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2002-07-07 22:05:24] [EMAIL PROTECTED] This should be fixed in CVS, so please try this snapshot: http://snaps.php.net/php4-latest.tar.gz [2002-04-03 14:25:35] [EMAIL PROTECTED] This bug may be related to #16272. Ronen. [2002-02-28 14:20:49] [EMAIL PROTECTED] We've had the same exact problem - specifically with mysql_fetch_array(), and with the exact same symptoms. Not predictable, random occurance, etc'. We're running PHP 4.1.1 as a static build for Apache 1.3.22 on RedHat Linux 6.1. MySQL version is 3.23.42 [2002-01-12 09:25:24] [EMAIL PROTECTED] I'am having the same problem using apache2 and latest cvs. I see that ext/mysql/libmysql/ is always compiled with #define UNDEF_THREADS_HACK so producing a non thread safe mysql builtin library. Not using the builtin libmysql this problem is solved. Don't know if it's the same for win32 builds. I also noticed that build this libmysql the debug code is not turned off definig DBUG_OFF (?), is this intented ? 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/14860 -- Edit this bug report at http://bugs.php.net/?id=14860&edit=1
#19179 [Fbk]: select doesn't work properly
ID: 19179 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: MySQL related Operating System: Win XP Pro PHP Version: 4.2.2 -Assigned To: +Assigned To: zak New Comment: Assigning all open mysql bugs to myself for 4.3 QA cycle. Previous Comments: [2002-08-29 17:28:07] [EMAIL PROTECTED] Could you please send a short script, your configuration options and a table description/dump to [EMAIL PROTECTED]?! [2002-08-29 16:39:34] [EMAIL PROTECTED] I've got problems doing a select statement like "select * from sets where group1 = 'private'". If trying to get more than about 50 rows, php throws out some correct results, but some weird characters too. The same statement works in mysql-console. All fields are escaped. The bug is reproducable, but always gives other results. Sometimes I had to assume, that php opened some files in same directory, but i never did a file open in that script. For further information I could send you my script and a dump of my database. -- Edit this bug report at http://bugs.php.net/?id=19179&edit=1
#16906 [Asn]: Warning: MySQL: Unable to save result set in ...
ID: 16906 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Assigned Bug Type: MySQL related Operating System: FreeBSD PHP Version: 4.1.2, 4.2.0 -Assigned To: cynic +Assigned To: zak New Comment: Assigning all open mysql bugs to myself for 4.3 release. Previous Comments: [2002-07-23 15:51:18] [EMAIL PROTECTED] I've got the same error on the webserver of my hosting provider (Linux 2.4.13) using PHP 4.2.2 when updating/inserting records to MySQL (client 3.23.39). Also a simple select of all records (approx. 3750 records, 479Kb in total as line-delimited text) Anyone got an idea how to solve this? If you respond, please connect computer and creations in my emailaddress. [2002-07-02 14:53:17] [EMAIL PROTECTED] umm, I should've added that I've encountered something like this just yesterday with 4.1.2/1.3.24, 4.2.1/1.3.24 and 4.2.1/1.3.26, but that was on RH 7.2. and the error mesage was different. all updates from php were corrupting the tables. updates from mysql(1) were ok. eventually it got fixed by dumping, dropping, and recreating the table. but that's probably completely unrelated. [2002-07-02 14:32:40] [EMAIL PROTECTED] this works with 4.3.0-dev, I'll have to try 4.2.1 tomorrow. roman@freepuppy ~/install/php4 > cat ./config.nice.cli+apxs 192:0 #! /bin/sh # # Created by configure './configure' \ '--enable-cli' \ '--enable-inline-optimization' \ '--enable-ftp' \ '--enable-shmop' \ '--enable-sysvsem' \ '--enable-sysvshm' \ '--enable-sockets' \ '--enable-tokenizer' \ '--disable-session' \ '--disable-shared' \ '--with-apxs=/usr/local/sbin/apxs' \ '--with-openssl' \ '--with-zlib' \ '--with-bz2' \ '--with-curl' \ '--with-gettext' \ '--with-iconv' \ '--with-mcrypt=/usr/local' \ '--with-mhash=/usr/local' \ '--with-ncurses' \ '--with-readline' \ '--with-pear' \ '--with-config-file-path=/usr/local/etc' \ '--with-mysql=/usr/local' \ "$@" Query, executed directly in mysql, works. [2002-05-02 06:34:30] [EMAIL PROTECTED] Please add SHORT but complete example script to this report which can be used to reproduce this. --Jani 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/16906 -- Edit this bug report at http://bugs.php.net/?id=16906&edit=1
Bug #14431 Updated: my_getwd.c:62: #error "No way to get current directory"
ID: 14431 Updated by: [EMAIL PROTECTED] -Summary: my_getwd.c:62: #error "No way to get current directory" Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Compile Failure Operating System: Solaris8 PHP Version: 4.1.0 -Assigned To: +Assigned To: zak Previous Comments: [2001-12-11 13:08:24] [EMAIL PROTECTED] This one seems to be similar to bug id 10269. Could someone assist me in working this out? ./configure \ --with-expat-dir=/usr/local \ --with-sablot=/usr/local \ --enable-xslt \ --with-xslt-sablot \ --with-openssl=/usr/local/ssl \ --with-curl=/opt \ --with-ldap=/usr/local \ --with-mysql \ --with-nsapi=/usr/netscape/server4 \ --with-iconv=/usr/local Making all in Zend Making all in main Making all in ext Making all in curl Making all in iconv Making all in ldap Making all in mysql Making all in libmysql /bin/sh /usr/software/php4/php-4.1.0/libtool --silent --mode=compile /usr/software/php4/php-4.1.0/meta_ccld -I. -I/usr/software/php4/php-4.1.0/ext/mysql/libmysql -I/usr/software/php4/php-4.1.0/main -I/usr/software/php4/php-4.1.0 -I/usr/netscape/server4/plugins/include -I/usr/software/php4/php-4.1.0/Zend -I/usr/local/ssl/include -I/opt/include -I/usr/local/include -I/usr/software/php4/php-4.1.0/ext/mysql/libmysql -D_POSIX_PTHREAD_SEMANTICS -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -I/usr/software/php4/php-4.1.0/TSRM -DTHREAD=1 -g -O2 -pthreads -DZTS -prefer-pic -c my_getwd.c my_getwd.c:62: #error "No way to get current directory" *** Error code 1 make: Fatal error: Command failed for target `my_getwd.lo' Current working directory /usr/software/php4/php-4.1.0/ext/mysql/libmysql *** Error code 1 make: Fatal error: Command failed for target `all-recursive' Current working directory /usr/software/php4/php-4.1.0/ext/mysql/libmysql *** Error code 1 make: Fatal error: Command failed for target `all-recursive' Current working directory /usr/software/php4/php-4.1.0/ext/mysql *** Error code 1 make: Fatal error: Command failed for target `all-recursive' Current working directory /usr/software/php4/php-4.1.0/ext *** Error code 1 make: Fatal error: Command failed for target `all-recursive' -- Edit this bug report at http://bugs.php.net/?id=14431&edit=1
Bug #15739 Updated: include recursive bug
ID: 15739 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Unknown/Other Function Operating System: windows 2000 PHP Version: 4.1.1 New Comment: 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 Previous Comments: [2002-02-26 17:20:50] [EMAIL PROTECTED] //code of file 1.php Execution will result in stack overflow in apache php4ts.dll Apache 1.3+php 4.1.1 -- Edit this bug report at http://bugs.php.net/?id=15739&edit=1
Bug #15737 Updated: isset() dont work with $str[$index]
ID: 15737 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus -Bug Type: Compile Warning +Bug Type: Strings related Operating System: Win32 / Linux PHP Version: 4.1.1 New Comment: The issues is not isset(). PHP generates an warning when attempting to access a string subscript that does not exist. If the level error reporting is set to E_ALL, this warning will be generated. A better way to do this would be to use strlen(). Previous Comments: [2002-02-26 13:52:05] [EMAIL PROTECTED] works fine on 4.0.6; 4.1.1 (linux and win32) announces "Uninitialized string offset on line 6..." -- Edit this bug report at http://bugs.php.net/?id=15737&edit=1
Bug #15375 Updated: safe_mode wrappers fail for MySQL (other exts?)
ID: 15375 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: MySQL related Operating System: All PHP Version: 4.1.1 Assigned To: zak New Comment: A fix for this behavior should appear within the next few releases of the MySQL 4.0.x series. I will update this bug when the fix is implemented. Previous Comments: [2002-02-05 12:24:48] [EMAIL PROTECTED] I generally agree on Rasmus' feedback on the issue, so i'll leave it closed. However, since this naturally works with remote mysql-servers, setting up a server where you have the create-permission isnt really much of a hazzle. [2002-02-05 10:15:39] [EMAIL PROTECTED] It works even if you are connecting to remote mysql server over tcp/ip, so I don't think this is only mysql related issue. [2002-02-05 09:53:36] [EMAIL PROTECTED] Verified that the exploit allows any file readable by the MySQL server to be viewed via this technique. Note that forbidding the MySQL user CREATE permission does make the exploit less convenient for the attacker. The MySQL dev team is looking at ways to reduce this risk via MySQL permission behavior in the server. Given Rasmus' feedback on the issue, I am closing this as a PHP bug. Hopefully, the MySQL dev team should be able eliminate or reduce this risk. If we can't completely resolve it, I will re-examine this bug. --zak@[mysql|php].com [2002-02-05 09:53:11] [EMAIL PROTECTED] Verified that the exploit allows any file readable by the MySQL server to be viewed via this technique. Note that forbidding the MySQL user CREATE permission does make the exploit less convenient for the attacker. The MySQL dev team is looking at ways to reduce this risk via MySQL permission behavior in the server. Given Rasmus' feedback on the issue, I am closing this as a PHP bug. Hopefully, the MySQL dev team should be able eliminate or reduce this risk. If we can't completely resolve it, I will re-examine this bug. --zak@[mysql|php].com [2002-02-05 06:22:51] [EMAIL PROTECTED] Humility is a dish best served lukewarm... I should have read more carefully. :) While Rasmus has spoken on this issue, but I will take a closer look at it tomorrow. 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/15375 -- Edit this bug report at http://bugs.php.net/?id=15375&edit=1
