Bug #47640 [Com]: Session does not close file in /tmp/
Edit report at https://bugs.php.net/bug.php?id=47640&edit=1 ID: 47640 Comment by: kriscr...@php.net Reported by:manuel dot schmitt at manitu dot de Summary:Session does not close file in /tmp/ Status: Not a bug Type: Bug Package:Session related Operating System: Linux PHP Version:5.2.9 Block user comment: N Private report: N New Comment: Could somebody explain why the status was changed to "Not a bug?" I'm not seeing anything in the comments to indicate why that edit was made. Looks like a real bug to me and everything else seems to check-out, so I'm assuming that was an error given the lack of an explanation. I'm re-opening this with "Feedback" status. If you're the one who closed this (the edit history is empty), please post a comment explaining your reasoning. Thanks! Previous Comments: [2012-05-27 01:04:29] bugs dot php dot net at jrs-s dot net I worked around this problem by simply moving sessions from file storage to memcache. session.save_handler = memcache session.save_path = "tcp://serv01:11211,tcp://serv02:11211,tcp://serv03:11211" An application pool that had been creeping up to MaxCli (900 children apiece, in this case) within a couple hours of a restart due to this FLOCK issue settled down and has now been running happily for several days on fewer than 150 children per server. I highly recommend just NOT USING php's file based session storage in the first place, because of exactly this issue. [2012-02-01 19:50:15] pio at rdl dot pl Hello ! Is there any news with this issue ? Piotr [2010-10-24 12:29:55] alex dot linte at gmail dot com Hello, I have the same mistake : host:~# date dimanche 24 octobre 2010, 12:10:03 (UTC+0200) host:~# ps faux | grep php juritrav 17749 0.0 0.0 118988 11616 ?S00:11 0:00 | \_ /usr/bin/php-cgi suphpuser 17818 0.0 0.0 117764 9536 ?S00:12 0:00 | \_ /usr/bin/php-cgi suphpuser 18004 0.0 0.0 117764 9536 ?S00:14 0:00 | \_ /usr/bin/php-cgi suphpuser 12573 0.0 0.1 138812 31784 ?S09:39 0:00 | \_ /usr/bin/php-cgi suphpuser 12574 0.0 0.0 117492 9396 ?S09:39 0:00 | \_ /usr/bin/php-cgi duphpuser 12594 0.0 0.0 117492 9396 ?S09:39 0:00 | \_ /usr/bin/php-cgi suphpuser 12675 0.0 0.0 117764 9536 ?S09:40 0:00 | \_ /usr/bin/php-cgi suphpuser 12682 0.0 0.0 117764 9536 ?S09:40 0:00 | \_ /usr/bin/php-cgi suphpuser 12695 0.0 0.0 117764 9536 ?S09:40 0:00 | \_ /usr/bin/php-cgi So php-cgi scripts run for ever until I kill its manually. I take the sample of process 18004 : front2:~# strace -p18004 Process 18004 attached - interrupt to quit flock(3, LOCK_EX host# lsof -p18004 php-cgi 18004 suphpuser3uW REG9,1 7 897723 /tmp/php5/sess_ (deleted) So the php script tries to lock a session file (file descriptor 3) that has been deleted by the PHP garbage collector. When the garbage collector delete a session file, it doesn't take care that any php process still using this session file. Then the php process can't lock the file because it doesn't exist anymore, the php-cgi process is blocked I have the problem with the following version of php : PHP 5.2.6-1+lenny9 with Suhosin-Patch 0.9.6.2 (cli) (built: Aug 4 2010 06:06:53) Copyright (c) 1997-2008 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies with Zend Optimizer v3.3.9, Copyright (c) 1998-2009, by Zend Technologies The cron job for php (script that delete session on debian) is disabled et the garbage collector php is enabled in php.ini file : session.gc_probability = 1 session.gc_divisor = 100 Sorry for my english. Alexandre LINTE [2009-05-03 12:07:47] manuel dot schmitt at manitu dot de ACK, but as server administrator there *must* be a way to prevent this. Admins do not have influence on the scripts that are used by webmasters. So I think it's a PHP thing. Likely one should automatically close all sessions that were opened by scripts aborting / running into limits sets by php (e.g. exec time) etc. This should solve it. [2009-05-02 18:42:02] j...@php.net Endless loops tend to cause such problems. One should always use http://www.php.net/session_write_close as early as possible to prevent race conditions and this kind of "bugs".
Bug #62680 [Com]: Function isset() throws fatal error on set array if non-existent key depth >= 3
Edit report at https://bugs.php.net/bug.php?id=62680&edit=1
ID: 62680
Comment by: kriscr...@php.net
Reported by:kriscr...@php.net
Summary:Function isset() throws fatal error on set array if
non-existent key depth >= 3
Status: Verified
Type: Bug
Package:Arrays related
Operating System: Linux and Windows
PHP Version:5.3.15
Block user comment: N
Private report: N
New Comment:
@Laruence Sorry for the delay; they're keeping me busy up here!
Yeah I have no objection. It really sucks but I have to agree. Since it's
fixed in 5.4, it really wouldn't be worth tearing into 5.3's guts just to
correct this.
I'll go ahead and mark it "won't fix" for ya (as I try to think happy
thoughts). =)
Previous Comments:
[2012-07-31 02:48:17] larue...@php.net
I'd like mark this as won't fix for 5.3, fixing this will be a big work IMO,
maybe
introduce new issues, and 5.3 is quite stable version now.
--------
[2012-07-30 18:32:12] kriscr...@php.net
Woops, drop the word "ternary" from the description/title. =)
--------
[2012-07-30 18:30:31] kriscr...@php.net
Oh and here's the test case:
--TEST--
Test for existence of ternary isset() bug in nested arrays.
--DESCRIPTION--
Errors should not be thrown when passing non-set arguments to isset().
--CREDIT--
Kris Craig
--FILE--
"",
"key2" => array( "subkey" => array( "supersubkey" => array(
"superdupersubkey" => "Hello." ) ) ),
"key3" => array( "subkey" => array( "supersubkey" => "Hello." )
) );
if ( isset( $arr["key"]["non_existant_key"] ) )
{
print "Arr?";
}
print "DEBUG #1.\r\n";
$out = ( isset( $arr["key"]["non_existent_key"] ) ? "WTF?!" : NULL );
print "DEBUG #2.\r\n";
foreach ( $arr as $key => $row )
{
print ( isset( $row["subkey"]["supersubkey"] ) ?
$row["subkey"]["supersubkey"] . "\r\n" : NULL );
}
print "DEBUG #3.\r\n";
/* Ternaries. --Kris */
print ( isset(
$some_non_existent_variable[0]["subkey"]["supersubkey"]["superdupersubkey"] ) ?
"BAD\r\n" : "OK\r\n" );
print ( isset( $arr[0]["subkey"]["supersubkey"]["superdupersubkey"] ) ?
"BAD-0\r\n" : "OK-0\r\n" );
print ( isset( $arr["key"]["subkey"]["supersubkey"]["superdupersubkey"] ) ?
"BAD-1\r\n" : "OK-1\r\n" );
print ( isset( $arr["key2"]["subkey"]["supersubkey"]["superdupersubkey"] ) ?
"OK-2\r\n" : "BAD-2\r\n" );
print ( isset( $arr["key3"]["subkey"]["supersubkey"]["superdupersubkey"] ) ?
"BAD-3\r\n" : "OK-3\r\n" );
/* Ifcheck. --Kris */
if ( isset( $arr["key"]["subkey"]["supersubkey"]["superdupersubkey"] ) )
{
die( "Error : T_PAAMAYIM_NEKUDOTAYIM is too hard to pronounce!" );
}
print "DEBUG #4.\r\n";
foreach ( $arr as $key => $row )
{
print ( isset( $row["subkey"]["supersubkey"]["superdupersubkey"] ) ?
$row["subkey"]["supersubkey"]["superdupersubkey"] . "\r\n" : NULL );
}
print "DEBUG #5.";
?>
--EXPECT--
DEBUG #1.
DEBUG #2.
Array
Hello.
DEBUG #3.
OK-0
OK-1
OK-2
OK-3
DEBUG #4.
Hello.
DEBUG #5.
[2012-07-30 18:27:15] kriscr...@php.net
Ahh ok. Is this a won't fix then since it's not in 5.4? Or is this still
something we'd want to correct?
Thanks!
[2012-07-28 07:34:31] larue...@php.net
yeah, this is a issue in 5.3, while 5.4 have no such issue which is due to the
fetch_dim_is behavior changed
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=62680
--
Edit this bug report at https://bugs.php.net/bug.php?id=62680&edit=1
Bug #62680 [Com]: Function isset() throws fatal error on set array if non-existent key depth >= 3
Edit report at https://bugs.php.net/bug.php?id=62680&edit=1
ID: 62680
Comment by: kriscr...@php.net
Reported by:kriscr...@php.net
Summary:Function isset() throws fatal error on set array if
non-existent key depth >= 3
Status: Verified
Type: Bug
Package:Arrays related
Operating System: Linux and Windows
PHP Version:5.3.15
Block user comment: N
Private report: N
New Comment:
Ahh ok. Is this a won't fix then since it's not in 5.4? Or is this still
something we'd want to correct?
Thanks!
Previous Comments:
[2012-07-28 07:34:31] larue...@php.net
yeah, this is a issue in 5.3, while 5.4 have no such issue which is due to the
fetch_dim_is behavior changed
[2012-07-27 23:04:52] kriscr...@php.net
I'm still fairly new to the codebase compared to most of you karma folks, so if
this looks like something a relative newbie could handle, please point me in
the right direction and I'd be happy to just assign this one to myself. It'll
probably take way longer but I imagine it would be a good learning experience
for me if I had a little guidance to get me started.
Thanks! =)
----
[2012-07-27 23:01:29] kriscr...@php.net
Description:
The test script sums it up pretty well. Basically, if I pass an array with a
missing key to isset(), it's not supposed to throw an error. After all,
isset() is generally what people use for those kinds of sanity checks where
unexpected data might be returned.
However, I just noticed (completely by accident) that, if you're passing an
array with a set key followed by three or more missing keys to isset(), PHP
will throw a fatal error and script execution will terminate at that point.
What's particularly strange about this is that it only seems to occur if the
top-level array variable AND its first key are both set. If I use the same
depth on an undefined variable or on the defined array but with the top-level
key being undefined, it works just fine.
In the example, this would mean that $non_existent_variable[...][...][...][...]
is fine and $arr[0][...][...][...] is fine ($arr is defined but $arr[0] and
$non_existent_variable are not). However, if I do $arr["key"][...][...][...],
where $arr["key"] is defined but the subsequent [...] keys are not, a fatal
error is thrown. That's clearly a bug.
In case anyone else encounters this before it's fixed, you can work around it
by adding some additional (albeit cluttery) sanity checks. For example, if
your $arr["key"] is not an array and that's causing the error, simply add
is_array( $arr["key"] ) to the ifcheck prior to isset and that will allow your
script to proceed without dying.
I've already created a PHPT case for this. It'd probably be a good idea to add
it to run_tests, though I'm not entirely certain how/where to do that.
Looks like this bug was previously documented in 5.2.x
(https://bugs.php.net/bug.php?id=44431), but it was closed with a comment
saying that it had been fixed (or at least couldn't be repro'd) in 5.2.6. So
I'm guess either that person wasn't properly reproducing the conditions of the
bug somehow or this is a regression.
Tested on Windows 7 x86_64 and CentOS 5.8 x86_64. In both cases, PHP version
was 5.3.15 (VC9 ZTS build on Windows). Tested both via Apache/mod_php and CLI.
I have not tested this on 5.4 yet. I don't have a 5.4 environment handy at
the moment, so if somebody else could repro this on that version I'd be much
obliged. Thanks!
Test script:
---
"",
"key2" => array( "subkey" => array( "supersubkey" => array(
"superdupersubkey" => "Hello." ) ) ),
"key3" => array( "subkey" => array( "supersubkey" => "Hello." )
) );
if ( isset( $arr["key"]["non_existant_key"] ) )
{
print "Arr?";
}
print "DEBUG #1.\r\n";
$out = ( isset( $arr["key"]["non_existant_key"] ) ? "WTF?!" : NULL );
print "DEBUG #2.\r\n";
foreach ( $arr as $key => $row )
{
print ( isset( $row["subkey"]["supersubkey"] ) ?
$row["subkey"]["supersubkey"] . "\r\n" : NULL );
}
print "DEBUG #3.\r\n";
if ( isset( $arr[0]["subkey"]["supersubkey"]["superdupersubkey"] ) )
{
die( "Error : T_PAAMAYIM_NEKUDOTAYIM is too hard to pronou
Bug #62680 [Com]: Function isset() throws fatal error on set array if non-existent key depth >= 3
Edit report at https://bugs.php.net/bug.php?id=62680&edit=1
ID: 62680
Comment by: kriscr...@php.net
Reported by:kriscr...@php.net
Summary:Function isset() throws fatal error on set array if
non-existent key depth >= 3
Status: Open
Type: Bug
Package:Arrays related
Operating System: Linux and Windows
PHP Version:5.3.15
Block user comment: N
Private report: N
New Comment:
I'm still fairly new to the codebase compared to most of you karma folks, so if
this looks like something a relative newbie could handle, please point me in
the right direction and I'd be happy to just assign this one to myself. It'll
probably take way longer but I imagine it would be a good learning experience
for me if I had a little guidance to get me started.
Thanks! =)
Previous Comments:
[2012-07-27 23:01:29] kriscr...@php.net
Description:
The test script sums it up pretty well. Basically, if I pass an array with a
missing key to isset(), it's not supposed to throw an error. After all,
isset() is generally what people use for those kinds of sanity checks where
unexpected data might be returned.
However, I just noticed (completely by accident) that, if you're passing an
array with a set key followed by three or more missing keys to isset(), PHP
will throw a fatal error and script execution will terminate at that point.
What's particularly strange about this is that it only seems to occur if the
top-level array variable AND its first key are both set. If I use the same
depth on an undefined variable or on the defined array but with the top-level
key being undefined, it works just fine.
In the example, this would mean that $non_existent_variable[...][...][...][...]
is fine and $arr[0][...][...][...] is fine ($arr is defined but $arr[0] and
$non_existent_variable are not). However, if I do $arr["key"][...][...][...],
where $arr["key"] is defined but the subsequent [...] keys are not, a fatal
error is thrown. That's clearly a bug.
In case anyone else encounters this before it's fixed, you can work around it
by adding some additional (albeit cluttery) sanity checks. For example, if
your $arr["key"] is not an array and that's causing the error, simply add
is_array( $arr["key"] ) to the ifcheck prior to isset and that will allow your
script to proceed without dying.
I've already created a PHPT case for this. It'd probably be a good idea to add
it to run_tests, though I'm not entirely certain how/where to do that.
Looks like this bug was previously documented in 5.2.x
(https://bugs.php.net/bug.php?id=44431), but it was closed with a comment
saying that it had been fixed (or at least couldn't be repro'd) in 5.2.6. So
I'm guess either that person wasn't properly reproducing the conditions of the
bug somehow or this is a regression.
Tested on Windows 7 x86_64 and CentOS 5.8 x86_64. In both cases, PHP version
was 5.3.15 (VC9 ZTS build on Windows). Tested both via Apache/mod_php and CLI.
I have not tested this on 5.4 yet. I don't have a 5.4 environment handy at
the moment, so if somebody else could repro this on that version I'd be much
obliged. Thanks!
Test script:
---
"",
"key2" => array( "subkey" => array( "supersubkey" => array(
"superdupersubkey" => "Hello." ) ) ),
"key3" => array( "subkey" => array( "supersubkey" => "Hello." )
) );
if ( isset( $arr["key"]["non_existant_key"] ) )
{
print "Arr?";
}
print "DEBUG #1.\r\n";
$out = ( isset( $arr["key"]["non_existant_key"] ) ? "WTF?!" : NULL );
print "DEBUG #2.\r\n";
foreach ( $arr as $key => $row )
{
print ( isset( $row["subkey"]["supersubkey"] ) ?
$row["subkey"]["supersubkey"] . "\r\n" : NULL );
}
print "DEBUG #3.\r\n";
if ( isset( $arr[0]["subkey"]["supersubkey"]["superdupersubkey"] ) )
{
die( "Error : T_PAAMAYIM_NEKUDOTAYIM is too hard to pronounce!" );
}
print ( isset( $arr[0]["subkey"]["supersubkey"]["superdupersubkey"] ) ?
"BAD-0\r\n" : "OK-0\r\n" );
print ( isset( $arr["key"]["subkey"]["supersubkey"]["superdupersubkey"] ) ?
"BAD-1\r\n" : "OK-1\r\n" );
print ( isset( $arr["key2"]["subkey"]["supersubkey"]["superdupersubkey"] ) ?
"OK-2\r\n" : "B
[PHP-BUG] Bug #62680 [NEW]: Function isset() throws fatal error on set array if non-existent key depth >= 3
From: kriscraig
Operating system: Linux and Windows
PHP version: 5.3.15
Package: Arrays related
Bug Type: Bug
Bug description:Function isset() throws fatal error on set array if
non-existent key depth >= 3
Description:
The test script sums it up pretty well. Basically, if I pass an array with
a missing key to isset(), it's not supposed to throw an error. After all,
isset() is generally what people use for those kinds of sanity checks where
unexpected data might be returned.
However, I just noticed (completely by accident) that, if you're passing an
array with a set key followed by three or more missing keys to isset(), PHP
will throw a fatal error and script execution will terminate at that
point.
What's particularly strange about this is that it only seems to occur if
the top-level array variable AND its first key are both set. If I use the
same depth on an undefined variable or on the defined array but with the
top-level key being undefined, it works just fine.
In the example, this would mean that
$non_existent_variable[...][...][...][...] is fine and
$arr[0][...][...][...] is fine ($arr is defined but $arr[0] and
$non_existent_variable are not). However, if I do
$arr["key"][...][...][...], where $arr["key"] is defined but the subsequent
[...] keys are not, a fatal error is thrown. That's clearly a bug.
In case anyone else encounters this before it's fixed, you can work around
it by adding some additional (albeit cluttery) sanity checks. For example,
if your $arr["key"] is not an array and that's causing the error, simply
add is_array( $arr["key"] ) to the ifcheck prior to isset and that will
allow your script to proceed without dying.
I've already created a PHPT case for this. It'd probably be a good idea to
add it to run_tests, though I'm not entirely certain how/where to do that.
Looks like this bug was previously documented in 5.2.x
(https://bugs.php.net/bug.php?id=44431), but it was closed with a comment
saying that it had been fixed (or at least couldn't be repro'd) in 5.2.6.
So I'm guess either that person wasn't properly reproducing the conditions
of the bug somehow or this is a regression.
Tested on Windows 7 x86_64 and CentOS 5.8 x86_64. In both cases, PHP
version was 5.3.15 (VC9 ZTS build on Windows). Tested both via
Apache/mod_php and CLI. I have not tested this on 5.4 yet. I don't have a
5.4 environment handy at the moment, so if somebody else could repro this
on that version I'd be much obliged. Thanks!
Test script:
---
"",
"key2" => array( "subkey" => array( "supersubkey" => array(
"superdupersubkey" => "Hello." ) ) ),
"key3" => array( "subkey" => array( "supersubkey" => "Hello." )
) );
if ( isset( $arr["key"]["non_existant_key"] ) )
{
print "Arr?";
}
print "DEBUG #1.\r\n";
$out = ( isset( $arr["key"]["non_existant_key"] ) ? "WTF?!" : NULL );
print "DEBUG #2.\r\n";
foreach ( $arr as $key => $row )
{
print ( isset( $row["subkey"]["supersubkey"] ) ?
$row["subkey"]["supersubkey"] . "\r\n" : NULL );
}
print "DEBUG #3.\r\n";
if ( isset( $arr[0]["subkey"]["supersubkey"]["superdupersubkey"] ) )
{
die( "Error : T_PAAMAYIM_NEKUDOTAYIM is too hard to pronounce!" );
}
print ( isset( $arr[0]["subkey"]["supersubkey"]["superdupersubkey"] ) ?
"BAD-0\r\n" : "OK-0\r\n" );
print ( isset( $arr["key"]["subkey"]["supersubkey"]["superdupersubkey"] ) ?
"BAD-1\r\n" : "OK-1\r\n" );
print ( isset( $arr["key2"]["subkey"]["supersubkey"]["superdupersubkey"] )
? "OK-2\r\n" : "BAD-2\r\n" );
print ( isset( $arr["key3"]["subkey"]["supersubkey"]["superdupersubkey"] )
? "BAD-3\r\n" : "OK-3\r\n" );
print "DEBUG #4.\r\n";
foreach ( $arr as $key => $row )
{
print ( isset( $row["subkey"]["supersubkey"]["superdupersubkey"] ) ?
$row["subkey"]["supersubkey"]["superdupersubkey"] . "\r\n" : NULL );
}
print "DEBUG #5.";
?>
Expected result:
DEBUG #1.
DEBUG #2.
Array
Hello.
DEBUG #3.
OK
OK-0
OK-1
OK-2
OK-3
DEBUG #4.
Hello.
DEBUG #5.
Actual result:
--
DEBUG #1.
DEBUG #2.
Array
Hello.
DEBUG #3.
OK
OK-0
Fatal error: Cannot use string offset as an array in C:\Program
Files (x86)\Apache2.2\htdocs\test8.php on line 28
--
Edit bug report at https://bugs.php.net/bug.php?id=62680&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=62680&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=62680&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=62680&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=62680&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=62680&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=62680&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=62680&r=needtrace
Need Reproduce Script:
Req #28181 [Com]: "make install" alters httpd.conf
Edit report at https://bugs.php.net/bug.php?id=28181&edit=1 ID: 28181 Comment by: kriscr...@php.net Reported by:hus at design-d dot de Summary:"make install" alters httpd.conf Status: Assigned Type: Feature/Change Request Package:*Configuration Issues Operating System: Linux PHP Version:4.x, 5.x Assigned To:kriscraig Block user comment: N Private report: N New Comment: RFC to resolve this issue: https://wiki.php.net/rfc/apxs-loadmodule Previous Comments: [2011-12-30 19:45:47] kriscr...@php.net Since there are no objections, I went ahead and assigned this to myself. I also updated the version to reflect that this issue is still present in the 5.x branches. [2011-12-23 23:38:53] kriscr...@php.net I just stumbled upon this really old (and still open) bug from PHP 4 while Googling this very issue on 5.2.17. Has this ever been addressed? If not, was there any pressing reason why or is it just not a priority? If the latter, I could probably take ownership of this if nobody has any objections. [2004-04-28 17:10:37] der...@php.net I'm all for this, as I thought it to be very annoying too... [2004-04-28 17:08:03] der...@php.net I'm all for this, as I thought it to be very annoying too... [2004-04-28 15:18:05] hus at design-d dot de But axps only does this if the "-a" flag is specified. Just drop that. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=28181 -- Edit this bug report at https://bugs.php.net/bug.php?id=28181&edit=1
Req #28181 [Com]: "make install" alters httpd.conf
Edit report at https://bugs.php.net/bug.php?id=28181&edit=1 ID: 28181 Comment by: kriscr...@php.net Reported by:hus at design-d dot de Summary:"make install" alters httpd.conf Status: Assigned Type: Feature/Change Request Package:*Configuration Issues Operating System: Linux PHP Version:4.x, 5.x Assigned To:kriscraig Block user comment: N Private report: N New Comment: Since there are no objections, I went ahead and assigned this to myself. I also updated the version to reflect that this issue is still present in the 5.x branches. Previous Comments: [2011-12-23 23:38:53] kriscr...@php.net I just stumbled upon this really old (and still open) bug from PHP 4 while Googling this very issue on 5.2.17. Has this ever been addressed? If not, was there any pressing reason why or is it just not a priority? If the latter, I could probably take ownership of this if nobody has any objections. [2004-04-28 17:10:37] der...@php.net I'm all for this, as I thought it to be very annoying too... [2004-04-28 17:08:03] der...@php.net I'm all for this, as I thought it to be very annoying too... [2004-04-28 15:18:05] hus at design-d dot de But axps only does this if the "-a" flag is specified. Just drop that. [2004-04-27 21:11:22] der...@php.net This is not something that PHP does, but the apache "APXS" tool. If you want to prevent that, either don't use "make install" or make a static module for PHP. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=28181 -- Edit this bug report at https://bugs.php.net/bug.php?id=28181&edit=1
Req #28181 [Com]: "make install" alters httpd.conf
Edit report at https://bugs.php.net/bug.php?id=28181&edit=1 ID: 28181 Comment by: kriscr...@php.net Reported by:hus at design-d dot de Summary:"make install" alters httpd.conf Status: Open Type: Feature/Change Request Package:Feature/Change Request Operating System: Linux PHP Version:4.3.6 Block user comment: N Private report: N New Comment: I just stumbled upon this really old (and still open) bug from PHP 4 while Googling this very issue on 5.2.17. Has this ever been addressed? If not, was there any pressing reason why or is it just not a priority? If the latter, I could probably take ownership of this if nobody has any objections. Previous Comments: [2004-04-28 17:10:37] der...@php.net I'm all for this, as I thought it to be very annoying too... [2004-04-28 17:08:03] der...@php.net I'm all for this, as I thought it to be very annoying too... [2004-04-28 15:18:05] hus at design-d dot de But axps only does this if the "-a" flag is specified. Just drop that. [2004-04-27 21:11:22] der...@php.net This is not something that PHP does, but the apache "APXS" tool. If you want to prevent that, either don't use "make install" or make a static module for PHP. [2004-04-27 14:23:37] hus at design-d dot de Description: The installation procedure tries to be helpful and adds a loadmodule instruction to the apache configuration. This might be nice if you have a default installation, but I firmly believe in keeping separate packages separate to keep my installation manageable. Therefore I have separate configuration files for addons like php or subversion; the "main" httpd.conf gets overwritten every now and then. So I'd like have at least the option of disabling this feature. -- Edit this bug report at https://bugs.php.net/bug.php?id=28181&edit=1
Bug #54212 [Com]: Localhost resolves much more slowly than 127.0.0.1 on mysql_connect()
Edit report at http://bugs.php.net/bug.php?id=54212&edit=1
ID: 54212
Comment by: kriscr...@php.net
Reported by:kriscr...@php.net
Summary:Localhost resolves much more slowly than 127.0.0.1
on mysql_connect()
Status: Feedback
Type: Bug
Package:MySQL related
Operating System: Windows
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
I'm sorry guys, I realize this report is very scant on details. Please
keep in mind I'm reporting it on someone else's behalf at their request.
I posted all the details I've been given and have requested further
information, which I will post here as soon as I get it.
I possibly should've waited, but I'd already promised to have it posted
by EOD today.
Previous Comments:
[2011-03-10 10:53:46] paj...@php.net
We need:
- windows version
- Whether IPv6 is enabled or not
Please try using simple socket as well, or using
fopen('http://localhost/foo.php'); while being sure that localhost is
actually
IPv6 or Ipv4, to compare both. That will let us diagnose the issue
without
having to rely on mysql.
[2011-03-10 10:53:14] u...@php.net
If there is anything, its not MySQL specific. mysqlnd is using PHP
Streams. PHP Streams should be the source. Only other cause I can think
of is MySQL server.
--------
[2011-03-10 10:45:51] kriscr...@php.net
Description:
I'm told that a number of people have been reporting this issue. The
reports I'm hearing state that people are finding it to be about 3-4
times slower when done by hostname.
My guess would be this is another IPv6-related issue. It's also worth
noting that I have not yet been able to independently verify these
numbers, though I am working on doing so and will post the data if/when
I have it.
It was requested that I post this bug so that we have a record of it.
If you've experienced any hostname vs. IP performance issues (good or
bad), please post a comment here so we have the reports in one central
place. Thanks!
Test script:
---
Execution Time: $duration sec\r\n";
--
Edit this bug report at http://bugs.php.net/bug.php?id=54212&edit=1
[PHP-BUG] Bug #54212 [NEW]: Localhost resolves much more slowly than 127.0.0.1 on mysql_connect()
From: kriscraig Operating system: Windows PHP version: 5.3.5 Package: MySQL related Bug Type: Bug Bug description:Localhost resolves much more slowly than 127.0.0.1 on mysql_connect() Description: I'm told that a number of people have been reporting this issue. The reports I'm hearing state that people are finding it to be about 3-4 times slower when done by hostname. My guess would be this is another IPv6-related issue. It's also worth noting that I have not yet been able to independently verify these numbers, though I am working on doing so and will post the data if/when I have it. It was requested that I post this bug so that we have a record of it. If you've experienced any hostname vs. IP performance issues (good or bad), please post a comment here so we have the reports in one central place. Thanks! Test script: --- Execution Time: $duration sec\r\n"; -- Edit bug report at http://bugs.php.net/bug.php?id=54212&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54212&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54212&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54212&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54212&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54212&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54212&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54212&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54212&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54212&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54212&r=support Expected behavior: http://bugs.php.net/fix.php?id=54212&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54212&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54212&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54212&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54212&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54212&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54212&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54212&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54212&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54212&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54212&r=mysqlcfg
Bug #53333 [Com]: Random crash
Edit report at http://bugs.php.net/bug.php?id=5&edit=1 ID: 5 Comment by: kriscr...@php.net Reported by:paj...@php.net Summary:Random crash Status: Feedback Type: Bug Package:MySQLi related Operating System: * PHP Version:5.3.3 Assigned To:mysql Block user comment: N Private report: N New Comment: I believe it would also be helpful to allow the mysqlnd debug setting to be used on a non-debug PHP build as well. Previous Comments: [2011-01-22 04:28:47] kriscr...@php.net Sorry for not keeping these comments up-to-date. I've had my head buried triaging this for the last two months now. Anyway, there's a few things to cover. First, I was able to get your mysqlnd debug to work. However, because you have it outputting the debug to a file on each and every PHP run, this filesystem stress is creating a major bottleneck, bringing PHP's perf understress down from around 50 tps (transactions per second) to about 1 or 2 tps. As a result, I am unable to repro this crash with this enabled as you specified in your comment. I would recommend that you perhaps find a way to store this data as an object or whatever and only output to a file in the event of a crash or other error. In any case, I spent some time backtracing this and I believe what we're dealing with is a classic double-free and/or corruption. I have no explanation as to what's causing the corruption to begin with though. I also investigated whether or not this is a threading issue. Contrary to what common sense would suggest, this does not appear to be the case, either. I ran the stress test again on Apache with the -X option (Debug mode), which forces httpd.exe to run as a single process. The crash still occured. No relevant change in the repro. I have also confirmed that this bug is still present in the latest release of 5.3.5. Finally, given the difficulty in reproducing this bug, not to mention the general difficulty in tracking down memory corruption issues in ANSI C in general, I'm now trying a bandaid approach. I added an ifcheck to _zend_mm_free_int in zend_alloc.c at the spot of the top of the crash stack, forcing it to skip the free attempt if the variable in question (next_block) is NULL. I then added some exception handling (using setjmp.h) code to mysqli_result_free_storage in mysqli.c at a spot earlier in the stack, forcing it to throw a PHP warning error (which is set to output to a log file) if there's an exception. I've never tried this in ANSI C before but I think I've got it right. The test is running now and may take awhile to yield a result. I will post a patch early next week. If successful, this won't fix whatever the underlying cause of the corruption is, but it will at least throw an error and spare us a crash, which will allow me to start generating PHP perf results under stress conditions along with the standard perf data. I'll post again when I have the results of this latest test run. [2010-12-02 11:26:33] paj...@php.net You need a debug build to get it working. -------- [2010-12-02 08:45:42] kriscr...@php.net Unfortunately, still no go with the forward slashes. Has this new debug feature actually been tested yet, or perhaps it needs to be enabled in the source then rebuilt? I'm fresh out of ideas. :/ -------- [2010-12-01 23:25:47] kriscr...@php.net Alrighty, I'll try using forward slashes and will post the outcome when it's done. The bug typically takes anywhere from 1 hour up to around 4 hours to repro under stress, so stand by for now. =) [2010-12-01 14:13:55] paj...@php.net Right, but only for the ini setting tests, as it should not be enabled by default :) The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=5 -- Edit this bug report at http://bugs.php.net/bug.php?id=5&edit=1
Bug #53333 [Com]: Random crash
Edit report at http://bugs.php.net/bug.php?id=5&edit=1 ID: 5 Comment by: kriscr...@php.net Reported by:paj...@php.net Summary:Random crash Status: Feedback Type: Bug Package:MySQLi related Operating System: * PHP Version:5.3.3 Assigned To:mysql Block user comment: N Private report: N New Comment: Sorry for not keeping these comments up-to-date. I've had my head buried triaging this for the last two months now. Anyway, there's a few things to cover. First, I was able to get your mysqlnd debug to work. However, because you have it outputting the debug to a file on each and every PHP run, this filesystem stress is creating a major bottleneck, bringing PHP's perf understress down from around 50 tps (transactions per second) to about 1 or 2 tps. As a result, I am unable to repro this crash with this enabled as you specified in your comment. I would recommend that you perhaps find a way to store this data as an object or whatever and only output to a file in the event of a crash or other error. In any case, I spent some time backtracing this and I believe what we're dealing with is a classic double-free and/or corruption. I have no explanation as to what's causing the corruption to begin with though. I also investigated whether or not this is a threading issue. Contrary to what common sense would suggest, this does not appear to be the case, either. I ran the stress test again on Apache with the -X option (Debug mode), which forces httpd.exe to run as a single process. The crash still occured. No relevant change in the repro. I have also confirmed that this bug is still present in the latest release of 5.3.5. Finally, given the difficulty in reproducing this bug, not to mention the general difficulty in tracking down memory corruption issues in ANSI C in general, I'm now trying a bandaid approach. I added an ifcheck to _zend_mm_free_int in zend_alloc.c at the spot of the top of the crash stack, forcing it to skip the free attempt if the variable in question (next_block) is NULL. I then added some exception handling (using setjmp.h) code to mysqli_result_free_storage in mysqli.c at a spot earlier in the stack, forcing it to throw a PHP warning error (which is set to output to a log file) if there's an exception. I've never tried this in ANSI C before but I think I've got it right. The test is running now and may take awhile to yield a result. I will post a patch early next week. If successful, this won't fix whatever the underlying cause of the corruption is, but it will at least throw an error and spare us a crash, which will allow me to start generating PHP perf results under stress conditions along with the standard perf data. I'll post again when I have the results of this latest test run. Previous Comments: [2010-12-02 11:26:33] paj...@php.net You need a debug build to get it working. -------- [2010-12-02 08:45:42] kriscr...@php.net Unfortunately, still no go with the forward slashes. Has this new debug feature actually been tested yet, or perhaps it needs to be enabled in the source then rebuilt? I'm fresh out of ideas. :/ -------- [2010-12-01 23:25:47] kriscr...@php.net Alrighty, I'll try using forward slashes and will post the outcome when it's done. The bug typically takes anywhere from 1 hour up to around 4 hours to repro under stress, so stand by for now. =) [2010-12-01 14:13:55] paj...@php.net Right, but only for the ini setting tests, as it should not be enabled by default :) [2010-12-01 14:10:34] and...@php.net Pierre, I'm a fan of this, but it can, and will probably, hit the run-time performance. But I can't tell without a benchmark. Unfortunately Ulf has some other things to do at the moment. It is easy to change that, just edit mysqlnd.h and find MYSQLND_DBG_ENABLED and set it to 1 in all cases. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=5 -- Edit this bug report at http://bugs.php.net/bug.php?id=5&edit=1
Bug #53333 [Com]: Random crash
Edit report at http://bugs.php.net/bug.php?id=5&edit=1 ID: 5 Comment by: kriscr...@php.net Reported by:paj...@php.net Summary:Random crash Status: Feedback Type: Bug Package:MySQLi related Operating System: * PHP Version:5.3.3 Assigned To:mysql Block user comment: N Private report: N New Comment: Unfortunately, still no go with the forward slashes. Has this new debug feature actually been tested yet, or perhaps it needs to be enabled in the source then rebuilt? I'm fresh out of ideas. :/ Previous Comments: [2010-12-01 23:25:47] kriscr...@php.net Alrighty, I'll try using forward slashes and will post the outcome when it's done. The bug typically takes anywhere from 1 hour up to around 4 hours to repro under stress, so stand by for now. =) [2010-12-01 14:13:55] paj...@php.net Right, but only for the ini setting tests, as it should not be enabled by default :) [2010-12-01 14:10:34] and...@php.net Pierre, I'm a fan of this, but it can, and will probably, hit the run-time performance. But I can't tell without a benchmark. Unfortunately Ulf has some other things to do at the moment. It is easy to change that, just edit mysqlnd.h and find MYSQLND_DBG_ENABLED and set it to 1 in all cases. [2010-12-01 14:06:17] paj...@php.net Wondering if it could be useful to have the logs in non debug builds as well, what do you think? [2010-12-01 11:18:30] and...@php.net Hi, I recently fixed the argument parser for the debug log for Windows, because ":" is a separator in the string. Also only since few weeks the trace log is available on Windows. You need a pretty fresh build sources. Also you need a _debug_ build, because the trace functionality is not compiled in in release builds. And please try using / instead of \, if that helps. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=5 -- Edit this bug report at http://bugs.php.net/bug.php?id=5&edit=1
Bug #53333 [Com]: Random crash
Edit report at http://bugs.php.net/bug.php?id=5&edit=1 ID: 5 Comment by: kriscr...@php.net Reported by:paj...@php.net Summary:Random crash Status: Feedback Type: Bug Package:MySQLi related Operating System: * PHP Version:5.3.3 Assigned To:mysql Block user comment: N Private report: N New Comment: Alrighty, I'll try using forward slashes and will post the outcome when it's done. The bug typically takes anywhere from 1 hour up to around 4 hours to repro under stress, so stand by for now. =) Previous Comments: [2010-12-01 14:13:55] paj...@php.net Right, but only for the ini setting tests, as it should not be enabled by default :) [2010-12-01 14:10:34] and...@php.net Pierre, I'm a fan of this, but it can, and will probably, hit the run-time performance. But I can't tell without a benchmark. Unfortunately Ulf has some other things to do at the moment. It is easy to change that, just edit mysqlnd.h and find MYSQLND_DBG_ENABLED and set it to 1 in all cases. [2010-12-01 14:06:17] paj...@php.net Wondering if it could be useful to have the logs in non debug builds as well, what do you think? [2010-12-01 11:18:30] and...@php.net Hi, I recently fixed the argument parser for the debug log for Windows, because ":" is a separator in the string. Also only since few weeks the trace log is available on Windows. You need a pretty fresh build sources. Also you need a _debug_ build, because the trace functionality is not compiled in in release builds. And please try using / instead of \, if that helps. ---- [2010-12-01 10:49:22] kriscr...@php.net Oh and also, could you tell me when this debug is supposed to output the file? I.e. does it output debug info whenever MySQL is invoked, or only when there's a crash? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=5 -- Edit this bug report at http://bugs.php.net/bug.php?id=5&edit=1
Bug #53333 [Com]: Random crash
Edit report at http://bugs.php.net/bug.php?id=5&edit=1 ID: 5 Comment by: kriscr...@php.net Reported by:paj...@php.net Summary:Random crash Status: Feedback Type: Bug Package:MySQLi related Operating System: * PHP Version:5.3.3 Assigned To:mysql Block user comment: N Private report: N New Comment: Oh and also, could you tell me when this debug is supposed to output the file? I.e. does it output debug info whenever MySQL is invoked, or only when there's a crash? Previous Comments: [2010-12-01 10:39:51] kriscr...@php.net Hi Ulf, I've been running the tests for Pierre and am also the one who first discovered this bug. He asked me to connect with you here because I've been unable to get the debug directive you mentioned to output. Specifically, I'm running the PHP 5.3.4RC1 ZTS Pierre released, VC9 compile, on Apache 2.2 under one of our Windows 2008 R2 hosts with Windbg attached to the process. In php.ini, I added the following line to the MYSQLND section: mysqlnd.debug="d:t:O,C:\temp\mysqlnd_debug.log" The setting does show up in PHPInfo(). Specifically: mysqlnd mysqlnd enabled Version mysqlnd 5.0.7-dev - 091210 - $Revision: 304625 $ Compression supported SSL not supported Command buffer size 4096 Read buffer size32768 Read timeout31536000 Collecting statistics Yes Collecting memory statisticsYes Tracing d:t:O,C:\temp\mysqlnd_debug.log However, the mysqlnd_debug.log file is never created. I'm not sure under what conditions it's supposed to output, but in this test I was hitting both MediaWiki and WordPress until the crash occured, and at no point was the file created. The directory has full perms (including write) granted to all users. I could theoretically use procmon to see if it's attempting to write the file, but since we're dealing with a bug that takes about an hour to repro, that wouldn't be my first choice. Have you had a chance yet to test this new debug feature? Do you know if there are any other settings/etc that need to be enabled in order for this to work? Please let me know and I'll give it another go. Thanks! --Kris [2010-11-30 12:26:20] paj...@php.net I will ask to enable it and run again the tests. Thanks :) [2010-11-30 12:24:45] u...@php.net Hi Pierre, can you provide a mysqlnd debug log, do you have access to the php.ini? In 5.3.4 mysqlnd learned to write proper debug logs on Windows. Try running PHP with mysqlnd.debug="d:t:O,C:\mysqlnd_debug.log". You need 5.3.4. 5.3.3 won't do it. Thanks, Ulf [2010-11-29 14:12:14] paj...@php.net Yes, it happens as well with current SVN (5.3.4RC1 too). [2010-11-29 14:11:19] paj...@php.net As I said it is not possible yet to get an isolated case. I would have done it already if yes. However, anyone able to do a post mortem analysis could see where and maybe why the crash occurs. memory dumb available if you have such developer (or someone willing to try, not too hard :). The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=5 -- Edit this bug report at http://bugs.php.net/bug.php?id=5&edit=1
Bug #53333 [Com]: Random crash
Edit report at http://bugs.php.net/bug.php?id=5&edit=1 ID: 5 Comment by: kriscr...@php.net Reported by:paj...@php.net Summary:Random crash Status: Feedback Type: Bug Package:MySQLi related Operating System: * PHP Version:5.3.3 Assigned To:mysql Block user comment: N Private report: N New Comment: Hi Ulf, I've been running the tests for Pierre and am also the one who first discovered this bug. He asked me to connect with you here because I've been unable to get the debug directive you mentioned to output. Specifically, I'm running the PHP 5.3.4RC1 ZTS Pierre released, VC9 compile, on Apache 2.2 under one of our Windows 2008 R2 hosts with Windbg attached to the process. In php.ini, I added the following line to the MYSQLND section: mysqlnd.debug="d:t:O,C:\temp\mysqlnd_debug.log" The setting does show up in PHPInfo(). Specifically: mysqlnd mysqlnd enabled Version mysqlnd 5.0.7-dev - 091210 - $Revision: 304625 $ Compression supported SSL not supported Command buffer size 4096 Read buffer size32768 Read timeout31536000 Collecting statistics Yes Collecting memory statisticsYes Tracing d:t:O,C:\temp\mysqlnd_debug.log However, the mysqlnd_debug.log file is never created. I'm not sure under what conditions it's supposed to output, but in this test I was hitting both MediaWiki and WordPress until the crash occured, and at no point was the file created. The directory has full perms (including write) granted to all users. I could theoretically use procmon to see if it's attempting to write the file, but since we're dealing with a bug that takes about an hour to repro, that wouldn't be my first choice. Have you had a chance yet to test this new debug feature? Do you know if there are any other settings/etc that need to be enabled in order for this to work? Please let me know and I'll give it another go. Thanks! --Kris Previous Comments: [2010-11-30 12:26:20] paj...@php.net I will ask to enable it and run again the tests. Thanks :) [2010-11-30 12:24:45] u...@php.net Hi Pierre, can you provide a mysqlnd debug log, do you have access to the php.ini? In 5.3.4 mysqlnd learned to write proper debug logs on Windows. Try running PHP with mysqlnd.debug="d:t:O,C:\mysqlnd_debug.log". You need 5.3.4. 5.3.3 won't do it. Thanks, Ulf [2010-11-29 14:12:14] paj...@php.net Yes, it happens as well with current SVN (5.3.4RC1 too). [2010-11-29 14:11:19] paj...@php.net As I said it is not possible yet to get an isolated case. I would have done it already if yes. However, anyone able to do a post mortem analysis could see where and maybe why the crash occurs. memory dumb available if you have such developer (or someone willing to try, not too hard :). [2010-11-29 14:09:13] u...@php.net Pierre, of course, we'd love to see an isolated phpt test case. As you state, it is not necessarily a mysqli issue but may have some other cause. I agree that Andrey should look at the back trace. Can this reproduced with 5.3.4? If so, please check if you can give us a mysqlnd debug log. It is going to be *very* long. As a first step, please provide us with no more than the last 1000 lines from that log. 1000 lines is a a bit of a random pick to limit the expected long debug log. In 5.3.4 mysqlnd learned to write proper debug logs on Windows. Try running PHP with mysqlnd.debug="d:t:O,C:\mysqlnd_debug.log". You need 5.3.4. 5.3.3 won't do it. Andrey, can you have a look at the backtrace? Thanks, Ulf The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=5 -- Edit this bug report at http://bugs.php.net/bug.php?id=5&edit=1
