#48888 [NoF->Csd]: script crashing when running simultaneously
ID: 4 User updated by: contact at juzaz dot com Reported By: contact at juzaz dot com -Status: No Feedback +Status: Closed Bug Type: Reproducible crash Operating System: Linux 2.6.24-gentoo-r8 PHP Version: 5.2.10 New Comment: After reinstalling a bunch of components to find the cause of this weird issue, I upgraded my kernel and it fixed it. I unfortunately don't know the reason behind but at least it works well now. Previous Comments: [2009-07-20 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". [2009-07-12 12:30:08] j...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. [2009-07-12 08:00:45] sjoerd-php at linuxonly dot nl Thank you for your bug report. How do you run these scripts? From the command line or from the browser? [2009-07-11 17:12:36] contact at juzaz dot com Description: When running 2 batch scripts simultaneously, getting weird errors like: Fatal error: Call to undefined function substr() in xxx.php on line 125 The problem is obviously not related to the source code as it happens with built-in functions. It also happens with custom class functions sometimes. The problem doesn't seem to exist when a single php process is running. Unfortunately the problem is not reproductible intentionnally. The exact same code and conditions will sometimes work and other times fail. -- Edit this bug report at http://bugs.php.net/?id=4&edit=1
#49393 [Com]: Comment Block exiting prematurally
ID: 49393
Comment by: carsten_sttgt at gmx dot de
Reported By: mudoch at gmail dot com
Status: Feedback
Bug Type: Scripting Engine problem
Operating System: Win XPsp3
PHP Version: 5.3.0
New Comment:
> verses the action in 5.2.5 where the code was written and tested.
In your 5.2.5 installation short_open_tags was enabled. In your current
installation it's not.
Regards,
Carsten
Previous Comments:
[2009-08-27 19:16:08] sjo...@php.net
Thank you for your bug report.
I was unable to reproduce the bug you described. Are you sure there is
no ?> somewhere in the comment? Did you supplied the right example code?
Is there some non-ASCII character in your file? It may help us if you
put the file up for download somewhere.
[2009-08-27 19:00:02] mudoch at gmail dot com
Description:
The comment block /* ... */ will exit at the first > in the block
verses the action in 5.2.5 where the code was written and tested.
Reproduce code:
---
= 2.1
* @package barcode-mribti
* @copyright 2001 Karim Mribti
* @see image.php
* @version $Id$
*
* barcode site home page
* Adapted from 0.0.7a on 2007-05-24 by Frédéric G. MARAND for Agorus
S.A.
*
* May2009 Lawrence Sall - modified for a cleaner fit, adjust util.php
for
* desired defaults.
*
*
*/
include("home.php");
?>
Expected result:
Page in home.php to be displayed
Actual result:
--
= 2.1 * @package barcode-mribti * @copyright 2001 Karim Mribti * @see
image.php * @version $Id$ * * barcode site home page * Adapted from
0.0.7a on 2007-05-24 by Frédéric G. MARAND for Agorus S.A. * * May2009
Lawrence Sall - modified for a cleaner fit, adjust util.php for *
desired defaults. * * */ include("home.php"); ?>
--
Edit this bug report at http://bugs.php.net/?id=49393&edit=1
#39340 [Com]: "With" keyword
ID: 39340
Comment by: robeddielee at hotmail dot com
Reported By: thehub at lofty dot net dot au
Status: Open
Bug Type: Feature/Change Request
Operating System: Windows XP
PHP Version: 4.4.4
New Comment:
One interesting use for this would be as an alternative to the
convention of using method chaining with setters. For example:
$definition->addField(new StringField('username'))
->setRequired(true)
->setReadonly(true);
Is becoming a popular convention, but requires all your setters to
return $this, which I personally dislike, and this pattern cannot be
used with existing APIs such as PEAR modules.
Using the with statement, would facilitate the method chaining setters
pattern without requiring hacks to your APIs. For example:
with ($definition->addField(new StringField('username')))
{
->setRequired(true);
->setReadonly(true);
}
This would require only that addField return the added object, which is
more palatable to me compared to all setters returning $this.
Previous Comments:
[2008-04-09 07:38:20] ois at oisnot dot com
Anyway, use objects.
[2007-01-08 19:12:24] thehub at lofty dot net dot au
or perhaps for a long piece of code that would be used a lot. this ugly
rectangle of code for example:
$server[$currServ][$currDB][$currGroup][$currUser]['access']=4;
$server[$currServ][$currDB][$currGroup][$currUser]['email']='';
$server[$currServ][$currDB][$currGroup][$currUser]['lastlogin']=0;
$server[$currServ][$currDB][$currGroup][$currUser]['projects']=array();
becomes
with($server[$currServ][$currDB][$currGroup][$currUser]){
$['access']=4;
$['email']='';
$['lastlogin']=0;
$['projects']=array()
}
kind of like a function that's created on the fly and then destroyed
when it's finished
[2006-11-02 02:34:22] thehub at lofty dot net dot au
Description:
Visual Basic has a neat little code trick that I'd like to see in
PHP...
With object1
.property1="value"
.function1()
End With
And it can be nested. This is useful if you don't want to create a
variable to hold the return of, e.g. a function call that returns an
array, when you only need it for two or three lines.
Reproduce code:
---
with($nested_array['a_very_long_key']){
$[0]='apples';
with(function1($[1]->data))
echo template($['title'],$['content']);
}
// or
with $object1:
with $->property1:
function1($['key_of_property1']);
endwith
endwith
--
Edit this bug report at http://bugs.php.net/?id=39340&edit=1
#27051 [Opn->Asn]: Impersonation with FastCGI does not EXEC process as impersonated user
ID: 27051 Updated by: paj...@php.net Reported By: ghoffer at globalscape dot com -Status: Open +Status: Assigned Bug Type: Feature/Change Request Operating System: Windows PHP Version: 4.3.4 -Assigned To: +Assigned To: pajoye New Comment: Assigned to me so it will stay in my radar. I can see the src of the bug. Previous Comments: [2009-08-27 19:17:38] nathan at andersonsplace dot net Please note this is still occurring in PHP 5.2 branch. [2009-06-24 15:12:12] tgross at m-s dot de When will this bug be fixed? I compiled PHP myself an added the fix that ghoffer submitted. The fix works, so would you please add these few lines into PHP? It's a big problem on our servers that impersonation does not work correctly. [2008-12-09 00:45:43] louis at steelbytes dot com I've added a new function to my now inappropriately named 'PHP_Filetimes' http://www.steelbytes.com/?mid=46 (use the *beta* download) The new function is a simple wrapper for CreateProcessAsUser that deals with this problem. come on PHP/Zend pull ya socks up, I shouldn't have to write my own extensions to work around such 'bugs'/limitations :-) [2008-12-08 23:04:23] louis at steelbytes dot com please please please fix/add this. it is killing me with 5.2.6 / win2008. [2007-06-21 18:06:45] aheckmann at m-s dot de I have the same problem here. Has anything happens in the last three years on that feature request? The solution seems to be easy, or not? 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/27051 -- Edit this bug report at http://bugs.php.net/?id=27051&edit=1
#49394 [Opn->Csd]: Probable date_format regression due to #48058
ID: 49394
Updated by: der...@php.net
Reported By: hjones at hopone dot net
-Status: Open
+Status: Closed
Bug Type: Strings related
Operating System: Solaris 9 (Sparc V9; 64-bit)
PHP Version: 5.2.10
New Comment:
This bug has been fixed in SVN.
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/.
Thank you for the report, and for helping us make PHP better.
This is already fixed in SVN, please try a snapshot.
Previous Comments:
[2009-08-27 20:49:24] hjones at hopone dot net
PHP was compiled with the following GCC:
# gcc -v
Reading specs from
/usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.3.2/specs
Configured with: ../configure --with-as=/usr/ccs/bin/as
--with-ld=/usr/ccs/bin/ld --disable-nls
Thread model: posix
gcc version 3.3.2
[2009-08-27 20:43:17] hjones at hopone dot net
Description:
Upgrading from 5.2.9 to 5.2.10 causes setcookie() to return the year
'' instead of '2009' when used with time() as the cookie expiry.
Replacing 5.2.10's ext/date/php_date.{c,h} with 5.2.9's copy and
recompiling corrects this issue.
I believe this is a regression caused by PHP bug #48058
Reproduce code:
---
Expected result:
Set-Cookie: php_test_cookie=test_cookie_value; expires=Sun, 13-Sep-2009
11:31:54 GMT
Actual result:
--
Set-Cookie: php_test_cookie=test_cookie_value; expires=Sun, 13-Sep-
11:31:54 GMT
--
Edit this bug report at http://bugs.php.net/?id=49394&edit=1
#49348 [Opn->Ver]: Uninitialized ++$foo->bar; does not cause a notice (but ++$bar; does!)
ID: 49348 Updated by: sjo...@php.net Reported By: BelStudent at yandex dot ru -Status: Open +Status: Verified Bug Type: Scripting Engine problem Operating System: * PHP Version: 5.*, 6 New Comment: In _get_zval_cv_lookup(), type is BP_VAR_W, while it should be BP_VAR_RW for the example code. Previous Comments: [2009-08-25 08:18:09] j...@php.net Reopened, Gwynne's arguments are rock solid. :) [2009-08-25 07:13:46] gwy...@php.net Actually, this is a valid problem; the problem described by bug #21008 is a different issue. There seems to be some confusion as to whether it should be fixed or not, but it's neither a duplicate nor bogus. Specifically, bug #21008 describes an issue with setting a variable to a value, where this report describes an issue with updating a variable. These are two distinct operations, and are handled differently. More to the point, the following code throws a notice: That the code described by this bug doesn't is an inconsistency. [2009-08-24 16:21:58] BelStudent at yandex dot ru Description: Usually, if you try to do this: ++$num, then thrown notice, that the "Undefined variable: num". This helps avoid errors. But if you have class and you're trying to do so ++$this->num num nowhere and had not previously identified, then the issue no warnings and notices. Accidentally deleted in the symbol and received ++$this->nu, and then climbed into hell knows what mistakes to find this place and correct to ++$this->num took several hours. So I am very concerned about the issue: how to do so were given notice, if you try to do something with uninitialized (unknown) variable in the class? Reproduce code: --- num; } } new A(); ?> Expected result: Undefined property: A::$num Actual result: -- empty -- Edit this bug report at http://bugs.php.net/?id=49348&edit=1
#49394 [Com]: Probable date_format regression due to #48058
ID: 49394
Comment by: hjones at hopone dot net
Reported By: hjones at hopone dot net
Status: Open
Bug Type: Strings related
Operating System: Solaris 9 (Sparc V9; 64-bit)
PHP Version: 5.2.10
New Comment:
PHP was compiled with the following GCC:
# gcc -v
Reading specs from
/usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.3.2/specs
Configured with: ../configure --with-as=/usr/ccs/bin/as
--with-ld=/usr/ccs/bin/ld --disable-nls
Thread model: posix
gcc version 3.3.2
Previous Comments:
[2009-08-27 20:43:17] hjones at hopone dot net
Description:
Upgrading from 5.2.9 to 5.2.10 causes setcookie() to return the year
'' instead of '2009' when used with time() as the cookie expiry.
Replacing 5.2.10's ext/date/php_date.{c,h} with 5.2.9's copy and
recompiling corrects this issue.
I believe this is a regression caused by PHP bug #48058
Reproduce code:
---
Expected result:
Set-Cookie: php_test_cookie=test_cookie_value; expires=Sun, 13-Sep-2009
11:31:54 GMT
Actual result:
--
Set-Cookie: php_test_cookie=test_cookie_value; expires=Sun, 13-Sep-
11:31:54 GMT
--
Edit this bug report at http://bugs.php.net/?id=49394&edit=1
#49394 [NEW]: Probable date_format regression due to #48058
From: hjones at hopone dot net
Operating system: Solaris 9 (Sparc V9; 64-bit)
PHP version: 5.2.10
PHP Bug Type: Strings related
Bug description: Probable date_format regression due to #48058
Description:
Upgrading from 5.2.9 to 5.2.10 causes setcookie() to return the year
'' instead of '2009' when used with time() as the cookie expiry.
Replacing 5.2.10's ext/date/php_date.{c,h} with 5.2.9's copy and
recompiling corrects this issue.
I believe this is a regression caused by PHP bug #48058
Reproduce code:
---
Expected result:
Set-Cookie: php_test_cookie=test_cookie_value; expires=Sun, 13-Sep-2009
11:31:54 GMT
Actual result:
--
Set-Cookie: php_test_cookie=test_cookie_value; expires=Sun, 13-Sep-
11:31:54 GMT
--
Edit bug report at http://bugs.php.net/?id=49394&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49394&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49394&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49394&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49394&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49394&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49394&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49394&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49394&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49394&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49394&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49394&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49394&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49394&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49394&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49394&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49394&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49394&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49394&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49394&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49394&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49394&r=mysqlcfg
#48746 [Com]: Unable to browse directories within Junction Points
ID: 48746
Comment by: phpstuff at cresstone dot com
Reported By: ddkees at illinois dot edu
Status: Feedback
Bug Type: Directory function related
Operating System: win32 only - Windows Server 2003
PHP Version: 5.3.0
Assigned To: pajoye
New Comment:
Ok, this snap seems to get everything except mounted volumes for me.
test output is now:
C:\mnt\test>php phptest.php
directory: bool(true)
junction.exe junction: bool(true)
mklink junction:bool(true)
mounted volume: bool(false)
I've found 3 ways to create volume junction points on Win 7: Through
the mountvol command, thourgh the mklink command, and though the
diskmgmt.msc GUI. They all result in the same behavior.
I also just found that mklink can create symlinks to volumes, which,
alas, also fail. (symlinks to directories & files work fine) 'dir'
command for symlinks vs. junctions to volumes looks like this:
2009.08.27 15.18 test2
[\\?\Volume{c7981ed5-d602-11dd-ac24-806e6f6e6963}\]
2009.08.27 15.19 test3
[\\?\Volume{c7981ed5-d602-11dd-ac24-806e6f6e6963}\]
For the record, the following command sequence can be used to re-create
my test setup... c:\mnt & c:\mnt\test are regular directories.
C:\mnt\test>mkdir directory
C:\mnt\test>junction junction directory
Junction v1.05 - Windows junction creator and reparse point viewer
Copyright (C) 2000-2007 Mark Russinovich
Systems Internals - http://www.sysinternals.com
Created: C:\mnt\test\junction
Targetted at: C:\mnt\test\directory
C:\mnt\test>mklink /j mklink_junction directory
Junction created for mklink_junction <<===>> directory
C:\mnt\test>mklink /j mounted_volume
\\?\Volume{c7981ed5-d602-11dd-ac24-806e6f6e6963}\
Junction created for mounted_volume <<===>>
\\?\Volume{c7981ed5-d602-11dd-ac24-806e6f6e6963}\
C:\mnt\test>dir
Volume in drive C is coreI7_System
Volume Serial Number is 38E2-2B62
Directory of C:\mnt\test
2009.08.27 15.29 .
2009.08.27 15.29 ..
2009.08.27 15.27 directory
2009.08.27 15.27 junction
[\??\C:\mnt\test\directory]
2009.08.27 15.28 mklink_junction
[C:\mnt\test\directory]
2009.08.27 15.29 mounted_volume
[\\?\Volume{c7981ed5-d602-11dd-ac24-806e6f6e6963}
\]
2009.08.27 15.23 451 phptest.php
1 File(s)451 bytes
6 Dir(s) 28,746,731,520 bytes free
C:\mnt\test>php phptest.php
directory: bool(true)
junction.exe junction: bool(true)
mklink junction:bool(true)
mounted volume: bool(false)
Thanks for your work on this, unfortunately, my inability to keep track
of drive letters means I use a lot of mounted volumes...
Previous Comments:
[2009-08-27 09:50:22] paj...@php.net
And confirmed your last cases using Win7/Vista/2k8. In this case
junction are prepended with \??\. Fix applied, the next snap should
have it.
[2009-08-27 09:39:02] s...@php.net
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revision&revision=287800
Log: - Fix for #48746, fix mounted volume and junctions when used from
vista or later, they are actually prepended with \??\
[2009-08-27 09:24:03] paj...@php.net
To do not miss a case again, can you please tell me how you create each
mounted volume or junction? If mnt is a mounted volume or not, etc.
Junction created with junction.exe works fine here on xp, 2k3, win7,
vista and 2k8, using normal parent directories (mounted volume or not).
For example (XP):
c:\mnt mounted volume (HDD)
c:\mnt\directory (mkdir directory)
c:\mnt\junction_abs (created with junction junction c:\mnt\directory)
c:\mnt\junction (created with junction junction directory from c:\mnt)
Using this script from c:\mnt\test (c:\mnt being a mounted volume):
\php-sdk\snap_5_2\vc6\x86\php52\Debug\php.exe t.php
bool(true)
bool(true)
bool(true)
[2009-08-27 08:42:54] paj...@php.net
"\??\" may be the cause (\\?\ is well documented not \??\). But I
wonder why junction.exe jucntion work just fine on our tests system (xp
and 2k3). Thanks for testing, I go back to code&test.
[2009-08-27 03:40:39] phpstuff at cresstone dot com
>From my testing, this snapshot works for directory junction points
created with mklink. However still no go on mounted volumes or directory
junction points created with junction.exe.
Re-creating any faulting junctions with mklink seems like a good
workaround, but mounted volumes are still left in the cold.
Looking at the output of the dir command, the only visible difference
between mklink and junction.exe is the p
#49340 [Opn]: Signals not catchable when certain functions are in execution
ID: 49340 Updated by: sjo...@php.net Reported By: alexmontoanelli at gmail dot com Status: Open Bug Type: PCNTL related Operating System: Linux PHP Version: 5.2.10 New Comment: PHP signals are implemented with ticks (http://us3.php.net/manual/en/control-structures.declare.php). Ticks are events that occur every so much statements in a script. Since fgets() blocks, no more statements are executed and no more ticks are fired. This means that no signal arrives. I do not know whether the current behavior is by design or by mistake, so I cannot determine whether it is a bug or not. It would certainly be desirable to be able to interrupt a blocking read by doing Ctrl-C. Previous Comments: [2009-08-27 11:28:41] alexmontoanelli at gmail dot com some position ? [2009-08-24 13:04:08] alexmontoanelli at gmail dot com Where I say: 'There is true?', is 'That's true?' Regards [2009-08-24 11:41:59] alexmontoanelli at gmail dot com The problem is that I need hit enter - exit from fgets - to run the signal handler - but this is not the correct way - in python for example, the signal handler are calling when the function are waiting for a user input. I found this page - http://br2.php.net/manual/en/function.pcntl-signal.php - the commentary above: '28-Mar-2006 07:26 Process handling is not available when using a blocking socket! Bear this in mind.' There is true? Regards [2009-08-24 08:54:42] sjo...@php.net Thank you for your bug report. I don't fully understand the problem. Is the problem that you have to hit enter for the signal handler to run? Or that the line with 'echo $foo' is ran after the fgets? [2009-08-23 22:12:28] alexmontoanelli at gmail dot com Description: After executions of certain functions, the handler configured by posix_singal, are not called where the funcion are in execution - like freads. Reproduce code: --- #!/usr/bin/php http://bugs.php.net/?id=49340&edit=1
#27051 [Com]: Impersonation with FastCGI does not EXEC process as impersonated user
ID: 27051 Comment by: nathan at andersonsplace dot net Reported By: ghoffer at globalscape dot com Status: Open Bug Type: Feature/Change Request Operating System: Windows PHP Version: 4.3.4 New Comment: Please note this is still occurring in PHP 5.2 branch. Previous Comments: [2009-06-24 15:12:12] tgross at m-s dot de When will this bug be fixed? I compiled PHP myself an added the fix that ghoffer submitted. The fix works, so would you please add these few lines into PHP? It's a big problem on our servers that impersonation does not work correctly. [2008-12-09 00:45:43] louis at steelbytes dot com I've added a new function to my now inappropriately named 'PHP_Filetimes' http://www.steelbytes.com/?mid=46 (use the *beta* download) The new function is a simple wrapper for CreateProcessAsUser that deals with this problem. come on PHP/Zend pull ya socks up, I shouldn't have to write my own extensions to work around such 'bugs'/limitations :-) [2008-12-08 23:04:23] louis at steelbytes dot com please please please fix/add this. it is killing me with 5.2.6 / win2008. [2007-06-21 18:06:45] aheckmann at m-s dot de I have the same problem here. Has anything happens in the last three years on that feature request? The solution seems to be easy, or not? [2004-01-26 15:41:14] ghoffer at globalscape dot com Description: (Related to Bug #10065, but slightly different and more detailed ) Environment: Win2K3 running PHP 4.3.4 under FastCGI. PHP.INI has "fastcgi.impersonate=1". IIS Site has "Anonymous Access" OFF and "NT Authentication" ON (so that you have to log in to the site as an NT User). Up to this point, all is fine: the NT user is being impersonated by the main thread of PHP so that file access permissions are handled properly. HOWEVER, if the PHP script attempts to execute a command (using exec, or passthru, or similar) then that spawned process is NOT impersonating the NT account, but rather running under the IIS account. SUGGESTED RESOLUTION: in proc_open.c, the proc_open function can make a few calls in lieu of "CreateProcess" in order to "pass along" the Impersonation. Instead of CreateProcess, it should use "CreateProcessAsUser," passing in the token of the impersonated user (which PHP is running under). If it does not do this, per the Win32 API docs, CreateProcess simply uses the non-impersonated token. Here is how to run a spawned process as the impersonated user (which CAN be done conditionally when impersonation is necessary (e.g., "LOGON_USER" is defined; but doing it ALWAYS should in no way impair security, only a slight hit in performance as three additional API calls are made): [ Error checking and variable declarations omitted ] OpenThreadToken( GetCurrentThread(), TOKEN_ALL_ACCESS, TRUE, &hToken ); // get impersonation token DuplicateTokenEx( hToken, MAXIMUM_ALLOWED, &sa, SecurityImpersonation, TokenPrimary, &hToken2 ); // duplicate it for passing to CreateProcessAsUser CreateProcessAsUser( hToken2, ... ) // rest of params are the same as CreateProcess // . . . CloseHandle( hToken2 ); CloseHandle( hToken ); Reproduce code: --- Expected result: PHP running as impersonated user under FastCGI should spawn processes with security context of that impersonated user. Actual result: -- The spawned process is being executed in the security context of the IIS account (IWAM_*). -- Edit this bug report at http://bugs.php.net/?id=27051&edit=1
#49393 [Opn->Fbk]: Comment Block exiting prematurally
ID: 49393
Updated by: sjo...@php.net
Reported By: mudoch at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: Scripting Engine problem
Operating System: Win XPsp3
PHP Version: 5.3.0
New Comment:
Thank you for your bug report.
I was unable to reproduce the bug you described. Are you sure there is
no ?> somewhere in the comment? Did you supplied the right example code?
Is there some non-ASCII character in your file? It may help us if you
put the file up for download somewhere.
Previous Comments:
[2009-08-27 19:00:02] mudoch at gmail dot com
Description:
The comment block /* ... */ will exit at the first > in the block
verses the action in 5.2.5 where the code was written and tested.
Reproduce code:
---
= 2.1
* @package barcode-mribti
* @copyright 2001 Karim Mribti
* @see image.php
* @version $Id$
*
* barcode site home page
* Adapted from 0.0.7a on 2007-05-24 by Frédéric G. MARAND for Agorus
S.A.
*
* May2009 Lawrence Sall - modified for a cleaner fit, adjust util.php
for
* desired defaults.
*
*
*/
include("home.php");
?>
Expected result:
Page in home.php to be displayed
Actual result:
--
= 2.1 * @package barcode-mribti * @copyright 2001 Karim Mribti * @see
image.php * @version $Id$ * * barcode site home page * Adapted from
0.0.7a on 2007-05-24 by Frédéric G. MARAND for Agorus S.A. * * May2009
Lawrence Sall - modified for a cleaner fit, adjust util.php for *
desired defaults. * * */ include("home.php"); ?>
--
Edit this bug report at http://bugs.php.net/?id=49393&edit=1
#49387 [Fbk->Csd]: E_DEPRECATED looks like a fatal error, even off
ID: 49387
User updated by: fernando dot wendt at gmail dot com
Reported By: fernando dot wendt at gmail dot com
-Status: Feedback
+Status: Closed
Bug Type: *Configuration Issues
Operating System: Windows XP
PHP Version: 5.3.0
New Comment:
Ops!
Trying to reproduce it twice, it points me to be working fine :)
Trully, there is a incomplete behavior present at phpPgAdmin (method
"printHeader", that have junt one "if" trying to change document header.
That was why the script seems to be stoping anyway.
Sorry, its all right. Bellows, a little buggy script to confirm this.
foo = 'Something';
}
public function getfoo(){
return($this->foo);
}
}
$data =& new Doit(); //Deprecated issue
echo $data->getfoo;
$xpto = 12; //Logical follows
echo $xpto;
pg_connect();//Missing function data
?>
Previous Comments:
[2009-08-27 16:17:01] sjo...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
[2009-08-27 12:53:36] fernando dot wendt at gmail dot com
Description:
PHP is ignoring the php.ini error_reporting configuration, and is
always hangin up scripts with the E_DEPRACATED message.
The default error_reporting = E_ALL & ~E_DEPRACATED is not working. All
depracated warnings are working as fatal errors, and i believe that was
not the intention it supposed to do.
The only way to avoid this (at least on my workaround) is setting up
the display_errors = Off (even on my workstation).
Reproduce code:
---
Try some script that have depracated function or issue to work. It will
freeze as a fatal error, pointing a depracated message.
Expected result:
First, it should respect the php.ini ~E_DEPRECATED flag and then show
deprecated issues as warnings, not as fatal errors.
Actual result:
--
php.ini ~E_DEPRECATED is not working: his behavior looks like a fatal
error, and is not being respected if is on or off.
--
Edit this bug report at http://bugs.php.net/?id=49387&edit=1
#49393 [NEW]: Comment Block exiting prematurally
From: mudoch at gmail dot com
Operating system: Win XPsp3
PHP version: 5.3.0
PHP Bug Type: Scripting Engine problem
Bug description: Comment Block exiting prematurally
Description:
The comment block /* ... */ will exit at the first > in the block verses
the action in 5.2.5 where the code was written and tested.
Reproduce code:
---
= 2.1
* @package barcode-mribti
* @copyright 2001 Karim Mribti
* @see image.php
* @version $Id$
*
* barcode site home page
* Adapted from 0.0.7a on 2007-05-24 by Frédéric G. MARAND for Agorus
S.A.
*
* May2009 Lawrence Sall - modified for a cleaner fit, adjust util.php
for
* desired defaults.
*
*
*/
include("home.php");
?>
Expected result:
Page in home.php to be displayed
Actual result:
--
= 2.1 * @package barcode-mribti * @copyright 2001 Karim Mribti * @see
image.php * @version $Id$ * * barcode site home page * Adapted from 0.0.7a
on 2007-05-24 by Frédéric G. MARAND for Agorus S.A. * * May2009 Lawrence
Sall - modified for a cleaner fit, adjust util.php for * desired defaults.
* * */ include("home.php"); ?>
--
Edit bug report at http://bugs.php.net/?id=49393&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49393&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49393&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49393&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49393&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49393&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49393&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49393&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49393&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49393&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49393&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49393&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49393&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49393&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49393&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49393&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49393&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49393&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49393&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49393&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49393&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49393&r=mysqlcfg
#49392 [NEW]: Many PHP tests try to verify float to integer overflow result
From: cndougla at linux dot vnet dot ibm dot com Operating system: Any PHP version: 6SVN-2009-08-27 (SVN) PHP Bug Type: Unknown/Other Function Bug description: Many PHP tests try to verify float to integer overflow result Description: Many tests have input values like 10.5e10 that must be converted to integer values. On 32-bit systems, the conversion overflows. According to the PHP manual: --- If the float is beyond the boundaries of integer (usually +/- 2.15e+9 = 2^31), the result is undefined, since the float doesn't have enough precision to give an exact integer result. No warning, not even a notice will be issued when this happens! --- Therefore, the tests are attempting to verify undefined values. Reproduce code: --- We found a bunch of testcases with this issue by running in a ppc64 kernel / ppc32 userspace: ext/standard/tests/array/array_fill_variation1.phpt ext/standard/tests/array/array_keys_variation_002.phpt ext/standard/tests/general_functions/gettype_settype_variation2.phpt ext/standard/tests/strings/htmlspecialchars_decode_variation2.phpt ext/standard/tests/strings/pack.phpt ext/standard/tests/strings/sprintf_variation35.phpt ext/standard/tests/strings/sprintf_variation4.phpt ext/standard/tests/strings/sprintf_variation41.phpt ext/standard/tests/strings/strncasecmp_variation5.phpt ext/standard/tests/strings/strncmp_variation5.phpt ext/standard/tests/strings/strrpos_variation14.phpt ext/standard/tests/strings/strrpos_variation15.phpt ext/standard/tests/strings/vsprintf_variation15.phpt ext/standard/tests/strings/vsprintf_variation16.phpt ext/standard/tests/strings/vsprintf_variation4.phpt We also found the following test had issues on ppc64/ppc64: ext/standard/tests/strings/vsprintf_variation15_64bit.phpt Expected result: These tests should not be checking for the value of the direct or indirect overflow of a float to integer conversion. The tests should have the one or two subtests that do this removed. Actual result: -- The tests fail on some platforms, especially split 64/32-bit installations. -- Edit bug report at http://bugs.php.net/?id=49392&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49392&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49392&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49392&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49392&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49392&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49392&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49392&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49392&r=needscript Try newer version: http://bugs.php.net/fix.php?id=49392&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49392&r=support Expected behavior: http://bugs.php.net/fix.php?id=49392&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49392&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49392&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49392&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49392&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49392&r=dst IIS Stability: http://bugs.php.net/fix.php?id=49392&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49392&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49392&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49392&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49392&r=mysqlcfg
#49391 [Opn]: ldap.c utilizing deprecated ldap_modify_s
ID: 49391 User updated by: thinice at gmail dot com Reported By: thinice at gmail dot com Status: Open Bug Type: LDAP related Operating System: Any PHP Version: 5.3.0 New Comment: ldap_modify_est_s = ldap_modify_ext_s Previous Comments: [2009-08-27 17:27:46] thinice at gmail dot com Description: As per the OpenLDAP documentation here: http://www.openldap.org/software/man.cgi?query=ldap_modify_s&apropos=0&sektion=0&manpath=OpenLDAP+2.4-Release&format=html The basis of most of the ldap functions utilize ldap_modify_s - which is deprecating in favor of ldap_modify_est_s -- Edit this bug report at http://bugs.php.net/?id=49391&edit=1
#49391 [NEW]: ldap.c utilizing deprecated ldap_modify_s
From: thinice at gmail dot com Operating system: Any PHP version: 5.3.0 PHP Bug Type: LDAP related Bug description: ldap.c utilizing deprecated ldap_modify_s Description: As per the OpenLDAP documentation here: http://www.openldap.org/software/man.cgi?query=ldap_modify_s&apropos=0&sektion=0&manpath=OpenLDAP+2.4-Release&format=html The basis of most of the ldap functions utilize ldap_modify_s - which is deprecating in favor of ldap_modify_est_s -- Edit bug report at http://bugs.php.net/?id=49391&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49391&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49391&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49391&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49391&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49391&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49391&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49391&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49391&r=needscript Try newer version: http://bugs.php.net/fix.php?id=49391&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49391&r=support Expected behavior: http://bugs.php.net/fix.php?id=49391&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49391&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49391&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49391&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49391&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49391&r=dst IIS Stability: http://bugs.php.net/fix.php?id=49391&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49391&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49391&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49391&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49391&r=mysqlcfg
#49361 [Com]: wordwrap works incorrectly
ID: 49361
Comment by: code-it at mail dot ru
Reported By: code-it at mail dot ru
Status: Verified
Bug Type: Strings related
Operating System: *
PHP Version: 5.3.0
New Comment:
sjoerd, your example looks very similar to what ive got in my real-life
script when i discovered the problem for the first time. but you missed
one thing
when you use "\n" to wrap strings, there is just a small piece of code
that does all the work in strings.c and the bug can be easy killed with
the patch i provided in my report. but when you try 2+ length strings
instead of "\n", another code works and it works incorrectly too
Previous Comments:
[2009-08-27 16:45:03] sjo...@php.net
Thank you for your bug report.
Your report is too long and too hard to understand. However, I did the
best I could to make a simple script which reproduces the problem you
describe and is more like real-life usage of wordwrap.
Expected:
The quick brown fox just
jumped over the lazy dog
which laid on the ground
Actual:
The quick brown fox just
jumped over the lazy
dog
which laid on the
ground
[2009-08-25 15:58:31] code-it at mail dot ru
Description:
wordwrapping suppose that
wordwrap(wordwrap($s,$n,$d),$n,$d) is equal to wordwrap($s,$n,$d) and
yes, sometimes php works that way:
$s0 = 'a a a a a a a a';
$s1 = wordwrap($s0,7,'XX');
$s2 = wordwrap($s1,7,'XX');
gives $s1==$s2=='a a a aXXa a a a'
but if we add an extra space to the end of $s0, the result will be
'a a a aXXa a a aXX' != 'a a a aXXa a aXXaXX'
if we construct $s0 as (a )+a? we get $s1!=$s2 if and only if
strlen($s0)%8==0. more, the diff between $s1 and $s2 every time is the
same: trailing 'XXaXX' in $s2 instead of ' aXX' in $s1.
now lets take a look at the case of 1-char-length thing as the 3rd
argument to wordwrap
$s0 = 'a a a a a a a a a a a'; // as above, $s0 is constructed as (a
)+a?
$s1 = wordwrap($s0,5,'X');
$s2 = wordwrap($s1,5,'X');
here we only get $s1==$s2 having strlen($s0)<11!
this bug is related to line 828 in
/php-src/branches/PHP_5_3/ext/standard/string.c?revision=287264:
current line: laststart = lastspace = current;
should be: laststart = lastspace = current+1;
+1 is obviuos: if we found a breakchar in the string, we can forget
about everything to the left of it INCLUDING itself and restart the
whole algorythm at the NEXT character as the first character in our new
string. so the very first `laststart = lastspace = 0;` to start becomes
`laststart = lastspace = current+1;` to restart. this patch completely
removes the strange behaviour.
when strlen(3rd argument to wordwrap)>1 another section of code works
and the above patch doesnt affect it
Reproduce code:
---
FAIL\n";
}
if ($k==$n) {
echo "passed all, no fails\n";
}
}
f(5,'X',20);
f(7,'XX',50);
?>
Expected result:
$len=5, $breakstr='X', $n=20 ---
passed all, no fails
$len=7, $breakstr='XX', $n=50 ---
passed all, no fails
Actual result:
--
$len=5, $breakstr='X', $n=20 ---
strlen($s0)=11 -> FAIL
strlen($s0)=12 -> FAIL
strlen($s0)=13 -> FAIL
strlen($s0)=14 -> FAIL
strlen($s0)=15 -> FAIL
strlen($s0)=16 -> FAIL
strlen($s0)=17 -> FAIL
strlen($s0)=18 -> FAIL
strlen($s0)=19 -> FAIL
strlen($s0)=20 -> FAIL
$len=7, $breakstr='XX', $n=50 ---
strlen($s0)=8 -> FAIL
strlen($s0)=16 -> FAIL
strlen($s0)=24 -> FAIL
strlen($s0)=32 -> FAIL
strlen($s0)=40 -> FAIL
strlen($s0)=48 -> FAIL
--
Edit this bug report at http://bugs.php.net/?id=49361&edit=1
#49390 [NEW]: SEGV with zval_ptr_dtor
From: aya at eh dot org Operating system: Linux PHP version: 5.3.0 PHP Bug Type: Reproducible crash Bug description: SEGV with zval_ptr_dtor Description: It seems that zval_ptr_dtor doesn't check if strings are heap-allocated. Reproduce code: --- // Change this to zero to get a SEGV int heapAllocate = 1; // Make a string zval zval* v; MAKE_STD_ZVAL(v); ZVAL_STRING(v, "foo", heapAllocate); // SEGV happens here zval_ptr_dtor(&v); Expected result: Nothing. Actual result: -- php-5.3.0/Zend/zend_execute_API.c(435) : Block 0x004014fa status: php-5.3.0/Zend/zend_variables.c(36) : Actual location (location was relayed) Invalid pointer: ((thread_id=0x74706972) != (expected=0x96F6B8A0)) -- Edit bug report at http://bugs.php.net/?id=49390&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49390&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49390&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49390&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49390&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49390&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49390&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49390&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49390&r=needscript Try newer version: http://bugs.php.net/fix.php?id=49390&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49390&r=support Expected behavior: http://bugs.php.net/fix.php?id=49390&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49390&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49390&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49390&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49390&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49390&r=dst IIS Stability: http://bugs.php.net/fix.php?id=49390&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49390&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49390&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49390&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49390&r=mysqlcfg
#49361 [Opn->Ver]: wordwrap works incorrectly
ID: 49361
Updated by: sjo...@php.net
Reported By: code-it at mail dot ru
-Status: Open
+Status: Verified
Bug Type: Strings related
Operating System: *
PHP Version: 5.3.0
New Comment:
Thank you for your bug report.
Your report is too long and too hard to understand. However, I did the
best I could to make a simple script which reproduces the problem you
describe and is more like real-life usage of wordwrap.
Expected:
The quick brown fox just
jumped over the lazy dog
which laid on the ground
Actual:
The quick brown fox just
jumped over the lazy
dog
which laid on the
ground
Previous Comments:
[2009-08-25 15:58:31] code-it at mail dot ru
Description:
wordwrapping suppose that
wordwrap(wordwrap($s,$n,$d),$n,$d) is equal to wordwrap($s,$n,$d) and
yes, sometimes php works that way:
$s0 = 'a a a a a a a a';
$s1 = wordwrap($s0,7,'XX');
$s2 = wordwrap($s1,7,'XX');
gives $s1==$s2=='a a a aXXa a a a'
but if we add an extra space to the end of $s0, the result will be
'a a a aXXa a a aXX' != 'a a a aXXa a aXXaXX'
if we construct $s0 as (a )+a? we get $s1!=$s2 if and only if
strlen($s0)%8==0. more, the diff between $s1 and $s2 every time is the
same: trailing 'XXaXX' in $s2 instead of ' aXX' in $s1.
now lets take a look at the case of 1-char-length thing as the 3rd
argument to wordwrap
$s0 = 'a a a a a a a a a a a'; // as above, $s0 is constructed as (a
)+a?
$s1 = wordwrap($s0,5,'X');
$s2 = wordwrap($s1,5,'X');
here we only get $s1==$s2 having strlen($s0)<11!
this bug is related to line 828 in
/php-src/branches/PHP_5_3/ext/standard/string.c?revision=287264:
current line: laststart = lastspace = current;
should be: laststart = lastspace = current+1;
+1 is obviuos: if we found a breakchar in the string, we can forget
about everything to the left of it INCLUDING itself and restart the
whole algorythm at the NEXT character as the first character in our new
string. so the very first `laststart = lastspace = 0;` to start becomes
`laststart = lastspace = current+1;` to restart. this patch completely
removes the strange behaviour.
when strlen(3rd argument to wordwrap)>1 another section of code works
and the above patch doesnt affect it
Reproduce code:
---
FAIL\n";
}
if ($k==$n) {
echo "passed all, no fails\n";
}
}
f(5,'X',20);
f(7,'XX',50);
?>
Expected result:
$len=5, $breakstr='X', $n=20 ---
passed all, no fails
$len=7, $breakstr='XX', $n=50 ---
passed all, no fails
Actual result:
--
$len=5, $breakstr='X', $n=20 ---
strlen($s0)=11 -> FAIL
strlen($s0)=12 -> FAIL
strlen($s0)=13 -> FAIL
strlen($s0)=14 -> FAIL
strlen($s0)=15 -> FAIL
strlen($s0)=16 -> FAIL
strlen($s0)=17 -> FAIL
strlen($s0)=18 -> FAIL
strlen($s0)=19 -> FAIL
strlen($s0)=20 -> FAIL
$len=7, $breakstr='XX', $n=50 ---
strlen($s0)=8 -> FAIL
strlen($s0)=16 -> FAIL
strlen($s0)=24 -> FAIL
strlen($s0)=32 -> FAIL
strlen($s0)=40 -> FAIL
strlen($s0)=48 -> FAIL
--
Edit this bug report at http://bugs.php.net/?id=49361&edit=1
#49387 [Opn->Fbk]: E_DEPRECATED looks like a fatal error, even off
ID: 49387 Updated by: sjo...@php.net Reported By: fernando dot wendt at gmail dot com -Status: Open +Status: Feedback Bug Type: *Configuration Issues Operating System: Windows XP PHP Version: 5.3.0 New Comment: Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. Previous Comments: [2009-08-27 12:53:36] fernando dot wendt at gmail dot com Description: PHP is ignoring the php.ini error_reporting configuration, and is always hangin up scripts with the E_DEPRACATED message. The default error_reporting = E_ALL & ~E_DEPRACATED is not working. All depracated warnings are working as fatal errors, and i believe that was not the intention it supposed to do. The only way to avoid this (at least on my workaround) is setting up the display_errors = Off (even on my workstation). Reproduce code: --- Try some script that have depracated function or issue to work. It will freeze as a fatal error, pointing a depracated message. Expected result: First, it should respect the php.ini ~E_DEPRECATED flag and then show deprecated issues as warnings, not as fatal errors. Actual result: -- php.ini ~E_DEPRECATED is not working: his behavior looks like a fatal error, and is not being respected if is on or off. -- Edit this bug report at http://bugs.php.net/?id=49387&edit=1
#49388 [Opn->Ver]: magic_quotes_gpc=on produces deprecated msg on CLI even if error_reporting=0
ID: 49388 Updated by: sjo...@php.net Reported By: romanf at trash dot net -Status: Open +Status: Verified Bug Type: Output Control Operating System: OpenSuse 11 PHP Version: 5.3.0 New Comment: Thank you for your bug report. I could reproduce your problem with the following command: php -d 'error_reporting=0' -d 'magic_quotes_gpc=on' -r '' It seems that PHP is not yet initialized when the warning is triggered. When it is not initialized it prints all warnings without taking error_reporting into account (module_initialized is 0 on main/main.c:920). Previous Comments: [2009-08-27 14:14:49] romanf at trash dot net Description: I have a php.ini with error_reporting=0 magic_quotes_gpc=on If I run a test-script on the CLI, the deprecated warning is still shown on stderr. When run under a webserver (e.g. apache) no output is produced. Expected result: Deprecated warning should be suppressed on CLI as well if error_reporting=0. Actual result: -- Deprecated warning is NOT suppressed on CLI (and only on CLI) if magic_quotes_gpc=on regardless of error_reporting. -- Edit this bug report at http://bugs.php.net/?id=49388&edit=1
#49389 [Opn->Bgs]: Load error
ID: 49389 Updated by: der...@php.net Reported By: J dot de dot Vries-eej at kpnplanet dot nl -Status: Open +Status: Bogus Bug Type: Dynamic loading Operating System: Windows PHP Version: 5.2.10 New Comment: 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. . Previous Comments: [2009-08-27 15:09:13] J dot de dot Vries-eej at kpnplanet dot nl Description: The page takes ages to load it's because we upgraded to php5 that it came to excistence Reproduce code: --- http://textsave.de/?p=21350 It's missing this part on the top http://bugs.php.net/?id=49389&edit=1
#49389 [NEW]: Load error
From: J dot de dot Vries-eej at kpnplanet dot nl Operating system: Windows PHP version: 5.2.10 PHP Bug Type: Dynamic loading Bug description: Load error Description: The page takes ages to load it's because we upgraded to php5 that it came to excistence Reproduce code: --- http://textsave.de/?p=21350 It's missing this part on the top http://bugs.php.net/?id=49389&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49389&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49389&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49389&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49389&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49389&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49389&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49389&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49389&r=needscript Try newer version: http://bugs.php.net/fix.php?id=49389&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49389&r=support Expected behavior: http://bugs.php.net/fix.php?id=49389&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49389&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49389&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49389&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49389&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49389&r=dst IIS Stability: http://bugs.php.net/fix.php?id=49389&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49389&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49389&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49389&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49389&r=mysqlcfg
#49388 [NEW]: magic_quotes_gpc=on produces deprecated msg on CLI even if error_reporting=0
From: romanf at trash dot net Operating system: OpenSuse 11 PHP version: 5.3.0 PHP Bug Type: Output Control Bug description: magic_quotes_gpc=on produces deprecated msg on CLI even if error_reporting=0 Description: I have a php.ini with error_reporting=0 magic_quotes_gpc=on If I run a test-script on the CLI, the deprecated warning is still shown on stderr. When run under a webserver (e.g. apache) no output is produced. Expected result: Deprecated warning should be suppressed on CLI as well if error_reporting=0. Actual result: -- Deprecated warning is NOT suppressed on CLI (and only on CLI) if magic_quotes_gpc=on regardless of error_reporting. -- Edit bug report at http://bugs.php.net/?id=49388&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49388&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49388&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49388&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49388&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49388&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49388&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49388&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49388&r=needscript Try newer version: http://bugs.php.net/fix.php?id=49388&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49388&r=support Expected behavior: http://bugs.php.net/fix.php?id=49388&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49388&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49388&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49388&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49388&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49388&r=dst IIS Stability: http://bugs.php.net/fix.php?id=49388&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49388&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49388&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49388&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49388&r=mysqlcfg
#49027 [Ver->Csd]: mysqli_options() doesn't work when using mysqlnd
ID: 49027 Updated by: and...@php.net Reported By: andreas dot streichardt at globalpark dot com -Status: Verified +Status: Closed Bug Type: MySQLi related Operating System: Linux PHP Version: 5.3.0 Assigned To: mysql New Comment: This bug has been fixed in SVN. 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/. Thank you for the report, and for helping us make PHP better. Fix will appear in 5.3.1 Thanks! Previous Comments: [2009-08-27 13:16:40] s...@php.net Automatic comment from SVN on behalf of andrey Revision: http://svn.php.net/viewvc/?view=revision&revision=287807 Log: Fixed bug #49027 (mysqli_options() doesn't work when using mysqlnd) [2009-08-06 00:38:40] ka...@php.net The INIT_COMMAND is currently not supported by mysqlnd, along with a bunch of other options, see ext/mysqlnd/mysqlnd.c. Leaving this with the mysql guys [2009-07-23 09:07:38] andreas dot streichardt at globalpark dot com Description: mysqli_real_connect() doesn't honor init commands previously set with mysqli_options($x,MYSQLI_INIT_COMMAND) when using the mysqlnd driver. I am not sure if this is simply a missing feature or a bug. At least this is a documentation problem as it isn't noted anywhere. Ideally if this is not a bug mysqli_options should return false so one notices that it isn't supported yet. This problem only appears when using mysqlnd as the driver. mysql> SELECT version(); ++ | version() | ++ | 5.4.1-beta-log | ++ But i don't think this is related to the database version, is it? Reproduce code: --- $handle=mysqli_init(); if (!mysqli_options($handle,MYSQLI_INIT_COMMAND,"testtest")) print "Broken!\n"; if (!...@mysqli_real_connect($handle,"localhost","root","","test",3306)) print "Connection broken!\n"; Expected result: Connection broken! (testtest is not a valid query) If the general log is activated you should see the query in the log Actual result: -- blank output (database connection was successful - assuming that the credentials provided in the connection string work). no "testtest" query in the general log -- Edit this bug report at http://bugs.php.net/?id=49027&edit=1
#49387 [NEW]: E_DEPRECATED looks like a fatal error, even off
From: fernando dot wendt at gmail dot com Operating system: Windows XP PHP version: 5.3.0 PHP Bug Type: *Configuration Issues Bug description: E_DEPRECATED looks like a fatal error, even off Description: PHP is ignoring the php.ini error_reporting configuration, and is always hangin up scripts with the E_DEPRACATED message. The default error_reporting = E_ALL & ~E_DEPRACATED is not working. All depracated warnings are working as fatal errors, and i believe that was not the intention it supposed to do. The only way to avoid this (at least on my workaround) is setting up the display_errors = Off (even on my workstation). Reproduce code: --- Try some script that have depracated function or issue to work. It will freeze as a fatal error, pointing a depracated message. Expected result: First, it should respect the php.ini ~E_DEPRECATED flag and then show deprecated issues as warnings, not as fatal errors. Actual result: -- php.ini ~E_DEPRECATED is not working: his behavior looks like a fatal error, and is not being respected if is on or off. -- Edit bug report at http://bugs.php.net/?id=49387&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49387&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49387&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49387&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49387&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49387&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49387&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49387&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49387&r=needscript Try newer version: http://bugs.php.net/fix.php?id=49387&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49387&r=support Expected behavior: http://bugs.php.net/fix.php?id=49387&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49387&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49387&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49387&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49387&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49387&r=dst IIS Stability: http://bugs.php.net/fix.php?id=49387&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49387&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49387&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49387&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49387&r=mysqlcfg
#46614 [Asn->Csd]: Extended MySQLi class gives incorrect empty() result (works in PHP_5_2 !)
ID: 46614
Updated by: and...@php.net
Reported By: sander dot vink at procurios dot nl
-Status: Assigned
+Status: Closed
Bug Type: MySQLi related
Operating System: *
PHP Version: 5.3CVS-2008-11-19 (snap)
Assigned To: mysql
New Comment:
This bug has been fixed in SVN.
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/.
Thank you for the report, and for helping us make PHP better.
The fix will be in 5.3.1
Previous Comments:
[2009-08-27 12:41:14] s...@php.net
Automatic comment from SVN on behalf of andrey
Revision: http://svn.php.net/viewvc/?view=revision&revision=287806
Log: Fix for bug#46614 Extended MySQLi class gives incorrect empty()
result
[2008-11-21 13:05:31] j...@php.net
Ah, I tested with PHP 5.2CVS and it works as expected. So this is
PHP_5_3 (and propably HEAD) issue only.
[2008-11-20 08:14:13] sander dot vink at procurios dot nl
Yes, exactly, it is not empty. However, I return the result of empty()
( not !empty() ) which should be false, since the array actually
contains data.
[2008-11-19 23:12:58] j...@php.net
You set $this->fooData[]to contain 'Bar' -> it's not empty -> returns
true..what's the bug..?
[2008-11-19 13:25:11] sander dot vink at procurios dot nl
Description:
When an empty() call is done within a class that extends the MySQLi
class, an incorrect result is provided.
Reproduce code:
---
class Foo extends MySQLi
{
protected $fooData = array();
public function isEmpty()
{
$this->fooData[] = 'Bar';
return empty($this->fooData);
}
}
$Foo = new Foo('localhost', 'root', '', 'test');
$isEmpty = $Foo->isEmpty();
var_dump($isEmpty);
Expected result:
bool(false)
Actual result:
--
bool(true)
--
Edit this bug report at http://bugs.php.net/?id=46614&edit=1
#41342 [Com]: PHP says syntax errors are 200 OK
ID: 41342 Comment by: steffen at steffen-gebert dot de Reported By: defenestrator at gmail dot com Status: Open Bug Type: Feature/Change Request Operating System: FreeBSD PHP Version: 5.2.2 New Comment: I have display_errors off and I also get code 200 (on syntax errors, undefined functions, ..). Please.. really sent 500 here! Previous Comments: [2009-03-17 18:45:53] php at plummer dot us I just want to be able to notify people of errors. With syntax errors, I can't use php code to do so and the web server doesn't know there's been a problem when a 200 response is returned so I can't use its error reporting capabilities. Basically it violates the http rfc to return a 200 on an error response. [2008-11-30 00:02:19] defenestrator at gmail dot com I need display_errors on in development environments, which is where the 200 OK response is causing the inconvenience for me in the first place. If I make an AJAX request to a PHP file that produces an error, then I can correct the error but any further requests to the same URL are pulled out of the browser cache, with no direct way to refresh it. Many workarounds exist but none should be necessary. There really isn't any benefit to *not* producing a 500 error here. [2008-11-06 17:54:34] j...@php.net Already happens, as long as display_errors = off. [2007-05-09 23:11:30] defenestrator at gmail dot com Description: When there is a syntax error in a PHP file, PHP sends back a 200 OK response without any caching headers. This results in browsers such as IE or Opera caching the resulting error, which can hinder debugging in some cases. For example, an XMLHttpRequest to a faulty script can't be easily force-refreshed from a browser. I'd prefer for PHP to produce a 500 error in this case. Alternatively, if you must produce a 200, then sending some headers to inhibit caching will solve the problem as well. Reproduce code: --- Expected result: HTTP/1.1 500 Internal Server Error ... Content-Length: 144 Content-Type: text/html Parse error: syntax error, unexpected '<' ... Actual result: -- HTTP/1.1 200 OK ... Content-Length: 144 Content-Type: text/html Parse error: syntax error, unexpected '<' ... -- Edit this bug report at http://bugs.php.net/?id=41342&edit=1
#49340 [Opn]: Signals not catchable when certain functions are in execution
ID: 49340 User updated by: alexmontoanelli at gmail dot com Reported By: alexmontoanelli at gmail dot com Status: Open Bug Type: PCNTL related Operating System: Linux PHP Version: 5.2.10 New Comment: some position ? Previous Comments: [2009-08-24 13:04:08] alexmontoanelli at gmail dot com Where I say: 'There is true?', is 'That's true?' Regards [2009-08-24 11:41:59] alexmontoanelli at gmail dot com The problem is that I need hit enter - exit from fgets - to run the signal handler - but this is not the correct way - in python for example, the signal handler are calling when the function are waiting for a user input. I found this page - http://br2.php.net/manual/en/function.pcntl-signal.php - the commentary above: '28-Mar-2006 07:26 Process handling is not available when using a blocking socket! Bear this in mind.' There is true? Regards [2009-08-24 08:54:42] sjo...@php.net Thank you for your bug report. I don't fully understand the problem. Is the problem that you have to hit enter for the signal handler to run? Or that the line with 'echo $foo' is ran after the fgets? [2009-08-23 22:12:28] alexmontoanelli at gmail dot com Description: After executions of certain functions, the handler configured by posix_singal, are not called where the funcion are in execution - like freads. Reproduce code: --- #!/usr/bin/php http://bugs.php.net/?id=49340&edit=1
#49386 [Opn->Bgs]: foreach with reference causes funny behaviour
ID: 49386 Updated by: col...@php.net Reported By: ingo dot aengenheister at gmx dot de -Status: Open +Status: Bogus Bug Type: Scripting Engine problem Operating System: Windows Vista PHP Version: 5.3.0 New Comment: 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. foreach by ref will not delete the reference after foreach is finished, meaning $b is still a ref to the last element after the first foreach, which you then overwrite with the values of the second array. Previous Comments: [2009-08-27 11:38:36] ingo dot aengenheister at gmx dot de Description: is it a bug or a feature ? Reproduce code: --- Expected result: abcde Actual result: -- abcdd -- Edit this bug report at http://bugs.php.net/?id=49386&edit=1
#49386 [NEW]: foreach with reference causes funny behaviour
From: ingo dot aengenheister at gmx dot de Operating system: Windows Vista PHP version: 5.3.0 PHP Bug Type: Scripting Engine problem Bug description: foreach with reference causes funny behaviour Description: is it a bug or a feature ? Reproduce code: --- Expected result: abcde Actual result: -- abcdd -- Edit bug report at http://bugs.php.net/?id=49386&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49386&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49386&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49386&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49386&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49386&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49386&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49386&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49386&r=needscript Try newer version: http://bugs.php.net/fix.php?id=49386&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49386&r=support Expected behavior: http://bugs.php.net/fix.php?id=49386&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49386&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49386&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49386&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49386&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49386&r=dst IIS Stability: http://bugs.php.net/fix.php?id=49386&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49386&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49386&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49386&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49386&r=mysqlcfg
#46858 [Asn->Bgs]: Incorrect isset result on MySQLi_Result properties (only in PHP_5_2)
ID: 46858
Updated by: and...@php.net
Reported By: eric at livejournal dot dk
-Status: Assigned
+Status: Bogus
Bug Type: MySQLi related
Operating System: *
PHP Version: 5.2.9
Assigned To: andrey
New Comment:
Interesting,
I find this bogus, as if the query has failed $result won't be an
object but a boolean value.
Here is the real bug, a Zend Engine bug:
and...@winnie:/work/mysql-server/mysql-5.1/sql$ php -r
'$a=true;var_dump($a);var_dump(isset($a->b));'
bool(true)
bool(false)
It doesn't fail although $a is not an object.
Previous Comments:
[2009-04-13 17:26:22] j...@php.net
Andrey, any possibility to fix this also in PHP_5_2 ?
(See bug #44352)
[2008-12-31 16:11:47] eric at livejournal dot dk
The property doesn't exist if the query failed. I realise I could
simply check the error member, but I figured I'd still report it because
IMO a bug exists - isset incorrectly returns false.
[2008-12-18 15:28:28] j...@php.net
Why do you test if that property exists anyway? It's always there, you
don't need to test for that. :)
[2008-12-13 16:46:02] eric at livejournal dot dk
Description:
isset returns false when applied to a MySQLi_result object that does
indeed exist.
Reproduce code:
---
query('SELECT * FROM test;'); //contains 1 row
echo $result->num_rows;
if (isset($result->num_rows))
echo 'defined';
else
echo 'undefined';
?>
Expected result:
1defined
Actual result:
--
1undefined
--
Edit this bug report at http://bugs.php.net/?id=46858&edit=1
#44998 [Asn->Bgs]: mysqli_real_escape_string() not properly escaping null characters
ID: 44998
Updated by: and...@php.net
Reported By: djneoform at gmail dot com
-Status: Assigned
+Status: Bogus
Bug Type: MySQLi related
Operating System: Win2003 Standard
PHP Version: 5.2.6
Assigned To: andrey
New Comment:
Hi, this is not a bug. Seems like, but it is a feature of MySQL's
BINARY data type.
http://dev.mysql.com/doc/refman/5.0/en/binary-varbinary.html reads :
---
When BINARY values are stored, they are right-padded with the pad
value to the specified length. The pad value and how it is handled is
version specific:
- As of MySQL 5.0.15, the pad value is 0x00 (the zero byte). Values are
right-padded with 0x00 on insert, and no trailing bytes are removed on
select. All bytes are significant in comparisons, including ORDER BY and
DISTINCT operations. 0x00 bytes and spaces are different in comparisons,
with 0x00 < space.
Example: For a BINARY(3) column, 'a ' becomes 'a \0' when inserted.
'a\0' becomes 'a\0\0' when inserted. Both inserted values remain
unchanged when selected.
-Before MySQL 5.0.15, the pad value is space. Values are right-padded
with space on insert, and trailing spaces are removed on select.
Trailing spaces are ignored in comparisons, including ORDER BY and
DISTINCT operations. 0x00 bytes and spaces are different in comparisons,
with 0x00 < space.
Example: For a BINARY(3) column, 'a ' becomes 'a ' when inserted and
'a' when selected. 'a\0' becomes 'a\0 ' when inserted and 'a\0' when
selected.
-
The \0 byte in the between is not lost, I see it from the network dump,
but \0 has no visual representation when dumped to screen, thus we see
nothing inbetween.
Previous Comments:
[2008-10-21 00:38:51] ian at city17 dot ca
Experienced the same thing when storing files in mysql. Many files end
up corrupt since the file ends before it was supposed to.
[2008-07-24 14:23:20] djneoform at gmail dot com
The resulting dump for the table once i run the script.
/*
MySQL Data Transfer
Source Host: localhost
Source Database: phpneoform
Target Host: localhost
Target Database: phpneoform
Date: 7/24/2008 10:22:31 AM
*/
SET FOREIGN_KEY_CHECKS=0;
--
-- Table structure for test_table
--
CREATE TABLE `test_table` (
`id` int(10) unsigned NOT NULL auto_increment,
`name` binary(100) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM AUTO_INCREMENT=2 DEFAULT CHARSET=latin1;
--
-- Records
--
INSERT INTO `test_table` VALUES ('1', 'A');
[2008-07-24 14:20:36] djneoform at gmail dot com
Results:
TEST STRING LENGTH: 51
RETURNED STRING LENGTH: 100
[2008-07-24 14:19:36] djneoform at gmail dot com
http://phpneoform.com/error.php
Here's this script running on a win2k3 server with PHP 5.2.6 and mysql
5.0.62
query("DROP TABLE IF EXISTS `test_table`");
$mysqli->query("
CREATE TABLE `test_table` (
`id` int(10) unsigned NOT NULL auto_increment,
`name` binary(100) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;
");
$str = str_repeat('A', 25).chr(0x0).str_repeat('B', 25);
echo "TEST STRING LENGTH: ".strlen($str)."\n";
$mysqli->query("
INSERT INTO
`test_table`
SET
`name` = '".$mysqli->real_escape_string($str)."'
");
$id = $mysqli->insert_id;
$result = $mysqli->query("
SELECT
name
FROM
`test_table`
WHERE
id = '".intval($id)."'
");
$result = $result->fetch_object();
echo "RETURNED STRING LENGTH: ".strlen($result->name)."\n";
?>
[2008-07-24 13:37:53] and...@php.net
Hi,
Do you still experience it?
Can you reproduce it with a simple script?
Can you provide a dump or just the data, index + frm, considering you
are using MyISAM?
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/44998
--
Edit this bug report at http://bugs.php.net/?id=44998&edit=1
#45468 [Asn->Csd]: Using mysqlnd defaults to using unix socket instead of localhost:port
ID: 45468
Updated by: and...@php.net
Reported By: michael dot kofler at gmx dot com
-Status: Assigned
+Status: Closed
Bug Type: MySQL related
Operating System: * (not win32)
PHP Version: 5.3CVS, 6CVS (2009-04-25)
Assigned To: johannes
New Comment:
Closing this, as not a bug anymore
Previous Comments:
[2009-08-27 10:26:20] and...@php.net
Jani,
I think you are wrong :
and...@winnie:/work/vanilla/php/php-src/branches/PHP_5_3$ ./php -r
'$c=mysql_connect("localhost:3307");var_dump($c,
$res=mysql_query("select 42", $c), mysql_fetch_assoc($res));'
Warning: mysql_connect(): Can't connect to local MySQL server through
socket '/var/run/mysqld/mysqld.sock' (2) in Command line code on line 1
Warning: mysql_query() expects parameter 2 to be resource, boolean
given in Command line code on line 1
Warning: mysql_fetch_assoc() expects parameter 1 to be resource, null
given in Command line code on line 1
bool(false)
NULL
NULL
---
My MySQL runs on 3307 and the socket it uses is /tmp/mysql.sock. I have
a /etc/my.cnf, that specifies /var/run/mysqld/mysqld.sock, and the
client tries to use it. So you see, if you specify localhost this means
- use unix socket, no matter if there is a port or not. mysqlnd does the
same. Same is valid if you try mysql --host localhost --port=3307 . I
suppose in your case you had mysql running with socket which you was
where expected.
[2009-04-26 15:27:11] j...@php.net
This is clearly a bug:
# sapi/cli/php -n -r 'mysql_connect("localhost:3306");'
Output with --with-mysql=mysqlnd:
Warning: mysql_connect(): [2002] No such file or directory (trying to
connect via unix:///tmp/mysql.sock) in Command line code on line 1
# sapi/cli/php -n -r 'mysql_connect("localhost:3306");'
No output (error) --with-mysql (without mysqlnd) -> connection works.
The problem is with code in ext/mysqlnd/mysqlnd.c:537-543 which forces
using the socket in this case.
Note: Same happens with mysqli. This bug also makes all mysql(i) tests
fail unless one uses some environment variables while running them.
[2009-02-03 11:59:28] and...@php.net
Hi,
it was a problem, the Unix path, in the extensions, not mysqlnd. Yes,
mysqlnd uses /tmp/mysql.sock, but actually there are no configure
options for mysqlnd. --with-mysql-sock is actually an option of
ext/mysql . It wasn't used in the past, as far as I recall, but current
5_3 and HEAD do use it to set default value for the socket path, which
can be overwritten by the user. Both for ext/mysql and mysqli.
This if from ext/mysql/php_mysql.c :
#ifdef MYSQL_UNIX_ADDR
STD_PHP_INI_ENTRY("mysql.default_socket",
MYSQL_UNIX_ADDR,PHP_INI_ALL,OnUpdateStringUnempty, default_socket,
zend_mysql_globals, mysql_globals)
#else
STD_PHP_INI_ENTRY("mysql.default_socket", NULL,
PHP_INI_ALL,OnUpdateStringUnempty, default_socket,
zend_mysql_globals, mysql_globals)
#endif
This is from ext/mysqli/mysql.c :
#ifdef PHP_MYSQL_UNIX_SOCK_ADDR
STD_PHP_INI_ENTRY("mysqli.default_socket",
MYSQL_UNIX_ADDR,PHP_INI_ALL,OnUpdateStringUnempty, default_socket,
zend_mysqli_globals,mysqli_globals)
#else
STD_PHP_INI_ENTRY("mysqli.default_socket", NULL,
PHP_INI_ALL,OnUpdateStringUnempty, default_socket,
zend_mysqli_globals,mysqli_globals)
#endif
MYSQL_UNIX_ADDR is a macro, for PHP_MYSQL_UNIX_ADDR, which is defined
by the configure script if --with-mysql-sock is used.
In this regard, PDO doesn't use --with-mysql-sock. PDO_MYSQL used
mysql_config to find the socket, but for mysqln defaults to
/tmp/mysql.sock , which seems like bug, because of inconsistency.
This is something for Johannes
Best,
Andrey
[2009-02-03 11:43:38] johan...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
--with-mysql-sock should work now properly
[2008-08-07 08:01:44] michael dot kofler at gmx dot com
re-tested on Linux with alpha1, compiled with this configuration:
configure --with-mysqli=mysqlnd \
--with-mysql=mysqlnd \
--with-mysql-sock=/var/run/mysqld/mysqld.sock \
--enable-pdo \
--with-pdo-mysql=mysqlnd \
--with-apxs2=/usr/bin/apxs2 \
--with-zlib \
--with-gd \
--with-config-file-scan-dir=/etc/php5/apache2 \
--with-jpeg-dir=/usr/lib \
--enable-exif \
--libdir=/usr/lib \
--enable-mbstring
also tried
--with-mysql-sock=/var/run/m
#45468 [Asn]: Using mysqlnd defaults to using unix socket instead of localhost:port
ID: 45468
Updated by: and...@php.net
Reported By: michael dot kofler at gmx dot com
Status: Assigned
Bug Type: MySQL related
Operating System: * (not win32)
PHP Version: 5.3CVS, 6CVS (2009-04-25)
Assigned To: johannes
New Comment:
Jani,
I think you are wrong :
and...@winnie:/work/vanilla/php/php-src/branches/PHP_5_3$ ./php -r
'$c=mysql_connect("localhost:3307");var_dump($c,
$res=mysql_query("select 42", $c), mysql_fetch_assoc($res));'
Warning: mysql_connect(): Can't connect to local MySQL server through
socket '/var/run/mysqld/mysqld.sock' (2) in Command line code on line 1
Warning: mysql_query() expects parameter 2 to be resource, boolean
given in Command line code on line 1
Warning: mysql_fetch_assoc() expects parameter 1 to be resource, null
given in Command line code on line 1
bool(false)
NULL
NULL
---
My MySQL runs on 3307 and the socket it uses is /tmp/mysql.sock. I have
a /etc/my.cnf, that specifies /var/run/mysqld/mysqld.sock, and the
client tries to use it. So you see, if you specify localhost this means
- use unix socket, no matter if there is a port or not. mysqlnd does the
same. Same is valid if you try mysql --host localhost --port=3307 . I
suppose in your case you had mysql running with socket which you was
where expected.
Previous Comments:
[2009-04-26 15:27:11] j...@php.net
This is clearly a bug:
# sapi/cli/php -n -r 'mysql_connect("localhost:3306");'
Output with --with-mysql=mysqlnd:
Warning: mysql_connect(): [2002] No such file or directory (trying to
connect via unix:///tmp/mysql.sock) in Command line code on line 1
# sapi/cli/php -n -r 'mysql_connect("localhost:3306");'
No output (error) --with-mysql (without mysqlnd) -> connection works.
The problem is with code in ext/mysqlnd/mysqlnd.c:537-543 which forces
using the socket in this case.
Note: Same happens with mysqli. This bug also makes all mysql(i) tests
fail unless one uses some environment variables while running them.
[2009-02-03 11:59:28] and...@php.net
Hi,
it was a problem, the Unix path, in the extensions, not mysqlnd. Yes,
mysqlnd uses /tmp/mysql.sock, but actually there are no configure
options for mysqlnd. --with-mysql-sock is actually an option of
ext/mysql . It wasn't used in the past, as far as I recall, but current
5_3 and HEAD do use it to set default value for the socket path, which
can be overwritten by the user. Both for ext/mysql and mysqli.
This if from ext/mysql/php_mysql.c :
#ifdef MYSQL_UNIX_ADDR
STD_PHP_INI_ENTRY("mysql.default_socket",
MYSQL_UNIX_ADDR,PHP_INI_ALL,OnUpdateStringUnempty, default_socket,
zend_mysql_globals, mysql_globals)
#else
STD_PHP_INI_ENTRY("mysql.default_socket", NULL,
PHP_INI_ALL,OnUpdateStringUnempty, default_socket,
zend_mysql_globals, mysql_globals)
#endif
This is from ext/mysqli/mysql.c :
#ifdef PHP_MYSQL_UNIX_SOCK_ADDR
STD_PHP_INI_ENTRY("mysqli.default_socket",
MYSQL_UNIX_ADDR,PHP_INI_ALL,OnUpdateStringUnempty, default_socket,
zend_mysqli_globals,mysqli_globals)
#else
STD_PHP_INI_ENTRY("mysqli.default_socket", NULL,
PHP_INI_ALL,OnUpdateStringUnempty, default_socket,
zend_mysqli_globals,mysqli_globals)
#endif
MYSQL_UNIX_ADDR is a macro, for PHP_MYSQL_UNIX_ADDR, which is defined
by the configure script if --with-mysql-sock is used.
In this regard, PDO doesn't use --with-mysql-sock. PDO_MYSQL used
mysql_config to find the socket, but for mysqln defaults to
/tmp/mysql.sock , which seems like bug, because of inconsistency.
This is something for Johannes
Best,
Andrey
[2009-02-03 11:43:38] johan...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
--with-mysql-sock should work now properly
[2008-08-07 08:01:44] michael dot kofler at gmx dot com
re-tested on Linux with alpha1, compiled with this configuration:
configure --with-mysqli=mysqlnd \
--with-mysql=mysqlnd \
--with-mysql-sock=/var/run/mysqld/mysqld.sock \
--enable-pdo \
--with-pdo-mysql=mysqlnd \
--with-apxs2=/usr/bin/apxs2 \
--with-zlib \
--with-gd \
--with-config-file-scan-dir=/etc/php5/apache2 \
--with-jpeg-dir=/usr/lib \
--enable-exif \
--libdir=/usr/lib \
--enable-mbstring
also tried
--with-mysql-sock=/var/run/mysqld \
result: mysql, mysqli and PDO/mysql, all using mysqlnd, still look for
the socket file /tmp/mysql.sock and ignore --with-mysql-sock
if I compile without mysqlnd and
#44942 [Com]: exec() hangs apache
ID: 44942
Comment by: listephp at andrioli dot com
Reported By: inqualab1985 at gmail dot com
Status: No Feedback
Bug Type: Program Execution
Operating System: Windows 2000 SP4
PHP Version: 5.2.5
New Comment:
I've the same problem too.
I tried the latest snapshot 5.2.11RC2-dev build date: Aug 26 2009
23:42:35 , but it shows up.
Configuration
- Windows 2003 R2
- Apache 2.2.11
Both, exec() running java.exe and system() running .NET program, hang
Apache as described above.
Previous Comments:
[2009-06-08 16:41:29] alex at bartl dot net
Reproducable with PHP 5.2.9-1 on Windows2003 Server with Apache2.2
Workaround with calling session_write_close() before calling exec()
confirmed working
NOT reproducable with PHP 5.2.1 on Windows 2000 Server with IIS5
anyway, seems to be a duplicate of Bug#44994
[2009-04-07 15:12:50] gouldee at netscape dot com
I am having the same or similar issue:
OS: MS2003
PHP: 5.2.6
APACHE2: 2.2
The bug occurs with an PHP script that has a PHP passthru exec call
that hangs every now and then. After the first hang occurs then any
passthru call hangs in the same manner.
I believe that the passthru call runs as I am calling a sendmail.exe
process that does send the E-Mail, however, the Browser page hangs after
the E-Mail has been sent by sendmail.exe called via passthru().
There are no PHP or Apache2 errors or warnings. It seems that the
problem happens when (2) calls to the same .exe happens at the same
time, but, I have no real proof of this, as I can't provide execution
times for each instance of the sendmail.exe running.
This is a serious problem, as all pages that call an .exe process after
the initial hang will hang up as well. I can clear the bug by simply
stopping and restarting the Apache service.
I also note that If I run the page, that hangs up, manually in a
Command Prompt DOS window like: D:\php page.php there are no hangs and
the process performs correctly even during and after the first showing
of the bug. So the problem seems to be when PHP does an exec call in
conjunction with Apache, as I said even during the time a hang occurs I
can still exec passthru commands from a command prompt.
I can also run any page that calls PHP as long as the page does not
have any exec or passthru calls in it, and all pages with HTML only runs
fine as well during the hang period.
[2009-02-26 15:14:32] frase at cs dot wisc dot edu
This is happening to me as well, PHP 5.2.8, Apache 2.2.11, Windows 2000
Pro SP4.
However, it only seems to happen when PHP is configured as an Apache
module (php5apache2_2.dll); when I configure it as CGI, it works fine.
I also have anecdotal evidence that it's related somehow to other
sockets being open on the system. In my case, we have a VB (compiled)
application with an embedded IE control, and also opens the serial port
to communicate with some hardware. If that hardware is plugged in (and
PHP is loaded as a module), then our scripts hang at 'exec("ping -n 1
somehost")'. If I unplug the hardware (so the serial port can't be
opened), it works.
[2009-02-17 10:12:38] russell_anam at hotmail dot com
I can indeed confirm that this bug exists in the latest PHP version
(PHP 5.2.8). exec() would randomly hang the Apache and the only solution
was to restart the whole server (service restart did not help). I can
also confirm that vlabella's solution INDEED worked for us. Since this
workaround works I think it's safe to say this is indeed a PHP bug that
needs to be fixed ASAP.
[2009-01-29 18:21:30] rolinger1 at hotmail dot com
I came across this article searching for a similar problem. I am using
Perl 5.10 though but am having the same issue with Apache 2.2. That
being said, I believe the issues are the same and that the problem is
with Apache and not php or perl.
With Perl I do a backtick call and Apache's CGI hangs. The windows
system processes shows 1 cmd running and 1 perl app running for each
time I click on the called web script.
Perl call:
@files = `dir ../configs /0:D /A:-D` ;
Somehow, apache uses the backtick command to launch a "cmd" console
process which in turn executes the system call "dir..."
I say the Apache CGI hangs because other PHP scripts (that don't do
system calls) all still seem to work. But after the first CGI hang, all
other Perl calls hang - even scripts that don't have system calls in
them. Scripts with system calls load another pair of cmd/perl processes
and return no data, scripts without system calls loads another perl
process but does return data.
After the initial hang tho
#49384 [NEW]: preg_match incorreclty matching vertical tab character
From: soham dot mehta at gmail dot com
Operating system: x86_64 GNU/Linux
PHP version: 5.2.10
PHP Bug Type: PCRE related
Bug description: preg_match incorreclty matching vertical tab character
Description:
In preg_match (and preg_replace), vertical tab character matches
characters other than itself. At the least, it matches ascii 10,11,12,13
and 133, when it should only match 11.
(Vertical tab has been nixed from PCRE - is that the cause?)
Reproduce code:
---
$wrong = chr(133); //can use any of 10,12,13 or 133
$x = preg_match('/\v/', $wrong, $matches, PREG_OFFSET_CAPTURE);
var_dump($matches);
$right = chr(11);
$x = preg_match('/\v/', $right, $matches, PREG_OFFSET_CAPTURE);
var_dump($matches);
Expected result:
array
empty
array
0 =>
array
0 => string ' ' (length=1)
1 => int 0
Actual result:
--
array
0 =>
array
0 => string '�' (length=1)
1 => int 0
array
0 =>
array
0 => string ' ' (length=1)
1 => int 0
--
Edit bug report at http://bugs.php.net/?id=49384&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49384&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49384&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49384&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49384&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49384&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49384&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49384&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49384&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49384&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49384&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49384&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49384&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49384&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49384&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49384&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49384&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49384&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49384&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49384&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49384&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49384&r=mysqlcfg
#48746 [Asn->Fbk]: Unable to browse directories within Junction Points
ID: 48746
Updated by: paj...@php.net
Reported By: ddkees at illinois dot edu
-Status: Assigned
+Status: Feedback
Bug Type: Directory function related
Operating System: win32 only - Windows Server 2003
PHP Version: 5.3.0
Assigned To: pajoye
New Comment:
And confirmed your last cases using Win7/Vista/2k8. In this case
junction are prepended with \??\. Fix applied, the next snap should
have it.
Previous Comments:
[2009-08-27 09:39:02] s...@php.net
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revision&revision=287800
Log: - Fix for #48746, fix mounted volume and junctions when used from
vista or later, they are actually prepended with \??\
[2009-08-27 09:24:03] paj...@php.net
To do not miss a case again, can you please tell me how you create each
mounted volume or junction? If mnt is a mounted volume or not, etc.
Junction created with junction.exe works fine here on xp, 2k3, win7,
vista and 2k8, using normal parent directories (mounted volume or not).
For example (XP):
c:\mnt mounted volume (HDD)
c:\mnt\directory (mkdir directory)
c:\mnt\junction_abs (created with junction junction c:\mnt\directory)
c:\mnt\junction (created with junction junction directory from c:\mnt)
Using this script from c:\mnt\test (c:\mnt being a mounted volume):
\php-sdk\snap_5_2\vc6\x86\php52\Debug\php.exe t.php
bool(true)
bool(true)
bool(true)
[2009-08-27 08:42:54] paj...@php.net
"\??\" may be the cause (\\?\ is well documented not \??\). But I
wonder why junction.exe jucntion work just fine on our tests system (xp
and 2k3). Thanks for testing, I go back to code&test.
[2009-08-27 03:40:39] phpstuff at cresstone dot com
>From my testing, this snapshot works for directory junction points
created with mklink. However still no go on mounted volumes or directory
junction points created with junction.exe.
Re-creating any faulting junctions with mklink seems like a good
workaround, but mounted volumes are still left in the cold.
Looking at the output of the dir command, the only visible difference
between mklink and junction.exe is the prepended "\??\", which is also
present on mounted volumes by necessity.
Full test log follows:
C:\mnt\test>dir
Volume in drive C is coreI7_System
Volume Serial Number is 38E2-2B62
Directory of C:\mnt\test
2009.08.26 23.32 .
2009.08.26 23.32 ..
2009.08.11 16.35 directory
2009.08.11 14.47 junction
[\??\C:\mnt\test\directory]
2009.08.20 13.26 mklink_junction
[C:\mnt\test\directory]
2009.08.26 23.26 mounted_volume
[\??\Volume{e13ba66a-14db-11de-8e96-001fd0ae05ac}
\]
2009.08.26 23.32 283 phptest.php
1 File(s)283 bytes
6 Dir(s) 28,765,544,448 bytes free
C:\mnt\test>php -v
PHP 5.3.1-dev (cli) (built: Aug 27 2009 03:52:14)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies
C:\mnt\test>type phptest.php
C:\mnt\test>php phptest.php
directory: bool(true)
junction.exe junction: bool(false)
mklink junction:bool(true)
mounted volume: bool(false)
[2009-08-26 20:46:13] paj...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
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/48746
--
Edit this bug report at http://bugs.php.net/?id=48746&edit=1
#49379 [Bgs]: Strange bug GMT change without any reason
ID: 49379
User updated by: cyberdisyan at gmail dot com
Reported By: cyberdisyan at gmail dot com
Status: Bogus
Bug Type: Date/time related
Operating System: Ubuntu - Linux
PHP Version: 5.2.10
New Comment:
Thanks again !
You just saved my day !!! :
Previous Comments:
[2009-08-27 09:32:55] der...@php.net
No need to change 1000s of lines of code, just tell PHP that you want
to use UTC:
date_default_timezone_set( 'UTC' );
[2009-08-27 09:25:03] cyberdisyan at gmail dot com
Dear derick,
Thanks for your prompt reply ... happy that it's not a bug ... but
unhappy to change thousands of code line :(
You can close the ticket :)
[2009-08-27 09:13:55] der...@php.net
We are happy to tell you that you just discovered Daylight Savings
Time. For more information see:
http://webexhibits.org/daylightsaving/b.html
Instead of using mktime/date consider using gmmktime and gmdate which
do
not suffer from DST.
.
[2009-08-27 01:20:30] cyberdisyan at gmail dot com
Description:
When trying to use date(), it return sometime a GMT 02:00 and just one
line below GMT 01:00 without any reason !
Reproduce code:
---
echo date("c",(int)1255903200)."";
echo date("c",(int)1256508000)."";
Expected result:
2009-10-19T00:00:00+01:00
2009-10-26T00:00:00+01:00
Actual result:
--
2009-10-19T00:00:00+02:00
2009-10-25T23:00:00+01:00
--
Edit this bug report at http://bugs.php.net/?id=49379&edit=1
#49379 [Bgs]: Strange bug GMT change without any reason
ID: 49379
Updated by: der...@php.net
Reported By: cyberdisyan at gmail dot com
Status: Bogus
Bug Type: Date/time related
Operating System: Ubuntu - Linux
PHP Version: 5.2.10
New Comment:
No need to change 1000s of lines of code, just tell PHP that you want
to use UTC:
date_default_timezone_set( 'UTC' );
Previous Comments:
[2009-08-27 09:25:03] cyberdisyan at gmail dot com
Dear derick,
Thanks for your prompt reply ... happy that it's not a bug ... but
unhappy to change thousands of code line :(
You can close the ticket :)
[2009-08-27 09:13:55] der...@php.net
We are happy to tell you that you just discovered Daylight Savings
Time. For more information see:
http://webexhibits.org/daylightsaving/b.html
Instead of using mktime/date consider using gmmktime and gmdate which
do
not suffer from DST.
.
[2009-08-27 01:20:30] cyberdisyan at gmail dot com
Description:
When trying to use date(), it return sometime a GMT 02:00 and just one
line below GMT 01:00 without any reason !
Reproduce code:
---
echo date("c",(int)1255903200)."";
echo date("c",(int)1256508000)."";
Expected result:
2009-10-19T00:00:00+01:00
2009-10-26T00:00:00+01:00
Actual result:
--
2009-10-19T00:00:00+02:00
2009-10-25T23:00:00+01:00
--
Edit this bug report at http://bugs.php.net/?id=49379&edit=1
#49379 [Bgs]: Strange bug GMT change without any reason
ID: 49379
User updated by: cyberdisyan at gmail dot com
Reported By: cyberdisyan at gmail dot com
Status: Bogus
Bug Type: Date/time related
Operating System: Ubuntu - Linux
PHP Version: 5.2.10
New Comment:
Dear derick,
Thanks for your prompt reply ... happy that it's not a bug ... but
unhappy to change thousands of code line :(
You can close the ticket :)
Previous Comments:
[2009-08-27 09:13:55] der...@php.net
We are happy to tell you that you just discovered Daylight Savings
Time. For more information see:
http://webexhibits.org/daylightsaving/b.html
Instead of using mktime/date consider using gmmktime and gmdate which
do
not suffer from DST.
.
[2009-08-27 01:20:30] cyberdisyan at gmail dot com
Description:
When trying to use date(), it return sometime a GMT 02:00 and just one
line below GMT 01:00 without any reason !
Reproduce code:
---
echo date("c",(int)1255903200)."";
echo date("c",(int)1256508000)."";
Expected result:
2009-10-19T00:00:00+01:00
2009-10-26T00:00:00+01:00
Actual result:
--
2009-10-19T00:00:00+02:00
2009-10-25T23:00:00+01:00
--
Edit this bug report at http://bugs.php.net/?id=49379&edit=1
#48746 [Asn]: Unable to browse directories within Junction Points
ID: 48746
Updated by: paj...@php.net
Reported By: ddkees at illinois dot edu
Status: Assigned
Bug Type: Directory function related
Operating System: win32 only - Windows Server 2003
PHP Version: 5.3.0
Assigned To: pajoye
New Comment:
To do not miss a case again, can you please tell me how you create each
mounted volume or junction? If mnt is a mounted volume or not, etc.
Junction created with junction.exe works fine here on xp, 2k3, win7,
vista and 2k8, using normal parent directories (mounted volume or not).
For example (XP):
c:\mnt mounted volume (HDD)
c:\mnt\directory (mkdir directory)
c:\mnt\junction_abs (created with junction junction c:\mnt\directory)
c:\mnt\junction (created with junction junction directory from c:\mnt)
Using this script from c:\mnt\test (c:\mnt being a mounted volume):
\php-sdk\snap_5_2\vc6\x86\php52\Debug\php.exe t.php
bool(true)
bool(true)
bool(true)
Previous Comments:
[2009-08-27 08:42:54] paj...@php.net
"\??\" may be the cause (\\?\ is well documented not \??\). But I
wonder why junction.exe jucntion work just fine on our tests system (xp
and 2k3). Thanks for testing, I go back to code&test.
[2009-08-27 03:40:39] phpstuff at cresstone dot com
>From my testing, this snapshot works for directory junction points
created with mklink. However still no go on mounted volumes or directory
junction points created with junction.exe.
Re-creating any faulting junctions with mklink seems like a good
workaround, but mounted volumes are still left in the cold.
Looking at the output of the dir command, the only visible difference
between mklink and junction.exe is the prepended "\??\", which is also
present on mounted volumes by necessity.
Full test log follows:
C:\mnt\test>dir
Volume in drive C is coreI7_System
Volume Serial Number is 38E2-2B62
Directory of C:\mnt\test
2009.08.26 23.32 .
2009.08.26 23.32 ..
2009.08.11 16.35 directory
2009.08.11 14.47 junction
[\??\C:\mnt\test\directory]
2009.08.20 13.26 mklink_junction
[C:\mnt\test\directory]
2009.08.26 23.26 mounted_volume
[\??\Volume{e13ba66a-14db-11de-8e96-001fd0ae05ac}
\]
2009.08.26 23.32 283 phptest.php
1 File(s)283 bytes
6 Dir(s) 28,765,544,448 bytes free
C:\mnt\test>php -v
PHP 5.3.1-dev (cli) (built: Aug 27 2009 03:52:14)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies
C:\mnt\test>type phptest.php
C:\mnt\test>php phptest.php
directory: bool(true)
junction.exe junction: bool(false)
mklink junction:bool(true)
mounted volume: bool(false)
[2009-08-26 20:46:13] paj...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2009-08-26 20:45:53] paj...@php.net
help if I comment in the right bug :) (reassigned)
[2009-08-26 20:44:50] paj...@php.net
Please follow #48746, same problem. I close (bogus) this bug to avoid
to have to split the info in too many reports.
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/48746
--
Edit this bug report at http://bugs.php.net/?id=48746&edit=1
#49382 [Opn->Asn]: can't access DateTime->date
ID: 49382
Updated by: der...@php.net
Reported By: klawd at kamundo dot de
-Status: Open
+Status: Assigned
Bug Type: Reproducible crash
Operating System: Debian GNU/Linux 5.0
PHP Version: 5.3.0
-Assigned To:
+Assigned To: derick
Previous Comments:
[2009-08-27 07:52:37] klawd at kamundo dot de
Description:
Can not access property date of DateTime.
Reproduce code:
---
$dt=new DateTime('1742-05-23 00:00:00'); echo $dt->date;
gets me Notice: Undefined property: DateTime::$date
strangely though, this works:
$dt=new DateTime('1742-05-23 00:00:00'); print_r($dt); echo $dt->date;
DateTime Object ( [date] => 1742-05-23 00:00:00 [timezone_type] => 3
[timezone] => UTC ) 1742-05-23 00:00:00
--
Edit this bug report at http://bugs.php.net/?id=49382&edit=1
#49379 [Opn->Bgs]: Strange bug GMT change without any reason
ID: 49379
Updated by: der...@php.net
Reported By: cyberdisyan at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: Date/time related
Operating System: Ubuntu - Linux
PHP Version: 5.2.10
New Comment:
We are happy to tell you that you just discovered Daylight Savings
Time. For more information see:
http://webexhibits.org/daylightsaving/b.html
Instead of using mktime/date consider using gmmktime and gmdate which
do
not suffer from DST.
.
Previous Comments:
[2009-08-27 01:20:30] cyberdisyan at gmail dot com
Description:
When trying to use date(), it return sometime a GMT 02:00 and just one
line below GMT 01:00 without any reason !
Reproduce code:
---
echo date("c",(int)1255903200)."";
echo date("c",(int)1256508000)."";
Expected result:
2009-10-19T00:00:00+01:00
2009-10-26T00:00:00+01:00
Actual result:
--
2009-10-19T00:00:00+02:00
2009-10-25T23:00:00+01:00
--
Edit this bug report at http://bugs.php.net/?id=49379&edit=1
#49234 [Asn]: method not found ssl_set
ID: 49234
Updated by: and...@php.net
Reported By: thalashir at gmail dot com
Status: Assigned
Bug Type: MySQLi related
Operating System: windows xp
PHP Version: 5.3.0
Assigned To: mysql
New Comment:
5.3 + mysqlnd doesn't support SSL (as well as compression). If you need
to use SSL then you have to use 5.3 + libmysql.
This is a feature request, more or less.
Previous Comments:
[2009-08-13 09:31:58] Thalashir at gmail dot com
Ok, thanks. Any suggestions how could I do the connection? I tried with
$mysqli->options(MYSQLI_READ_DEFAULT_FILE,'/path/to/cert_my.cnf');
where cert_my.cnf is
ssl-ca='path/to/cacert.pem'
ssl-cert='path/to/cert.pem'
ssl-key='path/to/key.pem'
but denies access to user.
Tried to access via mysql command line with options --ssl-ca=...
--ssl-cert=... --ssl-key... and it works.
[2009-08-12 12:26:50] paj...@php.net
It is not available with mysqlnd. No idea why, assigned to the mysql
team :)
[2009-08-12 11:04:31] thalashir at gmail dot com
Description:
When I try to connect to a Mysql database using SSL and mysqli, it says
that the method ssl_set don't exists. I used function
get_class_methods(mysqli) and is not listed. I checked mysql support,
mysqli support and openssl support with phpinfo and they are all
supported.
Here is the list returned from get_class_methods:
autocommit
change_user
character_set_name
client_encoding
close
commit
connect
dump_debug_info
debug
get_charset
get_client_info
get_connection_stats
get_server_info
get_warnings
init
kill
multi_query
mysqli
more_results
next_result
options
ping
prepare
query
real_connect
real_escape_string
poll
reap_async_query
escape_string
real_query
rollback
select_db
set_charset
set_opt
stat
stmt_init
store_result
thread_safe
use_result
refresh
Reproduce code:
---
$mysqli= mysqli_init();
if (!$mysqli) {
die('mysqli_init failed');
}
$mysqli->ssl_set('path/to/key.pem','path/to/cert.pem','path/to/cacert.pem',null,null);
$mysqli_real_connect('1.2.3.4','ssluser','sslpassword','db',port,MYSQLI_CLIENT_SSL);
//queries
$mysqli->close();
Expected result:
A secure connection to mysql
Actual result:
--
Fatal error: Call to undefined method mysqli::ssl_set() in ...
--
Edit this bug report at http://bugs.php.net/?id=49234&edit=1
#49039 [NoF->Bgs]: Can't pass file name with subfolder name 3 characters or less
ID: 49039 Updated by: paj...@php.net Reported By: sant9442 at gmail dot com -Status: No Feedback +Status: Bogus Bug Type: CGI related Operating System: win32 only - Windows PHP Version: 5.3.0 Assigned To: pajoye New Comment: Please see #48746. Same issue, all discussions/feedbacks will be followed there, Previous Comments: [2009-08-25 01:00:00] 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". [2009-08-17 23:13:19] paj...@php.net There is a difference between junction.exe and mklink and that may cause what we have here. We had to deal with symlink/junction (not under all circumstances) because of some path resolutions issues we have with symlinks, that's not specific to php either. However a regression has been introduced with junctions (with junction.exe) and it will be fixed soon. [2009-08-15 14:23:02] sant9442 at gmail dot com After reading Mark's article, the man it probably wrote MKLINK from his junction.exe/c work, for a command link too, I have a recommendatin for PHP. Since the new logic is for VISTA/W7/2008, I would highly suggest that PHP a) either no bother with this stuff, b) make it optional or C) make sure it doesn't enforce VISTA/W7/2008 hard vs soft links in its design for general Windows operation. It needs to take the lower ground with this or not at all. Then again, I don't see why it even cares about altering the intent of PHP developers or web operators with the scripts file names passed. Links are suppose to be outside an PHP engine IMV. [2009-08-15 14:06:53] sant9442 at gmail dot com I have 5 bucks, Microsoft MKLINK for VISTA/2008/W7 was written using Mark's Junction.C code as a basis. Check this out: http://technet.microsoft.com/en-us/magazine/2007.02.vistakernel.aspx Also, why would PHP even came for this? I just don't why. [2009-08-15 13:57:53] sant9442 at gmail dot com Good show. I have follow up with your links and also reup on junctions and moint points technical details. I have exclusively use SysInternal.com junction.exe (comes with C source at the web site). I'm sure you know the infamous Mark Russinovich. No need to elaborate on this industy guru, So I might suggest to explore PHP windows junction operations with junction.exe as I am pretty sure (I trust) Mark's logics matches what is correctly technically expected under windows. Put it this way, odds are good he is doing right. :-) I do have a question? why does PHP even care about symbolic links? Whats the purpose? Why not just use the input file names as passed?, like it is expected? Let the file system deal with it. Thats its purpose. PHP seems to be breaking it apart to revert and obtain the physical path. When I first saw that, I thought maybe it was doing for security purposes. 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/49039 -- Edit this bug report at http://bugs.php.net/?id=49039&edit=1
#45019 [Asn->WFx]: Segmentation fault with SELECT ? and UNION
ID: 45019
Updated by: and...@php.net
Reported By: pumuckel at metropolis dot de
-Status: Assigned
+Status: Wont fix
Bug Type: MySQLi related
Operating System: Linux Gentoo
PHP Version: 5.3CVS-2008-05-16 (snap)
Assigned To: andrey
New Comment:
Can't be fixed, as libmysql is faulty. Metadata changes when using
UNIONS, mysqlnd handles it, but libmysql doesn't well. If you have
SELECT with UNION and different metadata - then use mysqlnd.
Previous Comments:
[2008-07-15 12:13:21] pumuckel at metropolis dot de
Client API version: mysqlnd 5.0.4-dev - 080501 - $Revision: 1.3.2.15
With this version and this script we do not get segmentation fault.
But I have another script where you won't get expected results:
[...]
$foo = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ";
$foo2 = "foo238964283467254725472725347254757652734522374628346246";
$stmt = $db->prepare("SELECT ? UNION SELECT ?");
$stmt->bind_param("ss", $foo, $foo2);
$stmt->bind_result($bar);
$stmt->execute();
$stmt->fetch(); // first to fetch "foo"
echo("F1: $bar vs $foo (should be equal)\n");
$stmt->fetch(); // second to fetch $foo
echo("F2: $bar vs $foo2 (should be equal)\n");
$stmt->free_result();
[...]
Mike
[2008-07-14 19:16:54] u...@php.net
This looks like a libmysql only issue. Pumuckel, if possible give
mysqlnd a test with your code.
[2008-07-14 18:17:47] u...@php.net
Verified - there are issues with UNION. I'll play with it. Andrey, wait
for my test code.
[2008-05-16 08:11:43] pumuckel at metropolis dot de
Description:
We experienced some strange behaviour when using "INSERT INTO ...
select ? ... union select ? ..."
Some bound variables have been inserted, but were truncated somewhere
within the strings.
We have created a simple test script which only selects and returns the
contents we bound.
With "SELECT ? UNION SELECT ?" and 2 bound variables we can see, that
the contents of the variables are not the same when reading back from
db.
With the code below we even managed to get a segmentation fault.
Reproduce code:
---
prepare("SELECT CAST('x' as CHAR) X UNION SELECT CAST(? AS
CHAR(20)) UNION SELECT CAST(? as CHAR(50))");
$stmt->bind_param("ss", $foo, $foo2);
$stmt->bind_result($bar);
$stmt->execute();
$stmt->fetch(); // first to fetch "foo"
echo("F1: $bar vs $foo (".strlen($bar)." vs. ".strlen($foo).")\n");
$stmt->fetch(); // second to fetch $foo
echo("F2: $bar vs $foo (".strlen($bar)." vs. ".strlen($foo).")\n");
$stmt->fetch(); // second to fetch casted $foo
echo("F3: $bar vs $foo2 (".strlen($bar)." vs. ".strlen($foo2).")\n");
$stmt->free_result();
?>
Expected result:
Returned variable $bar should contain contents of 'x', $foo, $foo2:
F1: x vs 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ (1 vs. 36)
F2: 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ vs
0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ (36 vs. 36)
F3: 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ vs
0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ (36 vs. 36)
Actual result:
--
F1: x vs 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ (1 vs. 36)
F2: 0123 vs 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ (4 vs. 36)
Segmentation fault
With gdb:
F1: x vs 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ (1 vs. 36)
F2: 0123 vs 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ (4 vs. 36)
Program received signal SIGSEGV, Segmentation fault.
mysqli_stmt_fetch_libmysql (ht=0, return_value=0x86f9288,
return_value_ptr=0x0, this_ptr=0x86f8fb8, return_value_used=0) at
/usr/local/src/php5.3-200805151430/ext/mysqli/mysqli_api.c:837
837 if (Z_TYPE_P(stmt->result.vars[i]) ==
IS_STRING) {
(gdb) where
#0 mysqli_stmt_fetch_libmysql (ht=0, return_value=0x86f9288,
return_value_ptr=0x0, this_ptr=0x86f8fb8, return_value_used=0) at
/usr/local/src/php5.3-200805151430/ext/mysqli/mysqli_api.c:837
#1 0x082e92bd in zend_do_fcall_common_helper_SPEC
(execute_data=0x8729f38) at
/usr/local/src/php5.3-200805151430/Zend/zend_vm_execute.h:194
#2 0x082daa77 in execute (op_array=0x86f843c) at
/usr/local/src/php5.3-200805151430/Zend/zend_vm_execute.h:96
#3 0x082ba797 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/local/src/php5.3-200805151430/Zend/zend.c:1195
#4 0x0826ad8c in php_execute_script (primary_file=0xbfd034f4) at
/usr/local/src/php5.3-200805151430/main/main.c:2077
#5 0x083437f6 in main (argc=2, argv=0xbfd03684) at
/usr/local/src/php5.3-200805151430/sapi/cli/php_cli.c:1139
--
Edit this bug report at http://bugs.php.net/?id=45019&edit=1
#48746 [Fbk->Asn]: Unable to browse directories within Junction Points
ID: 48746
Updated by: paj...@php.net
Reported By: ddkees at illinois dot edu
-Status: Feedback
+Status: Assigned
Bug Type: Directory function related
Operating System: win32 only - Windows Server 2003
PHP Version: 5.3.0
Assigned To: pajoye
New Comment:
"\??\" may be the cause (\\?\ is well documented not \??\). But I
wonder why junction.exe jucntion work just fine on our tests system (xp
and 2k3). Thanks for testing, I go back to code&test.
Previous Comments:
[2009-08-27 03:40:39] phpstuff at cresstone dot com
>From my testing, this snapshot works for directory junction points
created with mklink. However still no go on mounted volumes or directory
junction points created with junction.exe.
Re-creating any faulting junctions with mklink seems like a good
workaround, but mounted volumes are still left in the cold.
Looking at the output of the dir command, the only visible difference
between mklink and junction.exe is the prepended "\??\", which is also
present on mounted volumes by necessity.
Full test log follows:
C:\mnt\test>dir
Volume in drive C is coreI7_System
Volume Serial Number is 38E2-2B62
Directory of C:\mnt\test
2009.08.26 23.32 .
2009.08.26 23.32 ..
2009.08.11 16.35 directory
2009.08.11 14.47 junction
[\??\C:\mnt\test\directory]
2009.08.20 13.26 mklink_junction
[C:\mnt\test\directory]
2009.08.26 23.26 mounted_volume
[\??\Volume{e13ba66a-14db-11de-8e96-001fd0ae05ac}
\]
2009.08.26 23.32 283 phptest.php
1 File(s)283 bytes
6 Dir(s) 28,765,544,448 bytes free
C:\mnt\test>php -v
PHP 5.3.1-dev (cli) (built: Aug 27 2009 03:52:14)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies
C:\mnt\test>type phptest.php
C:\mnt\test>php phptest.php
directory: bool(true)
junction.exe junction: bool(false)
mklink junction:bool(true)
mounted volume: bool(false)
[2009-08-26 20:46:13] paj...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2009-08-26 20:45:53] paj...@php.net
help if I comment in the right bug :) (reassigned)
[2009-08-26 20:44:50] paj...@php.net
Please follow #48746, same problem. I close (bogus) this bug to avoid
to have to split the info in too many reports.
[2009-08-26 20:44:06] s...@php.net
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revision&revision=287781
Log: - fix #48746, regression with file operaiton on path with
junctions
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/48746
--
Edit this bug report at http://bugs.php.net/?id=48746&edit=1
#49344 [Com]: pdo_mssql fails to connect,throws PDOException SQLSTATE[] (null) (severity 0)
ID: 49344
Comment by: rockyjl at gmail dot com
Reported By: rockyjl at gmai dot com
Status: Open
Bug Type: PDO related
Operating System: win2003 X64
PHP Version: 5.2.11RC1
New Comment:
php-5.2.11RC2-dev-win32-VC6-x86 has the Bug too!
Anyone can help me ? Please !
Previous Comments:
[2009-08-25 02:08:48] rockyjl at gmail dot com
I upgrade to php-5.2.11RC2-dev-win32-VC6-x86 now !
Testing the bug
[2009-08-24 10:06:51] rockyjl at gmai dot com
Description:
in Bug #48539
[28 Jun 2:10am UTC] fel...@php.net
This bug has been fixed in CVS.
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/.
Thank you for the report, and for helping us make PHP better.
Fixed in 5.2 and HEAD.
5.3 in soon.
Thanks.
But the bug still often happen in PHP 5.2.11RC1 ...
Could you tell me which version(win32 zip) can work in the environment
of win2003 x64 + apache 2.2.11 + sql2005,and the pdo_mssql can connect
DB successfully ??
Reproduce code:
---
function db()
{
try
{
$db = new PDO(DB_DSN, DB_User, DB_Password);
return $db;
}
catch (PDOException $e)
{
die($e->getMessage());
}
}
Expected result:
connect DB Successful
Actual result:
--
SQLSTATE[] (null) (severity 0)
--
Edit this bug report at http://bugs.php.net/?id=49344&edit=1
#49383 [NEW]: Lots of empty fstat() calls slow performance
From: olga at metacafe dot com
Operating system: Red Hat 3.4.6-10
PHP version: 5.3.0
PHP Bug Type: Performance problem
Bug description: Lots of empty fstat() calls slow performance
Description:
Hi,
We recently upgraded our web servers with PHP 5.3 and found out that there
are lots of empty fstat system calls. fstat is called 3 times on each file
open. This does not happen on PHP 5.2.9.
PHP 5.2.9 shows better results in benchmarking vs. 5.3.0, and I suppose
it's because of the fstat.
We're running Red Hat 3.4.6, Apache 2.0.59, PHP 5.3.0
Reproduce code:
---
Any code that loads PHP file.
Expected result:
Strace summary from 5.2.9
% time secondsusecs/call calls errors syscall
44.65 34.487815 159 217129 26 lstat
8.73 6.743625 170 39745 145 stat
8.23 6.355874 170 37466 18 open
8.21 6.345542 167 38091close
7.99 6.170706 165 37410fstat
Strace summary from 5.3.0
% time secondsusecs/call calls errors syscall
22.64 28.292541 301 93945fstat
18.39 22.979631 312 73713 110 lstat
9.23 11.529433 311 37131munmap
9.14 11.417404 306 37277mmap
8.52 10.643572 306 34755 149 stat
Actual result:
--
Strace result.
I replaced full path by [path]
open("[path]/Flash.php", O_RDONLY) = 21
fstat(21, {st_mode=S_IFREG|0777, st_size=23902, ...}) = 0
fstat(21, {st_mode=S_IFREG|0777, st_size=23902, ...}) = 0
fstat(21, {st_mode=S_IFREG|0777, st_size=23902, ...}) = 0
mmap(NULL, 23902, PROT_READ, MAP_SHARED, 21, 0) = 0x2a971a2000
stat("[path]/Flash.php", {st_mode=S_IFREG|0777, st_size=23902, ...}) = 0
munmap(0x2a971a2000, 23902) = 0
close(21) = 0
lstat("[path]/VTalkNotification.php", {st_mode=S_IFREG|0777, st_size=778,
...}) = 0
lstat("[path]/VTalkNotification.php", {st_mode=S_IFREG|0777, st_size=778,
...}) = 0
open("[path]/VTalkNotification.php", O_RDONLY) = 21
fstat(21, {st_mode=S_IFREG|0777, st_size=778, ...}) = 0
fstat(21, {st_mode=S_IFREG|0777, st_size=778, ...}) = 0
fstat(21, {st_mode=S_IFREG|0777, st_size=778, ...}) = 0
mmap(NULL, 778, PROT_READ, MAP_SHARED, 21, 0) = 0x2a971a2000
stat("[path]/VTalkNotification.php", {st_mode=S_IFREG|0777, st_size=778,
...}) = 0
munmap(0x2a971a2000, 778) = 0
close(21) = 0
--
Edit bug report at http://bugs.php.net/?id=49383&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49383&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49383&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49383&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49383&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49383&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49383&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49383&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49383&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49383&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49383&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49383&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49383&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49383&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49383&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49383&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49383&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49383&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49383&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49383&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49383&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49383&r=mysqlcfg
#49382 [NEW]: can't access DateTime->date
From: klawd at kamundo dot de
Operating system: Debian GNU/Linux 5.0
PHP version: 5.3.0
PHP Bug Type: Reproducible crash
Bug description: can't access DateTime->date
Description:
Can not access property date of DateTime.
Reproduce code:
---
$dt=new DateTime('1742-05-23 00:00:00'); echo $dt->date;
gets me Notice: Undefined property: DateTime::$date
strangely though, this works:
$dt=new DateTime('1742-05-23 00:00:00'); print_r($dt); echo $dt->date;
DateTime Object ( [date] => 1742-05-23 00:00:00 [timezone_type] => 3
[timezone] => UTC ) 1742-05-23 00:00:00
--
Edit bug report at http://bugs.php.net/?id=49382&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49382&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49382&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49382&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49382&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49382&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49382&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49382&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49382&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49382&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49382&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49382&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49382&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49382&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49382&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49382&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49382&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49382&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49382&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49382&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49382&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49382&r=mysqlcfg
