#21443 [NEW]: get_browser still has problems with browsecap.ini from www.garykeith.com
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.3.0 PHP Bug Type: Unknown/Other Function Bug description: get_browser still has problems with browsecap.ini from www.garykeith.com PHP does not detect Netscape for Windows ua: Mozilla/4.8 [en] (Windows NT 5.0; U) It did detect Mozilla 1.2 and IE 6 for Windows and Mozilla 1.1 and Netscape 4.7 in Linux. The latest verion (downloaded January 5 2003) of browsecap.ini was used. -- Edit bug report at http://bugs.php.net/?id=21443&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21443&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21443&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21443&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21443&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21443&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21443&r=support Expected behavior: http://bugs.php.net/fix.php?id=21443&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21443&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21443&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21443&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21443&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21443&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21443&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21443&r=gnused
#21443 [Bgs]: get_browser still has problems with browsecap.ini from www.garykeith.com
ID: 21443 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Unknown/Other Function Operating System: Linux PHP Version: 4.3.0 New Comment: I updated the browscap.ini and the detection works fine now with Netscape for windows: ua: Mozilla/4.8 [en] (Windows NT 5.0; U) pattern match: browser_name_pattern Mozilla/4\.8.*(Windows NT 5\.0; U) Previous Comments: [2003-01-05 21:49:27] [EMAIL PROTECTED] Ilia, I am the developer of the browscap.ini file that PHP recommends to its users. Respectfully, this issue does appear to be a bug in PHP. The user agent in question, Mozilla/4.8 [en] (Windows NT 5.0; U), is in my browscap.ini file and it is recognized when Serge visits my website which uses IIS. To me that suggests a bug in get_browser(). I am suspicious that in certain situations get_browser() has a problem dealing with multiple question marks in a user agent. In an attempt to prove my theory I changed the definition for the user agent in question and asked Serge to see if it works. I'll report back here on his results. [2003-01-05 15:41:02] [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. Thank you for your interest in PHP. Contact the developer mantaining the browsecap.ini, this is not a PHP bug. [2003-01-05 15:29:07] [EMAIL PROTECTED] PHP does not detect Netscape for Windows ua: Mozilla/4.8 [en] (Windows NT 5.0; U) It did detect Mozilla 1.2 and IE 6 for Windows and Mozilla 1.1 and Netscape 4.7 in Linux. The latest verion (downloaded January 5 2003) of browsecap.ini was used. -- Edit this bug report at http://bugs.php.net/?id=21443&edit=1
#33456 [NEW]: strtotime loosing 2 hours
From: serge at skycomp dot ca Operating system: Linux PHP version: 4.3.11 PHP Bug Type: Date/time related Bug description: strtotime loosing 2 hours Description: It seems that strtotime is loosing time. I'm loosing 2 hours on every call to it and I'm not sure why. The issue seems to be with the "at" text in the format string but I am unsure why the text "at" would make the timestamp lose exactly 2 hours. Reproduce code: --- '> ' Expected result: The output should be the formated representation from what was inputted. If sumbit is clicked again without changed the text field the value should not change since strtotime should generate a proper and valid timestamp which strftime formats again. Actual result: -- Relative to today I type: friday at 7pm click submit and the value of the text box is now: Friday, June 24 2005 at 05:00:00 PM I don't type or change anything. Simply click submit again: Friday, June 24 2005 at 03:00:00 PM Every time I click submit the timestamp looses 2 hours. -- Edit bug report at http://bugs.php.net/?id=33456&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33456&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33456&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33456&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33456&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33456&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33456&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33456&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33456&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33456&r=support Expected behavior: http://bugs.php.net/fix.php?id=33456&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33456&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33456&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33456&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33456&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33456&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33456&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33456&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33456&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33456&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33456&r=mysqlcfg
#33456 [Fbk->Opn]: strtotime loosing 2 hours
ID: 33456 User updated by: serge at skycomp dot ca Reported By: serge at skycomp dot ca -Status: Feedback +Status: Open Bug Type: Date/time related Operating System: Linux PHP Version: 4.3.11 New Comment: This server does not run php5. It's on php4 Previous Comments: [2005-06-24 00:48:26] [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 [2005-06-24 00:13:31] serge at skycomp dot ca Description: It seems that strtotime is loosing time. I'm loosing 2 hours on every call to it and I'm not sure why. The issue seems to be with the "at" text in the format string but I am unsure why the text "at" would make the timestamp lose exactly 2 hours. Reproduce code: --- '> ' Expected result: The output should be the formated representation from what was inputted. If sumbit is clicked again without changed the text field the value should not change since strtotime should generate a proper and valid timestamp which strftime formats again. Actual result: -- Relative to today I type: friday at 7pm click submit and the value of the text box is now: Friday, June 24 2005 at 05:00:00 PM I don't type or change anything. Simply click submit again: Friday, June 24 2005 at 03:00:00 PM Every time I click submit the timestamp looses 2 hours. -- Edit this bug report at http://bugs.php.net/?id=33456&edit=1
#33456 [Fbk->Opn]: strtotime loosing 2 hours
ID: 33456 User updated by: serge at skycomp dot ca Reported By: serge at skycomp dot ca -Status: Feedback +Status: Open Bug Type: Date/time related Operating System: Linux PHP Version: 4.3.11 New Comment: Ok I'll see about testing it agains the latest CVS if I have a chance. A 100% php example is as follows: Previous Comments: [2005-06-24 00:58:40] [EMAIL PROTECTED] Right. And I didn't ask you to upgrade the server. I asked to to try the latest snapshot. And I'd really appreciate if you provide a reproduce code without HTML/forms/etc. Just a plain, short and clean PHP code that demonstrates the problem. Thanks in advance. [2005-06-24 00:55:09] serge at skycomp dot ca This server does not run php5. It's on php4 [2005-06-24 00:48:26] [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 [2005-06-24 00:13:31] serge at skycomp dot ca Description: It seems that strtotime is loosing time. I'm loosing 2 hours on every call to it and I'm not sure why. The issue seems to be with the "at" text in the format string but I am unsure why the text "at" would make the timestamp lose exactly 2 hours. Reproduce code: --- '> ' Expected result: The output should be the formated representation from what was inputted. If sumbit is clicked again without changed the text field the value should not change since strtotime should generate a proper and valid timestamp which strftime formats again. Actual result: -- Relative to today I type: friday at 7pm click submit and the value of the text box is now: Friday, June 24 2005 at 05:00:00 PM I don't type or change anything. Simply click submit again: Friday, June 24 2005 at 03:00:00 PM Every time I click submit the timestamp looses 2 hours. -- Edit this bug report at http://bugs.php.net/?id=33456&edit=1
#22787 [Com]: Make fails after upgrading to mysql v4.0.12
ID: 22787 Comment by: serge at skycomp dot ca Reported By: gregory dot fennell at am dot sony dot com Status: Bogus Bug Type: MySQL related Operating System: RedHat v8.0 PHP Version: 4.3.1 New Comment: This issue seems to be related to mnogosearch PHP module and MySQL 4.x. If I remove the --with-mnogosearch it will compile fine. Not sure where to go from here as I need --with-mnogosearch Previous Comments: [2003-04-08 14:06:28] azza at sbcglobal dot net Thank you for your response. I am assuming nothing. What I have asserted is that use of a direct or symlink to libmysqlclient.so.10 is causing a problem. This ownership of this issue balances between (1) mysql, (2) rpm packagers, and (3) php. My objective was not to assert blame, but to identify a significant issue. The fact is that the environment has changed with the new production release of mysql 4.0.12, which is causing a problem (bug) since php-mysql is dependent on libmysqlclient.so.10 versus libmysqlclient.so (which has a link to the current version). [2003-04-07 17:58:46] [EMAIL PROTECTED] Come on..if you can't get it to work, don't automatically assume that it's a bug in PHP. (which this REALLY IS NOT!) [2003-04-07 07:05:22] gregory dot fennell at am dot sony dot com OK, I will try this one more time. As several postings have confirmed, this is an issue. Can someone please work on a fix so that we can move forward with using the newest production releases of PHP? It seems that two postings from "azza at sbcglobal dot net" didn't get posted or were removed so I am reposting them. Posting #2: I am unclear why this has been set to bogus vs open. (1) A significant number of other parties are having this issue. (2) The failure to reproduce the error does not mean the error does not exist. (3) The installation process for php and mysql is quite varied, thus unlesss one tests all major installation scenarios no conclusion may be drawn. (4) As shown in my previous post - several rpms show a requirement of libmysqlclient.so.10. The correction is to use libmysqlclient.so which has a symlink to the current version, which is libmysqlclient.so.12. Thus, a) the bug is not bogus, b) the correction may be simple and c) failure to correct the error may have significant negative consequences. Posting #1: Same Issue: I agree that working together is the means for resolving this issue. (1) php-mysql-4.3.1-rbt.rh8.1.i386.rpm shows requirement of libmysqlclient.so.10 http://www.aucs.org/rpmcenter/details/php-4.3.1-for-apache-1.3.x/php-mysql-4.3.1-rbt.rh8.1.i386.rpm.html (2) php-mysql-4.2.2-8.0.7 RPM for i386 shows requirement of libmysqlclient.so.10 http://rpmfind.net/linux/RPM/redhat/updates/8.0/i386/php-mysql-4.2.2-8.0.7.i386.html What should be in the code is a reference to libmysqlclient.so which is a symlink to the current version - libmysqlclient.so.12. This may be a major issue if it crashes a large number of sites. Take a look at how libmyssqlclient.so is configured on your system. [2003-04-04 10:57:34] [EMAIL PROTECTED] Did you uninstall the old mysql 3.23 version before installing that new one? Are you sure it's not just a conflict between old and new version of mysql? And I say again: This is NOT any bug in PHP. Please ask further support questions on e.g. [EMAIL PROTECTED] [2003-04-04 07:15:37] gregory dot fennell at am dot sony dot com The following RPMs are used (Version: 4.0.12): Server Client programs Libraries and header files Dynamic client libraries I also use a self-compiled version of PHP-4.3.1 with the configure line that is in my original posting. Any help you can give is greatly appreciated. I know I have several colleagues that are waiting on a fix as well. Thanks for your help in this. 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/22787 -- Edit this bug report at http://bugs.php.net/?id=22787&edit=1
#28227 [Com]: PHP CGI depends upon non-standard SCRIPT_FILENAME
ID: 28227 Comment by: serge at localhost dot localdomain Reported By: lukem at NetBSD dot org Status: No Feedback Bug Type: CGI related Operating System: * PHP Version: 5CVS, 4CVS (2005-02-04) Assigned To: fmk New Comment: The bug is still somewhere there. $ php-cgi --version PHP 5.2.6 (cgi-fcgi) (built: May 8 2008 08:52:59) Until it gets fixed in either php-cgi or webservers-side here's a workaround-wrapper: http://pastebin.ca/1296199 I wrote and tested this wrapper for thttpd only. -- Serge Previous Comments: [2007-12-27 01:16:07] al dot rivero at gmail dot com with PHP/5.2.3-1ubuntu6.2 php-cgi ejemplo.php works, but REQUEST_METHOD=GET php-cgi ejemplo.php doesn't work, it produces the bug, "No input file specified". Then REQUEST_METHOD=GET SCRIPT_FILENAME=ejemplo.php php-cgi ejemplo.php works, and more suprisingly SCRIPT_FILENAME=ejemplo.php php-cgi ejemplo.php works, and SCRIPT_FILENAME=ejemplo.php php-cgi works! Note that there is now an informative-doc RFC for CGI 1.1 http://www.ietf.org/rfc/rfc3875 and it says that _name is a MUST, but _filename is optional, in fact it is not mentioned there (it is an Apache extension). [2007-07-03 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, 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". [2007-06-25 23:44:14] sni...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi [2006-08-10 19:05:01] f...@php.net The patch broke CGI on other web servers (IIS on Win32). That was the reason it was reverted. So far I have not been able to come up with a way to apply your patch so it will work in all cases (not breaking existing installed systems). [2006-08-10 00:04:42] lukem at NetBSD dot org If I recall correctly, PHP4 as a CGI _did_ rely upon SCRIPT_FILENAME being set by the web server, at least in the default build of PHP4. My original workaround was to modify the non-Apache web server I was using to set SCRIPT_FILENAME before invoking php-as-cgi. IMHO, it not an acceptable long-term solution to modify the _web server_ because the _CGI application_ (php) relies upon a non-standard CGI variable. Which is why I developed the patch, which worked at the time for the release of PHP I was using (4.3.6). Based on the replies I've seen to my bug report & patch, other people are also seeing this problem, even in newer releases of PHP. Not everyone uses PHP as an Apache module, and not everyone uses Apache as a web server. People that want to use php as a CGI on other minimal web servers (e.g, embedded systems) may run into this problem, spend time trying to fix it, get pushback from the PHP developer community about this not being a problem (c.f. the way various bug reports documenting a similar problem with the "no input file found" being closed as "configuration problem", when I show that it's PHP-as-CGI barfing because SCRIPT_FILENAME isn't set), and in the end punt and use another solution. I strongly suggest that the PHP developers set up a test environment where PHP runs as a CGI from one of the many minimal (Open Source) web servers available that don't implement SCRIPT_FILENAME to attempt to reproduce this issue that numerous people have observerd (based on followups to this ticket, and other tickets that I've read). 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/28227 -- Edit this bug report at http://bugs.php.net/?id=28227&edit=1
Bug #48706 [Com]: SoapClient invalid wsdl crashes php with file error_log active
Edit report at http://bugs.php.net/bug.php?id=48706&edit=1 ID: 48706 Comment by: serge at mch dot be Reported by:aigors at inbox dot lv Summary:SoapClient invalid wsdl crashes php with file error_log active Status: Closed Type: Bug Package:SOAP related Operating System: Windows XP PHP Version:5.2.10 Assigned To:jani Block user comment: N Private report: N New Comment: The problem exists (again/still), I tried with current version 5.3.5 and version 5.3.4. Previous Comments: [2009-07-28 17:27:28] j...@php.net Yes, this was fixed by fixing bug #48247 [2009-07-27 07:22:23] aigors at inbox dot lv It doesn't crash with the PHP Version 5.2.11-dev build on Jul 26 2009 23:42:23. Thank you.) [2009-07-26 19:37:55] j...@php.net Please try using this snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-06-27 10:26:34] aigors at inbox dot lv I generated the crash backtrace report, it's available in http://gedrox.no-ip.org/php/CrashHang_Report__PID_5620__06272009131757156.mht. Hope did it right. [2009-06-27 09:59:53] aigors at inbox dot lv Description: SoapClient crashes the PHP when invalid wsdl_url is used and file php log output is configured in the php.ini. Reproduce code: --- PHP code: http://example.com'); ?> php.ini-dist and php.ini changes: --- C:/php5/php.ini-dist +++ C:/php5/php.ini -log_errors = Off +log_errors = On -;error_log = filename +error_log = c:/php_log -;extension=php_soap.dll +extension=php_soap.dll Expected result: SoapFault Exception should be thrown. Actual result: -- PHP crashes with system log message "Faulting application php.exe, version 5.2.10.10, faulting module php5ts.dll, version 5.2.10.10, fault address 0x000abc6f." -- Edit this bug report at http://bugs.php.net/bug.php?id=48706&edit=1
[PHP-BUG] Bug #53899 [NEW]: SoapClient invalid wsdl crashes php with file error_log active
From: Operating system: Windows Server 2003 R3 PHP version: 5.3.5 Package: SOAP related Bug Type: Bug Bug description:SoapClient invalid wsdl crashes php with file error_log active Description: See : http://bugs.php.net/bug.php?id=48706 SoapClient crashes the PHP when invalid wsdl_url is used and file php log output is configured in the php.ini. Test script: --- PHP code: http://example.com'); ?> php.ini-dist and php.ini changes: --- C:/php5/php.ini-dist +++ C:/php5/php.ini -log_errors = Off +log_errors = On -;error_log = filename +error_log = c:/php_log -;extension=php_soap.dll +extension=php_soap.dll Expected result: SoapFault Exception should be thrown. Actual result: -- FastCGI Error (Error 500) -- Edit bug report at http://bugs.php.net/bug.php?id=53899&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53899&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53899&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53899&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53899&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53899&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53899&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53899&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53899&r=needscript Try newer version: http://bugs.php.net/fix.php?id=53899&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53899&r=support Expected behavior: http://bugs.php.net/fix.php?id=53899&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53899&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53899&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53899&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53899&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53899&r=dst IIS Stability: http://bugs.php.net/fix.php?id=53899&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53899&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53899&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53899&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53899&r=mysqlcfg
Bug #53585 [Com]: PNG support broken, Abort trap: 6 (core dumped)
Edit report at https://bugs.php.net/bug.php?id=53585&edit=1 ID: 53585 Comment by: Serge dot Sitnikov at gmail dot com Reported by:serge dot sitnikov at gmail dot com Summary:PNG support broken, Abort trap: 6 (core dumped) Status: Not a bug Type: Bug Package:GD related Operating System: FreeBSD 8.1-RELEASE PHP Version:5.3.4 Block user comment: N Private report: N New Comment: I found that recompiling all pecl extensions solve the problem, so this is some kind of dependency problem. Previous Comments: [2012-03-02 01:40:13] dave at jetcafe dot org Confirmed and duplicated on FreeBSD 7.3-RELEASE. Moving a crashing extension to the top just moves the bug down. I am unable to find any determinism (which doesn't mean none exists) in this. I appreciate that both the FreeBSD camps and PHP camps are pointing at each other. It would be greatly appreciated by those of us having a problem if someone from both camps could take a cooperative look. Thank you. :) [2012-02-13 13:55:02] erik at erik dot eu By changing the order in extensions.ini the problem doesn't go away. It's moved to the latter module. with sequence; --- snip of extensions.ini --- extension=pdf.so extension=gd.so --- pdf_load_image($pdfObject,"png", 'someimage.png'); will work But png functions from GD won't! with sequence; --- snip of extensions.ini --- extension=gd.so extension=pdf.so --- GD works but pdf_load_image will segfault. doing portupgrade will alter the sequence in extensions.ini so GD works and it looks like problems are solved. But loading png in pdf will fail. Enviroment; Freebsd 8.2-RELEASE php5.3.10 just did portmaster -r png (13-feb-2012) [2011-11-17 00:17:04] andy at fud dot org dot nz I can reproduce this on FreeBSD 8.2-RELEASE (amd64) the test script is test.png can be found at https://gg.net.nz/X/test.png If I have the pdf extension loaded before gd (in extensions.ini) then I get an abort --- snip of extensions.ini --- extension=pdf.so extension=gd.so --- % php test.php zsh: abort (core dumped) php t.php If I load gd first then the issue goes away --- snip of extensions.ini --- extension=gd.so extension=pdf.so --- % php test.php ok The software versions are: php5-5.3.8 php5-gd-5.3.8 pdflib-7.0.4 pecl-pdflib-2.1.8 png-1.4.8 [2010-12-21 11:03:06] paj...@php.net Then it is definitively not a PHP problem. The tests suite work just fine, and all PNGs I use for testing as well (from the PNG tests suite and some other). Please report the issue to FreeBSD or update it as suggested in the other comment. ---- [2010-12-21 10:48:03] serge dot sitnikov at gmail dot com @paj...@php.net You may test on that image, for example: http://upload.wikimedia.org/wikipedia/commons/7/7a/Basketball.png 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=53585 -- Edit this bug report at https://bugs.php.net/bug.php?id=53585&edit=1
#48928 [NEW]: collation discreapency between mysql.exe client and mysql extensions.
From: serge dot laot at wanadoo dot fr
Operating system: Win XP Pro, Win server 2003
PHP version: 5.2.10
PHP Bug Type: MySQL related
Bug description: collation discreapency between mysql.exe client and mysql
extensions.
Description:
php_mysql.dll (or php_mysqli.dll) extension do not use the same
configuration as MySQL.exe, so if you run the same query from both sides
you will not get the same results.
I know I can use the following :
@@mysql_query("SET NAMES 'utf8'",$my);
on a fresh connection, but if the MySQL configuration changes I must have
to change the php code as well.
Reproduce code:
---
PHP code :
$rec=@@mysql_query("show Variables LIKE 'c___a%_%'",$my);
while($row=mysql_fetch_assoc($rec)){
foreach($row as $n=>$v){
echo $v."\n";
}
}
MySQL code ;
show Variables LIKE 'c___a%_%';
Expected result:
Mysql.exe results :
Variable_name Value
character_set_clientutf8
character_set_connectionutf8
character_set_database utf8
character_set_filesystembinary
character_set_results utf8
character_set_serverutf8
character_set_systemutf8
character_sets_dir ...\share\charsets\
collation_connectionutf8_general_ci
collation_database utf8_general_ci
collation_serverutf8_general_ci
Actual result:
--
php_mysql.dll results :
Variable_name Value
character_set_clientlatin1
character_set_connectionlatin1
character_set_database utf8
character_set_filesystembinary
character_set_results latin1
character_set_serverutf8
character_set_systemutf8
character_sets_dir ...\share\charsets\
collation_connectionlatin1_swedish_ci
collation_database utf8_general_ci
collation_serverutf8_general_ci
--
Edit bug report at http://bugs.php.net/?id=48928&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48928&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48928&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48928&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48928&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48928&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48928&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48928&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48928&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48928&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48928&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48928&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48928&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48928&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48928&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48928&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48928&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48928&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48928&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48928&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48928&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48928&r=mysqlcfg
[PHP-BUG] Bug #53585 [NEW]: PNG support broken, Abort trap: 6 (core dumped)
From:
Operating system: FreeBSD 8.1-RELEASE
PHP version: 5.3.4
Package: GD related
Bug Type: Bug
Bug description:PNG support broken, Abort trap: 6 (core dumped)
Description:
PNG support broken, completely. If PHP runs under Apache that will lead to
workers exhaustion.
PHP 5.3.4 on FreeBSD 8.1-RELEASE amd64
array (
'GD Version' => 'bundled (2.0.34 compatible)',
'FreeType Support' => true,
'FreeType Linkage' => 'with freetype',
'T1Lib Support' => true,
'GIF Read Support' => true,
'GIF Create Support' => true,
'JPEG Support' => true,
'PNG Support' => true,
'WBMP Support' => true,
'XPM Support' => true,
'XBM Support' => true,
'JIS-mapped Japanese Font Support' => false,
)
png-1.4.4 Library for manipulating PNG images
Test script:
---
$image = imagecreatefrompng('/path/to/my/png/file');
Expected result:
Image opened.
Actual result:
--
Abort trap: 6 (core dumped)
--
Edit bug report at http://bugs.php.net/bug.php?id=53585&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53585&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53585&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53585&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53585&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53585&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53585&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53585&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53585&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53585&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53585&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53585&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53585&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53585&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53585&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53585&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53585&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53585&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53585&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53585&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53585&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53585&r=mysqlcfg
Bug #53585 [Com]: PNG support broken, Abort trap: 6 (core dumped)
Edit report at http://bugs.php.net/bug.php?id=53585&edit=1
ID: 53585
Comment by: serge dot sitnikov at gmail dot com
Reported by:serge dot sitnikov at gmail dot com
Summary:PNG support broken, Abort trap: 6 (core dumped)
Status: Open
Type: Bug
Package:GD related
Operating System: FreeBSD 8.1-RELEASE
PHP Version:5.3.4
Block user comment: N
Private report: N
New Comment:
Unfortunately, upgrading and reinstalling all of PHP related ports does
not solve
the problem.
Previous Comments:
[2010-12-21 08:49:52] eugene at krivoruchko dot info
In FreeBSD 8.0
After update all port:
#portmanager -u
This problem resolved...
[2010-12-21 08:18:20] serge dot sitnikov at gmail dot com
Description:
PNG support broken, completely. If PHP runs under Apache that will lead
to
workers exhaustion.
PHP 5.3.4 on FreeBSD 8.1-RELEASE amd64
array (
'GD Version' => 'bundled (2.0.34 compatible)',
'FreeType Support' => true,
'FreeType Linkage' => 'with freetype',
'T1Lib Support' => true,
'GIF Read Support' => true,
'GIF Create Support' => true,
'JPEG Support' => true,
'PNG Support' => true,
'WBMP Support' => true,
'XPM Support' => true,
'XBM Support' => true,
'JIS-mapped Japanese Font Support' => false,
)
png-1.4.4 Library for manipulating PNG images
Test script:
---
$image = imagecreatefrompng('/path/to/my/png/file');
Expected result:
Image opened.
Actual result:
--
Abort trap: 6 (core dumped)
--
Edit this bug report at http://bugs.php.net/bug.php?id=53585&edit=1
Bug #53585 [Com]: PNG support broken, Abort trap: 6 (core dumped)
Edit report at http://bugs.php.net/bug.php?id=53585&edit=1
ID: 53585
Comment by: serge dot sitnikov at gmail dot com
Reported by:serge dot sitnikov at gmail dot com
Summary:PNG support broken, Abort trap: 6 (core dumped)
Status: Feedback
Type: Bug
Package:GD related
Operating System: FreeBSD 8.1-RELEASE
PHP Version:5.3.4
Block user comment: N
Private report: N
New Comment:
@paj...@php.net
Image does not matter. Any PNG image I have tested lead to the same
result --
core dumped. Already tested that on two machines.
Previous Comments:
[2010-12-21 10:25:30] paj...@php.net
@serge dot sitnikov at gmail dot com
Please provide the PNG image you use as test.
[2010-12-21 10:24:38] paj...@php.net
Not a php problem then :)
[2010-12-21 09:26:55] serge dot sitnikov at gmail dot com
Unfortunately, upgrading and reinstalling all of PHP related ports does
not solve
the problem.
[2010-12-21 08:49:52] eugene at krivoruchko dot info
In FreeBSD 8.0
After update all port:
#portmanager -u
This problem resolved...
[2010-12-21 08:18:20] serge dot sitnikov at gmail dot com
Description:
PNG support broken, completely. If PHP runs under Apache that will lead
to
workers exhaustion.
PHP 5.3.4 on FreeBSD 8.1-RELEASE amd64
array (
'GD Version' => 'bundled (2.0.34 compatible)',
'FreeType Support' => true,
'FreeType Linkage' => 'with freetype',
'T1Lib Support' => true,
'GIF Read Support' => true,
'GIF Create Support' => true,
'JPEG Support' => true,
'PNG Support' => true,
'WBMP Support' => true,
'XPM Support' => true,
'XBM Support' => true,
'JIS-mapped Japanese Font Support' => false,
)
png-1.4.4 Library for manipulating PNG images
Test script:
---
$image = imagecreatefrompng('/path/to/my/png/file');
Expected result:
Image opened.
Actual result:
--
Abort trap: 6 (core dumped)
--
Edit this bug report at http://bugs.php.net/bug.php?id=53585&edit=1
Bug #53585 [Com]: PNG support broken, Abort trap: 6 (core dumped)
Edit report at http://bugs.php.net/bug.php?id=53585&edit=1 ID: 53585 Comment by: serge dot sitnikov at gmail dot com Reported by:serge dot sitnikov at gmail dot com Summary:PNG support broken, Abort trap: 6 (core dumped) Status: Feedback Type: Bug Package:GD related Operating System: FreeBSD 8.1-RELEASE PHP Version:5.3.4 Block user comment: N Private report: N New Comment: @paj...@php.net You may test on that image, for example: http://upload.wikimedia.org/wikipedia/commons/7/7a/Basketball.png Previous Comments: [2010-12-21 10:40:54] serge dot sitnikov at gmail dot com @paj...@php.net Image does not matter. Any PNG image I have tested lead to the same result -- core dumped. Already tested that on two machines. [2010-12-21 10:25:30] paj...@php.net @serge dot sitnikov at gmail dot com Please provide the PNG image you use as test. [2010-12-21 10:24:38] paj...@php.net Not a php problem then :) [2010-12-21 09:26:55] serge dot sitnikov at gmail dot com Unfortunately, upgrading and reinstalling all of PHP related ports does not solve the problem. [2010-12-21 08:49:52] eugene at krivoruchko dot info In FreeBSD 8.0 After update all port: #portmanager -u This problem resolved... 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/bug.php?id=53585 -- Edit this bug report at http://bugs.php.net/bug.php?id=53585&edit=1
[PHP-BUG] Bug #55203 [NEW]: Missing region names from geoip library
From:
Operating system: Linux (Ubuntu)
PHP version: 5.3SVN-2011-07-14 (SVN)
Package: Unknown/Other Function
Bug Type: Bug
Bug description:Missing region names from geoip library
Description:
PHP Version: PHP 5.3.3-1ubuntu9.3 with Suhosin-Patch (cli) (built: Jan 12
2011
16:07:38)
GeoIP version: GEO-106 20110510 Build 1 Copyright (c) 2011 MaxMind Inc All
Rights Reserved
Description:
Upon calling geoip_region_name_by_code for certain regions, the region name
returned is empty.
Ex:
echo geoip_region_name_by_code("AG","08"); // Returns: Saint Philip
echo geoip_region_name_by_code("AG","09"); // Returns: Nothing
What is expected:
The geoip_region_name_by_code function to return the correct region name
for all
regions described in the standard http://www.maxmind.com/app/fips10_4
(Note: This link is even published on
http://www.php.net/manual/en/function.geoip-region-name-by-code.php)
The issue:
As mentioned on
http://www.php.net/manual/en/function.geoip-region-name-by-
code.php
The data is taken directly from the GeoIP Library and not from any
database.
This means that the php geoip library has to be updated.
Solution:
Small mindless work of updating the source code of the php geoip library
with
the missing regions. (44 of them):
Country Region
AG 09
CG 13
CG 14
HU 43
MD 57
MV 30
MV 31
MV 32
MV 33
MV 34
MV 35
MV 36
MV 37
MV 38
MV 39
MV 41
MV 42
MV 43
MV 44
MV 45
MV 46
MV 47
TN 10
UG 26
UG 28
UG 29
UG 30
UG 31
UG 38
UG 39
UG 40
UG 41
UG 43
UG 45
UG 46
UG 47
UG 50
UG 58
UG 59
UG 60
UG 61
UG 70
UG 72
UG 76
Test script:
---
echo geoip_region_name_by_code("AG","08");
Saint Philip // Working!
echo geoip_region_name_by_code("AG","09");
// Nothing ...
Expected result:
The region name according to http://www.maxmind.com/app/fips10_4
--
Edit bug report at https://bugs.php.net/bug.php?id=55203&edit=1
--
Try a snapshot (PHP 5.2):
https://bugs.php.net/fix.php?id=55203&r=trysnapshot52
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=55203&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=55203&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=55203&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=55203&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=55203&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=55203&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=55203&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=55203&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=55203&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=55203&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=55203&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=55203&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=55203&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=55203&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=55203&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=55203&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=55203&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=55203&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=55203&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=55203&r=mysqlcfg
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=55203&r=trysnapshot54
Bug #61579 [Com]: Segfault preg_replace "/'(\\\\'|\\\\{2}|[^'])*'/" with a long string
Edit report at https://bugs.php.net/bug.php?id=61579&edit=1
ID: 61579
Comment by: serge dot rivest at gmail dot com
Reported by:robin at byte dot nl
Summary:Segfault preg_replace "/'('|{2}|[^'])*'/"
with a long string
Status: Feedback
Type: Bug
Package:PCRE related
Operating System: Debian 2.6.
PHP Version:5.3.10
Block user comment: N
Private report: N
New Comment:
It does appear to be failing on this line:
foreach ($db->fetchAll($sql) as $a)
Very very likely it's just running out of memory. Although every time it
crashes
we also get this in /var/log/syslog:
Oct 8 20:01:39 dev kernel: [726784.383723] php5-fpm[8644]: segfault at
7fff6b8a2f00 ip 7f6607c80a7a sp 7fff6b8a2e90 error 6 in
libpcre.so.3.12.1[7f6607c6e000+3c000]
Which is bizarre. Might just be a regexp in the DB driver which is being run
when
the process runs out of memory... Hrm, time to try Serges idea of using xdebug.
And we see:
0.8160 12868128 -> PDO->quote()
/www/studyladder.dev222/zendframework/Zend/Db/Adapter/Pdo/Abstract.php:296
0.8160 12868344 -> substr()
/www/studyladder.dev222/zendframework/Zend/Db/Statement.php:198
0.8160 12868456 -> str_replace()
/www/studyladder.dev222/zendframework/Zend/Db/Statement.php:199
0.8160 12868472 -> preg_replace()
/www/studyladder.dev222/zendframework/Zend/Db/Statement.php:204
So, probably not running out of memory. This is the code it's crashing on:
// get a version of the SQL statement with all quoted
// values and delimited identifiers stripped out
// remove "foo\"bar"
$sql = preg_replace("/$q($qe|{2}|[^$q])*$q/", '', $sql);
Don't really know what it is doing, but the regexp looks like this:
/'(\\'|\\{2}|[^'])*'/
And the query it is crashing on does have a long literal string in it with
single
quotes. Tried changing the query to use a long literal string with double
quotes
and that fixes it. Phew.
Previous Comments:
[2012-03-31 18:24:38] yohg...@php.net
Cannot reproduce. Could you download source and test against it?
It seems your system's pcrelib problem.
[2012-03-31 11:18:42] robin at byte dot nl
Looked a bit deeper/cleaner:
The preg_replace failes when the string between single quotes is equal or
longer than 3399 bytes including quotes... 3487 already did seem like an odd
number ;)
cleaner would be if you take $string = "'...3397chars...'";
then it fails with segfault,
$string = "'...less than 3397 chars...'"; works fine.
[2012-03-31 10:53:49] robin at byte dot nl
Description:
When i use this preg_replace with a long string (3487+ bytes) and single quotes
it ends up with a segfault...
$str = preg_replace("/'('|{2}|[^'])*'/", '', $string);
with a string longer than 3487 bytes containing multiple quotes.
results in:
php[26779]: segfault at bf737da8 ip b73e4d43 sp bf737c30 error 6 in
libpcre.so.3.12.1[b73d4000+28000]
Test script:
---
Expected result:
Remove everything between single quotes.
Actual result:
--
Segmentation fault
[25236001.27] php[29917]: segfault at bf37ddc8 ip b744cd43 sp bf37dc50
error 6 in libpcre.so.3.12.1[b743c000+28000]
--
Edit this bug report at https://bugs.php.net/bug.php?id=61579&edit=1
Bug #61579 [Com]: Segfault preg_replace "/'(\\\\'|\\\\{2}|[^'])*'/" with a long string
Edit report at https://bugs.php.net/bug.php?id=61579&edit=1
ID: 61579
Comment by: serge dot rivest at gmail dot com
Reported by:robin at byte dot nl
Summary:Segfault preg_replace "/'('|{2}|[^'])*'/"
with a long string
Status: Feedback
Type: Bug
Package:PCRE related
Operating System: Debian 2.6.
PHP Version:5.3.10
Block user comment: N
Private report: N
New Comment:
I guess that's a question for the people in charge of Zend DB, where this
pattern
originates.
I'm just a user ;)
Previous Comments:
[2012-10-08 10:00:31] ni...@php.net
I don't know what exactly the problem is you're facing, but there is a good
chance that it's just a stack overflow or similar caused by a very inefficient
regex.
You might be able to fix it simply by using "/'('|{2}|[^']+)*'/".
The right approach though would be "/'[^']*(?:.[^']*)*'/".
[2012-10-08 09:46:09] serge dot rivest at gmail dot com
It does appear to be failing on this line:
foreach ($db->fetchAll($sql) as $a)
Very very likely it's just running out of memory. Although every time it
crashes
we also get this in /var/log/syslog:
Oct 8 20:01:39 dev kernel: [726784.383723] php5-fpm[8644]: segfault at
7fff6b8a2f00 ip 7f6607c80a7a sp 7fff6b8a2e90 error 6 in
libpcre.so.3.12.1[7f6607c6e000+3c000]
Which is bizarre. Might just be a regexp in the DB driver which is being run
when
the process runs out of memory... Hrm, time to try Serges idea of using xdebug.
And we see:
0.8160 12868128 -> PDO->quote()
/www/studyladder.dev222/zendframework/Zend/Db/Adapter/Pdo/Abstract.php:296
0.8160 12868344 -> substr()
/www/studyladder.dev222/zendframework/Zend/Db/Statement.php:198
0.8160 12868456 -> str_replace()
/www/studyladder.dev222/zendframework/Zend/Db/Statement.php:199
0.8160 12868472 -> preg_replace()
/www/studyladder.dev222/zendframework/Zend/Db/Statement.php:204
So, probably not running out of memory. This is the code it's crashing on:
// get a version of the SQL statement with all quoted
// values and delimited identifiers stripped out
// remove "foo\"bar"
$sql = preg_replace("/$q($qe|{2}|[^$q])*$q/", '', $sql);
Don't really know what it is doing, but the regexp looks like this:
/'(\\'|\\{2}|[^'])*'/
And the query it is crashing on does have a long literal string in it with
single
quotes. Tried changing the query to use a long literal string with double
quotes
and that fixes it. Phew.
[2012-03-31 18:24:38] yohg...@php.net
Cannot reproduce. Could you download source and test against it?
It seems your system's pcrelib problem.
[2012-03-31 11:18:42] robin at byte dot nl
Looked a bit deeper/cleaner:
The preg_replace failes when the string between single quotes is equal or
longer than 3399 bytes including quotes... 3487 already did seem like an odd
number ;)
cleaner would be if you take $string = "'...3397chars...'";
then it fails with segfault,
$string = "'...less than 3397 chars...'"; works fine.
[2012-03-31 10:53:49] robin at byte dot nl
Description:
When i use this preg_replace with a long string (3487+ bytes) and single quotes
it ends up with a segfault...
$str = preg_replace("/'('|{2}|[^'])*'/", '', $string);
with a string longer than 3487 bytes containing multiple quotes.
results in:
php[26779]: segfault at bf737da8 ip b73e4d43 sp bf737c30 error 6 in
libpcre.so.3.12.1[b73d4000+28000]
Test script:
---
Expected result:
Remove everything between single quotes.
Actual result:
--
Segmentation fault
[25236001.27] php[29917]: segfault at bf37ddc8 ip b744cd43 sp bf37dc50
error 6 in libpcre.so.3.12.1[b743c000+28000]
--
Edit this bug report at https://bugs.php.net/bug.php?id=61579&edit=1
#40850 [NEW]: The connection to a MySQL Server don't return FALSE if the connection failed.
From: serge dot dominici at e-sd dot org
Operating system: win32
PHP version: 5.2.1
PHP Bug Type: MySQLi related
Bug description: The connection to a MySQL Server don't return FALSE if the
connection failed.
Description:
When creating the mysqli object, it don't return FALSE as said in the
documentation, if the connection failed.
Reproduce code:
---
try {
$this->mysqli = @new mysqli('localhost', 'bad_user', 'password', 'db');
if ($this->mysqli == FALSE) {
throw new Exception("Connection failed !");
}
var_dump($this->mysqli);
var_export($this->mysqli);
} catch (Exception $e) {
$e->showStackTrace();
}
Expected result:
object(mysqli)#5 (0) { } mysqli::__set_state(array( ))
Actual result:
--
Connection failed !
--
Edit bug report at http://bugs.php.net/?id=40850&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=40850&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=40850&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=40850&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=40850&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=40850&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=40850&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=40850&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=40850&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=40850&r=support
Expected behavior:http://bugs.php.net/fix.php?id=40850&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=40850&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=40850&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=40850&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40850&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=40850&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=40850&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=40850&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=40850&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=40850&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=40850&r=mysqlcfg
#40850 [Opn]: The connection to a MySQL Server don't return FALSE if the connection failed.
ID: 40850
User updated by: serge dot dominici at e-sd dot org
Reported By: serge dot dominici at e-sd dot org
Status: Open
Bug Type: MySQLi related
Operating System: win32
PHP Version: 5.2.1
New Comment:
Sorry i have invert 'Expected result' and 'Actual result'
Previous Comments:
[2007-03-18 22:35:53] serge dot dominici at e-sd dot org
Description:
When creating the mysqli object, it don't return FALSE as said in the
documentation, if the connection failed.
Reproduce code:
---
try {
$this->mysqli = @new mysqli('localhost', 'bad_user', 'password',
'db');
if ($this->mysqli == FALSE) {
throw new Exception("Connection failed !");
}
var_dump($this->mysqli);
var_export($this->mysqli);
} catch (Exception $e) {
$e->showStackTrace();
}
Expected result:
object(mysqli)#5 (0) { } mysqli::__set_state(array( ))
Actual result:
--
Connection failed !
--
Edit this bug report at http://bugs.php.net/?id=40850&edit=1
