#35160 [Bgs]: openssl 0.9.8a + module does not load any ciphers
ID: 35160 User updated by: beckman at purplecow dot com Reported By: beckman at purplecow dot com Status: Bogus Bug Type: OpenSSL related Operating System: FreeBSD 5.3-RELEASE-p10 PHP Version: 5CVS-2005-11-09 (snap) New Comment: It seems my other posts are no longer here... I can't disagree that my bug doesn't imply a problem with PHP itself, but I was hoping that someone could say this is a bug with OpenSSL and NOT PHP not just that it works fine. I grabbed the 200511182130 snapshot with OpenSSL 0.9.8a. During make: /usr/home/beckman/tmp/php5-200511182130/ext/openssl/openssl.c: In function `php_openssl_x509_from_zval': /usr/home/beckman/tmp/php5-200511182130/ext/openssl/openssl.c:770: warning: passing arg 1 of `PEM_ASN1_read_bio' from incompatible pointer type Then after it built, I tried to run it again: ~/tmp/php5-200511182130/sapi/cli -- ./php ?php file_get_contents(https://www.katazo.com/secure/checkout/;); ^D Warning: file_get_contents(): failed to create an SSL context in /usr/home/beckman/tmp/php5-200511182130/sapi/cli/- on line 2 Warning: file_get_contents(): Failed to enable crypto in /usr/home/beckman/tmp/php5-200511182130/sapi/cli/- on line 2 Warning: file_get_contents(https://www.katazo.com/secure/checkout/): failed to open stream: Operation now in progress in /usr/home/beckman/tmp/php5-200511182130/sapi/cli/- on line 2 Excerpts from My PHP -i: phpinfo() PHP Version = 5.1.0RC7-dev System = FreeBSD web2.762corp.com 5.4-RELEASE FreeBSD 5.4-RELEASE #0: Sun May 8 10:21:06 UTC 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 Build Date = Nov 18 2005 17:57:35 Configure Command = './configure' '--enable-versioning' '--enable-memory-limit' '--with-layout=GNU' '--with-config-file-scan-dir=/usr/local/etc/php' '--enable -libxml' '--with-libxml-dir=/usr/local' '--enable-spl' '--with-regex=php' '--with-apxs=/usr/local/sbin/apxs' '--prefix=/usr/local' '--with-openssl=/usr/local/ss l' 'i386-portbld-freebsd5.3' Server API = Command Line Interface ... Registered PHP Streams = php, file, http, ftp, https, ftps Registered Stream Socket Transports = tcp, udp, unix, udg, ssl, sslv3, sslv2, tls openssl OpenSSL support = enabled OpenSSL Version = OpenSSL 0.9.8a 11 Oct 2005 Is this a problem with PHP + OpenSSL 0.9.8a (since 0.9.7i works fine) or is this an OpenSSL 0.9.8a bug? Also, when you said works fine did you mean compiles fine or did you mean I compiled 0.9.8a from source + php RC5 from source and then opened an HTTPS URL and got the contents successfully? Previous Comments: [2005-11-17 16:41:13] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Works fine on fresh build on openssl 0.9.8a and PHP 5.1.0RC5. The original message on the debian list seems to imply the problem is on some pre-compiled openssl builds. Not a PHP bug. [2005-11-09 00:19:19] beckman at purplecow dot com Code to generate errors: file_get_contents(https://some.secure.site.com/;); echo openssl_error_string(); BTW, this string, returned from openssl_error_string(): error:140A90A1:SSL routines:func(169):reason(161) Reason 161 is Library has no ciphers returned from SSL_CTX_new. Here's my layman's thought: line 348 of ext/openssl/xp_ssl.c calls SSL_CTX_new(method) Nowhere before this is SSL_library_init() called, as per documentation on openssl.org: http://www.openssl.org/docs/ssl/SSL_library_init.html Confusingly the documentation also says that SSL_CTX_new() will load the ciphers: http://www.openssl.org/docs/ssl/SSL_CTX_new.html Though it seems that in 0.9.8a it does not. In ssl/ssl_algs.c you see that SSL_library_init() is changed a bit, and in 0.9.8a calls ssl_load_ciphers() (defined on line 168 of ssl/ssl_ciph.c) which doesn't exist in 0.9.7i. I can't tell if this is a fundamental change in OpenSSL that you have to add a function call to the openssl extension in PHP, or if OpenSSL screwed something up. My guess is that OpenSSL changed the way they load ciphers, and that the OpenSSL extension needs to be changed to do so. Granted, the OpenSSL site isn't great at documentation.. [2005-11-08 22:14:39] beckman at purplecow dot com Description: Using FreeBSD ports tree, I installed openssl 0.9.8a and php5-openssl, which installed the openssl libraries and tools and the php5 openssl
#35160 [NEW]: openssl 0.9.8a + module does not load any ciphers
From: beckman at purplecow dot com Operating system: FreeBSD 5.3-RELEASE-p10 PHP version: 5.0.5 PHP Bug Type: OpenSSL related Bug description: openssl 0.9.8a + module does not load any ciphers Description: Using FreeBSD ports tree, I installed openssl 0.9.8a and php5-openssl, which installed the openssl libraries and tools and the php5 openssl extension openssl.so. After confirming the HTTPS/SSL contexts (streams and transports) were enabled, and OpenSSL support was enabled, I attempted to use file_get_contents to open an HTTPS:// url. This resulted in the following PHP errors: [08-Nov-2005 14:28:10] PHP Warning: file_get_contents(): failed to create an SSL context in /usr/local/lib/php/762dev/functions.inc on line 576 [08-Nov-2005 14:28:10] PHP Warning: file_get_contents(): Failed to enable crypto in /usr/local/lib/php/762dev/functions.inc on line 576 [08-Nov-2005 14:28:10] PHP Warning: file_get_contents(https://##.#.com/?user=##passwd=##msisdn=###): failed to open stream: Operation now in progress in /usr/local/lib/php/762dev/functions.inc on line 576 Here's what I got as the error from openssl_error_string(): error:140A90A1:SSL routines:func(169):reason(161) And here's what I read to lead me to believe that the problem is with a change in the way openssl initializes the ciphers: http://lists.alioth.debian.org/pipermail/pkg-openssl-devel/2005-October/000219.html I think that php5-openssl does not call the SSL_library_init() function before starting use of the library. I de-installed openssl.so and the openssl library, re-installed openssl-0.9.7i, re-installed the openssl.so extension/module, and the library now works great from within PHP. Reproduce code: --- echo file_get_contents(https://whatever.com/;); Expected result: The contents of whatever.com. Actual result: -- Errors. [08-Nov-2005 14:28:10] PHP Warning: file_get_contents(): failed to create an SSL context in /usr/local/lib/php/762dev/functions.inc on line 576 [08-Nov-2005 14:28:10] PHP Warning: file_get_contents(): Failed to enable crypto in /usr/local/lib/php/762dev/functions.inc on line 576 [08-Nov-2005 14:28:10] PHP Warning: file_get_contents(https://##.#.com/?user=##passwd=##msisdn=###): failed to open stream: Operation now in progress in /usr/local/lib/php/762dev/functions.inc on line 576 Here's what I got as the error from openssl_error_string(): error:140A90A1:SSL routines:func(169):reason(161) -- Edit bug report at http://bugs.php.net/?id=35160edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=35160r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=35160r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=35160r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=35160r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=35160r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=35160r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=35160r=needscript Try newer version: http://bugs.php.net/fix.php?id=35160r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=35160r=support Expected behavior: http://bugs.php.net/fix.php?id=35160r=notwrong Not enough info: http://bugs.php.net/fix.php?id=35160r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=35160r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=35160r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35160r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=35160r=dst IIS Stability: http://bugs.php.net/fix.php?id=35160r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=35160r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=35160r=float No Zend Extensions: http://bugs.php.net/fix.php?id=35160r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=35160r=mysqlcfg
#35160 [Fbk-Opn]: openssl 0.9.8a + module does not load any ciphers
ID: 35160 User updated by: beckman at purplecow dot com Reported By: beckman at purplecow dot com -Status: Feedback +Status: Open Bug Type: OpenSSL related Operating System: FreeBSD 5.3-RELEASE-p10 PHP Version: 5.0.5 New Comment: Same results, using php5-latest: [08-Nov-2005 17:50:52] PHP Warning: file_get_contents(): failed to create an SSL context in /usr/home/beckman/tmp/php5-200511082130/sapi/cli/- on line 15 [08-Nov-2005 17:50:52] PHP Warning: file_get_contents(): Failed to enable crypto in /usr/home/beckman/tmp/php5-200511082130/sapi/cli/- on line 15 [08-Nov-2005 17:50:52] PHP Warning: file_get_contents(https://#/): failed to open stream: Operation now in progress in /usr/home/beckman/tmp/php5-200511082130/sapi/cli/- on line 15 System = FreeBSD web2.762corp.com 5.4-RELEASE FreeBSD 5.4-RELEASE #0: Sun May 8 10:21:06 UTC 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 Build Date = Nov 8 2005 17:47:38 Configure Command = './configure' '--enable-versioning' '--enable-memory-limit' '--with-layout=GNU' '--with-config-file-scan-dir=/usr/local/etc/php' '--enable -libxml' '--with-libxml-dir=/usr/local' '--enable-spl' '--with-regex=php' '--with-apxs=/usr/local/sbin/apxs' '--prefix=/usr/local' '--with-openssl=/usr/local' ' i386-portbld-freebsd5.3' Registered PHP Streams = php, file, http, ftp, https, ftps Registered Stream Socket Transports = tcp, udp, unix, udg, ssl, sslv3, sslv2, tls openssl OpenSSL support = enabled OpenSSL Version = OpenSSL 0.9.8a 11 Oct 2005 Previous Comments: [2005-11-08 23:25:49] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip And if it doesn't work either, provide a short reproducing script. Note: We do NOT support any ports. [2005-11-08 22:14:39] beckman at purplecow dot com Description: Using FreeBSD ports tree, I installed openssl 0.9.8a and php5-openssl, which installed the openssl libraries and tools and the php5 openssl extension openssl.so. After confirming the HTTPS/SSL contexts (streams and transports) were enabled, and OpenSSL support was enabled, I attempted to use file_get_contents to open an HTTPS:// url. This resulted in the following PHP errors: [08-Nov-2005 14:28:10] PHP Warning: file_get_contents(): failed to create an SSL context in /usr/local/lib/php/762dev/functions.inc on line 576 [08-Nov-2005 14:28:10] PHP Warning: file_get_contents(): Failed to enable crypto in /usr/local/lib/php/762dev/functions.inc on line 576 [08-Nov-2005 14:28:10] PHP Warning: file_get_contents(https://##.#.com/?user=##passwd=##msisdn=###): failed to open stream: Operation now in progress in /usr/local/lib/php/762dev/functions.inc on line 576 Here's what I got as the error from openssl_error_string(): error:140A90A1:SSL routines:func(169):reason(161) And here's what I read to lead me to believe that the problem is with a change in the way openssl initializes the ciphers: http://lists.alioth.debian.org/pipermail/pkg-openssl-devel/2005-October/000219.html I think that php5-openssl does not call the SSL_library_init() function before starting use of the library. I de-installed openssl.so and the openssl library, re-installed openssl-0.9.7i, re-installed the openssl.so extension/module, and the library now works great from within PHP. Reproduce code: --- echo file_get_contents(https://whatever.com/;); Expected result: The contents of whatever.com. Actual result: -- Errors. [08-Nov-2005 14:28:10] PHP Warning: file_get_contents(): failed to create an SSL context in /usr/local/lib/php/762dev/functions.inc on line 576 [08-Nov-2005 14:28:10] PHP Warning: file_get_contents(): Failed to enable crypto in /usr/local/lib/php/762dev/functions.inc on line 576 [08-Nov-2005 14:28:10] PHP Warning: file_get_contents(https://##.#.com/?user=##passwd=##msisdn=###): failed to open stream: Operation now in progress in /usr/local/lib/php/762dev/functions.inc on line 576 Here's what I got as the error from openssl_error_string(): error:140A90A1:SSL routines:func(169):reason(161) -- Edit this bug report at http://bugs.php.net/?id=35160edit=1
#35160 [Opn]: openssl 0.9.8a + module does not load any ciphers
ID: 35160 User updated by: beckman at purplecow dot com Reported By: beckman at purplecow dot com Status: Open Bug Type: OpenSSL related Operating System: FreeBSD 5.3-RELEASE-p10 PHP Version: 5.0.5 New Comment: Code to generate errors: file_get_contents(https://some.secure.site.com/;); echo openssl_error_string(); BTW, this string, returned from openssl_error_string(): error:140A90A1:SSL routines:func(169):reason(161) Reason 161 is Library has no ciphers returned from SSL_CTX_new. Here's my layman's thought: line 348 of ext/openssl/xp_ssl.c calls SSL_CTX_new(method) Nowhere before this is SSL_library_init() called, as per documentation on openssl.org: http://www.openssl.org/docs/ssl/SSL_library_init.html Confusingly the documentation also says that SSL_CTX_new() will load the ciphers: http://www.openssl.org/docs/ssl/SSL_CTX_new.html Though it seems that in 0.9.8a it does not. In ssl/ssl_algs.c you see that SSL_library_init() is changed a bit, and in 0.9.8a calls ssl_load_ciphers() (defined on line 168 of ssl/ssl_ciph.c) which doesn't exist in 0.9.7i. I can't tell if this is a fundamental change in OpenSSL that you have to add a function call to the openssl extension in PHP, or if OpenSSL screwed something up. My guess is that OpenSSL changed the way they load ciphers, and that the OpenSSL extension needs to be changed to do so. Granted, the OpenSSL site isn't great at documentation.. Previous Comments: [2005-11-08 23:53:32] beckman at purplecow dot com Same results, using php5-latest: [08-Nov-2005 17:50:52] PHP Warning: file_get_contents(): failed to create an SSL context in /usr/home/beckman/tmp/php5-200511082130/sapi/cli/- on line 15 [08-Nov-2005 17:50:52] PHP Warning: file_get_contents(): Failed to enable crypto in /usr/home/beckman/tmp/php5-200511082130/sapi/cli/- on line 15 [08-Nov-2005 17:50:52] PHP Warning: file_get_contents(https://#/): failed to open stream: Operation now in progress in /usr/home/beckman/tmp/php5-200511082130/sapi/cli/- on line 15 System = FreeBSD web2.762corp.com 5.4-RELEASE FreeBSD 5.4-RELEASE #0: Sun May 8 10:21:06 UTC 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 Build Date = Nov 8 2005 17:47:38 Configure Command = './configure' '--enable-versioning' '--enable-memory-limit' '--with-layout=GNU' '--with-config-file-scan-dir=/usr/local/etc/php' '--enable -libxml' '--with-libxml-dir=/usr/local' '--enable-spl' '--with-regex=php' '--with-apxs=/usr/local/sbin/apxs' '--prefix=/usr/local' '--with-openssl=/usr/local' ' i386-portbld-freebsd5.3' Registered PHP Streams = php, file, http, ftp, https, ftps Registered Stream Socket Transports = tcp, udp, unix, udg, ssl, sslv3, sslv2, tls openssl OpenSSL support = enabled OpenSSL Version = OpenSSL 0.9.8a 11 Oct 2005 [2005-11-08 23:25:49] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip And if it doesn't work either, provide a short reproducing script. Note: We do NOT support any ports. [2005-11-08 22:14:39] beckman at purplecow dot com Description: Using FreeBSD ports tree, I installed openssl 0.9.8a and php5-openssl, which installed the openssl libraries and tools and the php5 openssl extension openssl.so. After confirming the HTTPS/SSL contexts (streams and transports) were enabled, and OpenSSL support was enabled, I attempted to use file_get_contents to open an HTTPS:// url. This resulted in the following PHP errors: [08-Nov-2005 14:28:10] PHP Warning: file_get_contents(): failed to create an SSL context in /usr/local/lib/php/762dev/functions.inc on line 576 [08-Nov-2005 14:28:10] PHP Warning: file_get_contents(): Failed to enable crypto in /usr/local/lib/php/762dev/functions.inc on line 576 [08-Nov-2005 14:28:10] PHP Warning: file_get_contents(https://##.#.com/?user=##passwd=##msisdn=###): failed to open stream: Operation now in progress in /usr/local/lib/php/762dev/functions.inc on line 576 Here's what I got as the error from openssl_error_string(): error:140A90A1:SSL routines:func(169):reason(161) And here's what I read to lead me to believe that the problem is with a change in the way openssl initializes the ciphers: http://lists.alioth.debian.org/pipermail/pkg-openssl-devel/2005-October/000219.html I think that php5-openssl does not call the SSL_library_init() function before starting use of the library. I de-installed openssl.so and the openssl library, re-installed openssl-0.9.7i, re-installed the openssl.so extension/module, and the library now works great from within PHP. Reproduce code
#25460 [Csd-Bgs]: mysql_list_fields does NOT use link_identifier
ID: 25460
User updated by: beckman at purplecow dot com
Reported By: beckman at purplecow dot com
-Status: Closed
+Status: Bogus
-Bug Type: Documentation problem
+Bug Type: MySQL related
Operating System: FreeBSD 5.0-RELEASE #0
PHP Version: 4.3.3
Assigned To: georg
New Comment:
If your supposition is correct (phpMyAdmin is broken), then why would
mysql_list_fields(crt, assignments) with a currently valid open
link to the database attempt to use the table mysql.assignments? Even
if you give it a link, it uses the mysql database to find the table.
While I'm not a C/C++ programmer, I read the code for that function. I
noticed that ZEND_FETCH_RESOURCE2 was added in 4.0 beta 3, and wonder
if THAT function is somehow causing this obscure occurence of this bug.
Why do I think it is a bug? Because mysql_list_fields DOES work as
advertised in the code I could come up with. HOWEVER, in that specific
example in phpMyAdmin, it does not. I'm wondering if somehow
ZEND_FETCH_RESOURCE2 is returning the wrong mysql-conn that is being
used to connect to the DB and list the fields from a table.
If any connection to a database can be used to read any DB from that
connection, and just before running mysql_list_fields I can do a show
fields from crt.assignments and it works using both a defined
link_resource or leaving it blank (using the currently selected
connection), why would mysql_list_fields(crt, assignments) fail on
the next line?
I swear it isn't bogus. And if it is, I'll buy you a beer or something
and hang my head in shame.
Previous Comments:
[2003-09-10 03:50:39] [EMAIL PROTECTED]
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.
[2003-09-10 03:43:58] [EMAIL PROTECTED]
assigned to myself
[2003-09-10 03:43:08] [EMAIL PROTECTED]
mysql_list_fields is deprecated, use SHOW COLUMNS FROM table
[LIKE 'foo'] instead.
This should be documented in the manual. Reclassified as
documentation bug.
[2003-09-09 15:47:42] [EMAIL PROTECTED]
This works as advertised. phpMyadmin is broken.
[2003-09-09 15:09:16] beckman at purplecow dot com
Description:
Synopsis: mysql_list_fields should ignore the currently selected
database, since the name of the database is clearly being passed to the
function. But the function uses the currently selected database rather
than the database specified in the function.
Evidence:
Using MySQL 4.0.14 and PHP 4.3.3, mysql_list_fields($db, $tbl,
$link_identifier) uses the most recent connection to mysql, not the
connection specified in $link_identifier.
I've tried to reproduce this problem, and the only place I can is in
phpMyAdmin 2.5.4 dev.
It seems that mysql_list_fields ignores the link_identifier it is
passed and uses either DB mysql or uses the most recent connection.
When testing, here's what I did.
In phpMyAdmin, I selected my database, then selected Query.
I now get an error saying #1146 - Table 'mysql.assignments' doesn't
exist.
So I got into the code in db_details_qbe.php. On line 132, this line
occurs:
$fld_results = @PMA_mysql_list_fields($db, $tbl) or
PMA_mysqlDie(PMA_mysql_error(), 'PMA_mysql_list_fields(' . $db . ', ' .
$tbl . ')', FALSE, $err_url);
The function is as this:
function PMA_mysql_list_fields($database_name, $table_name,
$link_identifier = FALSE) {
if ($link_identifier != FALSE) {
return
mysql_list_fields(PMA_convert_charset($database_name),
PMA_convert_charset($table_name), $link_identifier);
} else {
return
mysql_list_fields(PMA_convert_charset($database_name),
PMA_convert_charset($table_name));
}
}
When echo'ed, it was executed as mysql_list_fields(crt,
assignments). So I decided I should try using the link identifier
explicitly.
$fld_results = @PMA_mysql_list_fields($db, $tbl, $userlink) or
PMA_mysqlDie(PMA_mysql_error(), 'PMA_mysql_list_fields(' . $db . ', ' .
$tbl . ')', FALSE, $err_url);
Got the same error. So then I was concerned that $userlink wasn't the
correct link to the database in question. So I did this on line 131:
$r = mysql_query(Show
#25460 [Bgs-Csd]: mysql_list_fields does NOT use link_identifier
ID: 25460 User updated by: beckman at purplecow dot com Reported By: beckman at purplecow dot com -Status: Bogus +Status: Closed Bug Type: MySQL related Operating System: FreeBSD 5.0-RELEASE #0 PHP Version: 4.3.3 Assigned To: georg New Comment: Whoops. Now that you've marked it depreciated, I withdrawal my bug report! I'll get phpMyAdmin to stop using it, and thus this bug goes away. But just for me feeling good, can you not mark it bogus? That makes me feel like less of a man, and much less of a geek... :-) A closed would be so much better. Previous Comments: [2003-09-10 13:00:46] beckman at purplecow dot com If your supposition is correct (phpMyAdmin is broken), then why would mysql_list_fields(crt, assignments) with a currently valid open link to the database attempt to use the table mysql.assignments? Even if you give it a link, it uses the mysql database to find the table. While I'm not a C/C++ programmer, I read the code for that function. I noticed that ZEND_FETCH_RESOURCE2 was added in 4.0 beta 3, and wonder if THAT function is somehow causing this obscure occurence of this bug. Why do I think it is a bug? Because mysql_list_fields DOES work as advertised in the code I could come up with. HOWEVER, in that specific example in phpMyAdmin, it does not. I'm wondering if somehow ZEND_FETCH_RESOURCE2 is returning the wrong mysql-conn that is being used to connect to the DB and list the fields from a table. If any connection to a database can be used to read any DB from that connection, and just before running mysql_list_fields I can do a show fields from crt.assignments and it works using both a defined link_resource or leaving it blank (using the currently selected connection), why would mysql_list_fields(crt, assignments) fail on the next line? I swear it isn't bogus. And if it is, I'll buy you a beer or something and hang my head in shame. [2003-09-10 03:50:39] [EMAIL PROTECTED] 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. [2003-09-10 03:43:58] [EMAIL PROTECTED] assigned to myself [2003-09-10 03:43:08] [EMAIL PROTECTED] mysql_list_fields is deprecated, use SHOW COLUMNS FROM table [LIKE 'foo'] instead. This should be documented in the manual. Reclassified as documentation bug. [2003-09-09 15:47:42] [EMAIL PROTECTED] This works as advertised. phpMyadmin is broken. 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/25460 -- Edit this bug report at http://bugs.php.net/?id=25460edit=1
#25460 [Csd]: mysql_list_fields does NOT use link_identifier
ID: 25460 User updated by: beckman at purplecow dot com Reported By: beckman at purplecow dot com Status: Closed Bug Type: MySQL related Operating System: FreeBSD 5.0-RELEASE #0 PHP Version: 4.3.3 Assigned To: georg New Comment: So are mysql_field_* depreciated as well? Should they be marked as such in the documentation? You might want to put a nice replacement function in the documentation for mysql_list_fields (and other depreciated functions) to allow people to migrate away from mysql_list_fields smoothly and easily without doing trial and error. I haven't yet figured out how to do this while continuing using mysql_field_* functions. mysql_query(SHOW FIELDS FROM db.table) doesn't return the same data in the same format as mysql_list_fields does. Previous Comments: [2003-09-10 13:03:01] beckman at purplecow dot com Whoops. Now that you've marked it depreciated, I withdrawal my bug report! I'll get phpMyAdmin to stop using it, and thus this bug goes away. But just for me feeling good, can you not mark it bogus? That makes me feel like less of a man, and much less of a geek... :-) A closed would be so much better. [2003-09-10 13:00:46] beckman at purplecow dot com If your supposition is correct (phpMyAdmin is broken), then why would mysql_list_fields(crt, assignments) with a currently valid open link to the database attempt to use the table mysql.assignments? Even if you give it a link, it uses the mysql database to find the table. While I'm not a C/C++ programmer, I read the code for that function. I noticed that ZEND_FETCH_RESOURCE2 was added in 4.0 beta 3, and wonder if THAT function is somehow causing this obscure occurence of this bug. Why do I think it is a bug? Because mysql_list_fields DOES work as advertised in the code I could come up with. HOWEVER, in that specific example in phpMyAdmin, it does not. I'm wondering if somehow ZEND_FETCH_RESOURCE2 is returning the wrong mysql-conn that is being used to connect to the DB and list the fields from a table. If any connection to a database can be used to read any DB from that connection, and just before running mysql_list_fields I can do a show fields from crt.assignments and it works using both a defined link_resource or leaving it blank (using the currently selected connection), why would mysql_list_fields(crt, assignments) fail on the next line? I swear it isn't bogus. And if it is, I'll buy you a beer or something and hang my head in shame. [2003-09-10 03:50:39] [EMAIL PROTECTED] 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. [2003-09-10 03:43:58] [EMAIL PROTECTED] assigned to myself [2003-09-10 03:43:08] [EMAIL PROTECTED] mysql_list_fields is deprecated, use SHOW COLUMNS FROM table [LIKE 'foo'] instead. This should be documented in the manual. Reclassified as documentation bug. 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/25460 -- Edit this bug report at http://bugs.php.net/?id=25460edit=1
#25460 [NEW]: mysql_list_fields does NOT use link_identifier
From: beckman at purplecow dot com
Operating system: FreeBSD 5.0-RELEASE #0
PHP version: 4.3.3
PHP Bug Type: MySQL related
Bug description: mysql_list_fields does NOT use link_identifier
Description:
Synopsis: mysql_list_fields should ignore the currently selected database,
since the name of the database is clearly being passed to the function.
But the function uses the currently selected database rather than the
database specified in the function.
Evidence:
Using MySQL 4.0.14 and PHP 4.3.3, mysql_list_fields($db, $tbl,
$link_identifier) uses the most recent connection to mysql, not the
connection specified in $link_identifier.
I've tried to reproduce this problem, and the only place I can is in
phpMyAdmin 2.5.4 dev.
It seems that mysql_list_fields ignores the link_identifier it is passed
and uses either DB mysql or uses the most recent connection.
When testing, here's what I did.
In phpMyAdmin, I selected my database, then selected Query.
I now get an error saying #1146 - Table 'mysql.assignments' doesn't
exist.
So I got into the code in db_details_qbe.php. On line 132, this line
occurs:
$fld_results = @PMA_mysql_list_fields($db, $tbl) or
PMA_mysqlDie(PMA_mysql_error(), 'PMA_mysql_list_fields(' . $db . ', ' .
$tbl . ')', FALSE, $err_url);
The function is as this:
function PMA_mysql_list_fields($database_name, $table_name,
$link_identifier = FALSE) {
if ($link_identifier != FALSE) {
return mysql_list_fields(PMA_convert_charset($database_name),
PMA_convert_charset($table_name), $link_identifier);
} else {
return mysql_list_fields(PMA_convert_charset($database_name),
PMA_convert_charset($table_name));
}
}
When echo'ed, it was executed as mysql_list_fields(crt, assignments).
So I decided I should try using the link identifier explicitly.
$fld_results = @PMA_mysql_list_fields($db, $tbl, $userlink) or
PMA_mysqlDie(PMA_mysql_error(), 'PMA_mysql_list_fields(' . $db . ', ' .
$tbl . ')', FALSE, $err_url);
Got the same error. So then I was concerned that $userlink wasn't the
correct link to the database in question. So I did this on line 131:
$r = mysql_query(Show tables from .$db, $userlink);
while($row = mysql_fetch_array($r)) { print_r($row); }
And it gave me a list of all the tables, including assignments (first).
So I dropped the $userlink from the above code and tried it again.
Worked. So then I thought, maybe $userlink isn't using the
mysql_select_db that I think it is. So I changed the query to select
count(*) from assignments and it failed, so I assume $userlink is working
off of the assumption that the currently selected database is mysql.
mysql_list_fields should ignore the currently selected database, since the
name of the database is clearly being passed to the function. But the
function uses the currently selected database rather than the database
specified in the function.
Reproduction:
I wasn't able to use a simple $link = mysql_connect, mysql_select_db, then
see mysql_list_fields fail. I went through the phpMyAdmin code as
completely as possible, but I'm fairly certain that it is a fault in the
php functions, based on the documentation. I believe it may be related to
or similar to Bug #22661.
--
Edit bug report at http://bugs.php.net/?id=25460edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25460r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25460r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=25460r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=25460r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=25460r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=25460r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=25460r=support
Expected behavior: http://bugs.php.net/fix.php?id=25460r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=25460r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=25460r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=25460r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25460r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=25460r=dst
IIS Stability: http://bugs.php.net/fix.php?id=25460r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=25460r=gnused
