Bug #60078 [Opn]: SIGSEGV in xhprof.c
Edit report at https://bugs.php.net/bug.php?id=60078&edit=1
ID: 60078
User updated by:odou...@php.net
Reported by:odou...@php.net
Summary:SIGSEGV in xhprof.c
Status: Open
Type: Bug
Package:xhprof
Operating System: -
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
I created a patch for this (tested successfully) :
https://github.com/olivierd/xhprof/commit/2e74533746bf14b0bcfc9a6fae08e1bf9b4f724b
Previous Comments:
[2011-10-19 17:45:05] odou...@php.net
System is Linux 64 x64 (kernel 2.6.36)
Bi CPU Intel(R) Xeon(R) CPU L5630 @ 2.13GHz
I found this bug on a particular machine where some CPUs are deactivated on
purpose
(sorry, this is a major information but I only detected it now).
Command used to deactivate a thread: echo 0 >
/sys/devices/system/cpu/cpu1/online
function bind_to_cpu failed for cpu 1, and now I can see why.
Do you have any idea how to handle this on xhprof ? Maybe not resetting the
whole
hp_globals.cpu_frequencies array if bind_ failed ?
[2011-10-19 17:39:26] scott...@php.net
Any more information about the OS or version of PHP? I have this working fine
on
OS X with PHP 5.3 and PHP 5.4.
[2011-10-18 13:22:27] odou...@php.net
More debugging :
it seems bug is happening in get_cpu_frequency() that returned 0 on line 1335
so
array hp_globals.cpu_frequencies is
wiped out by function clear_frequencies();
Just before, we have an error ("setaffinity: Invalid argument") thrown by line
1228, so my guess is that function
bind_to_cpu() failed, and at the end program is segfaulting because this has an
impact on an array.
[2011-10-17 16:51:21] odou...@php.net
Description:
I'll try to be as precise as possible :
This happens in a special case that can be reproduced 100%, but I cannot
provide
a test
script (it is using 20MB of closed customer code).
This happens only whith xhprof_enable(). No problem is encountered when the
module is just
loaded with no call to xhprof_enable()
In latest clone from git (commit a6bae51236 for file xhprof.c)
Program received signal SIGSEGV, Segmentation fault.
0x73575f49 in hp_mode_shared_endfn_cb (top=0xef0210, symbol=)
at /usr/src/xhprof/extension/xhprof.c:1553
bt
#0 hp_mode_shared_endfn_cb (top=0xef0210, symbol=) at
/usr/src/xhprof/extension/xhprof.c:1553
#1 0x7357609e in hp_mode_hier_endfn_cb (entries=)
at
/usr/src/xhprof/extension/xhprof.c:1573
#2 0x73576e66 in hp_compile_file (file_handle=,
type=8) at
/usr/src/xhprof/extension/xhprof.c:1721
#3 0x007218a4 in ?? ()
#4 0x0071f294 in execute ()
#5 0x006faf7b in zend_execute_scripts ()
#6 0x006b573a in php_execute_script ()
#7 0x00772287 in main ()
Ok so problem is in the function "hp_mode_shared_endfn_cb"
Let's try to see what is the value of each variable here :
print /f hp_globals.cpu_frequencies[hp_globals.cur_cpu_id]
Cannot access memory at address 0x0
ok so problem is in this expression.
print hp_globals.cpu_frequencies
$8 = (double *) 0x0
(gdb) print /f hp_globals.cur_cpu_id
$9 = 0
Ok so I can see that hp_globals.cpu_frequencies equals NULL (right ?), and we
attempt to
access it as an array.
I read the source code quickly, and I can see that this array should be filled
at some
point. Seems it is not.
I made a dirty patch just to avoid the SIGSEGV, but all my timings in xhprof
reports are
inaccurate now.
--
Edit this bug report at https://bugs.php.net/bug.php?id=60078&edit=1
[PHP-BUG] Bug #60119 [NEW]: host="localhost" lost in mysqlnd_ms_get_last_used_connection()
From: uw Operating system: PHP version: Irrelevant Package: mysqlnd_ms Bug Type: Bug Bug description:host="localhost" lost in mysqlnd_ms_get_last_used_connection() Description: mysqlnd_ms_get_last_used_connection() reports wrong host, if host is "localhost". In that case, the host reported is "". Test script: --- Tests in the repository fail, if configured appropriately. FAILED TEST SUMMARY - mysqlnd_ms_get_last_used_connection() [/home/nixnutz/php/php-src/pecl/mysqlnd_ms/trunk/tests/mysqlnd_ms_get_last_used_connection.phpt] mysqlnd_ms_get_last_used_connection() switching [/home/nixnutz/php/php-src/pecl/mysqlnd_ms/trunk/tests/mysqlnd_ms_get_last_used_connection_switches.phpt] Expected result: host="localhost" not host="" Actual result: -- host="" -- Edit bug report at https://bugs.php.net/bug.php?id=60119&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60119&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60119&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60119&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60119&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60119&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60119&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60119&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60119&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60119&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60119&r=support Expected behavior: https://bugs.php.net/fix.php?id=60119&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60119&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60119&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60119&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60119&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60119&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60119&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60119&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60119&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60119&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60119&r=mysqlcfg
[PHP-BUG] Bug #60120 [NEW]: proc_open hangs with stdin/out with 2048+ bytes
From: pajoye
Operating system: windows
PHP version: Irrelevant
Package: Filesystem function related
Bug Type: Bug
Bug description:proc_open hangs with stdin/out with 2048+ bytes
Description:
The stream used to read data from stdin/out/err hangs if the data passed is
getting larger than 2048, under certain circumstances.
Test script:
---
error_reporting(E_ALL);
$cmd = 'php -r "fwrite(STDOUT, $in = file_get_contents(\'php://stdin\'));
fwrite(STDERR, $in);"';
$descriptors = array(array('pipe', 'r'), array('pipe', 'w'), array('pipe',
'w'));
$stdin = str_repeat('*', 1024 * 16) . '!';
$stdin = str_repeat('*', 2049 );
$options = array_merge(array('suppress_errors' => true, 'binary_pipes' =>
true, 'bypass_shell' => false));
$process = proc_open($cmd, $descriptors, $pipes, getcwd(), array(),
$options);
foreach ($pipes as $pipe) {
stream_set_blocking($pipe, false);
}
$writePipes = array($pipes[0]);
$stdinLen = strlen($stdin);
$stdinOffset = 0;
unset($pipes[0]);
while ($pipes || $writePipes) {
$r = $pipes;
$w = $writePipes;
$e = null;
$n = stream_select($r, $w, $e, 60);
if (false === $n) {
break;
} elseif ($n === 0) {
proc_terminate($process);
}
if ($w) {
$written = fwrite($writePipes[0], (binary)substr($stdin,
$stdinOffset), 8192);
if (false !== $written) {
$stdinOffset += $written;
}
if ($stdinOffset >= $stdinLen) {
fclose($writePipes[0]);
$writePipes = null;
}
}
foreach ($r as $pipe) {
$type = array_search($pipe, $pipes);
$data = fread($pipe, 8192);
if (false === $data || feof($pipe)) {
fclose($pipe);
unset($pipes[$type]);
}
}
}
--
Edit bug report at https://bugs.php.net/bug.php?id=60120&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60120&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60120&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60120&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60120&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60120&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60120&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60120&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60120&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60120&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60120&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60120&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60120&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60120&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60120&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60120&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60120&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60120&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60120&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60120&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60120&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60120&r=mysqlcfg
Req #51595 [Com]: passing ini settings via FASTCGI parameters
Edit report at https://bugs.php.net/bug.php?id=51595&edit=1 ID: 51595 Comment by: info at breakdev dot com Reported by:f...@php.net Summary:passing ini settings via FASTCGI parameters Status: Closed Type: Feature/Change Request Package:FPM related Operating System: any PHP Version:trunk Assigned To:fat Block user comment: N Private report: N New Comment: it doesn't work with nginx anf php5-cgi spawn: nginx version: nginx/0.7.67 PHP 5.3.8-1~dotdeb.1 with Suhosin-Patch (cli) (built: Aug 26 2011 12:46:54) I used this line in the nginx.conf: fastcgi_param PHP_ADMIN_VALUE open_basedir=/home/www/docs so there was set $_SERVER['PHP_ADMIN_VALUE']="open_basedir=/home/www/docs" Previous Comments: [2011-08-21 18:06:17] f...@php.net Yes it's been integrated into FPM since 5.3.3 I think. In all the cases, it works with php 5.3.7 [2011-08-21 17:40:43] ywarnier at beeznest dot org Hi guys, has this been sent to any stable release of PHP? I can't find it in any part of http://www.php.net/ChangeLog-5.php#5.3.7 [2010-04-23 19:15:58] f...@php.net 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. It's been commited in revision 298383 In fastcgi headers, only unique values can be passed. So you have to concatenate differentes value in one and separate them with a new line character (\n). For exemple in nginx, it could be done this way: set $php_value "pcre.backtrack_limit=424242"; set $php_value "$php_value \n pcre.recursion_limit=9"; fastcgi_param PHP_VALUE $php_value; fastcgi_param PHP_ADMIN_VALUE "open_basedir=/var/www/htdocs"; In lighttpd, it seems there is no options to pass custom headers :/ [2010-04-23 18:06:04] f...@php.net Automatic comment from SVN on behalf of fat Revision: http://svn.php.net/viewvc/?view=revision&revision=298383 Log: Add PHP_VALUE and PHP_ADMIN_VALUE interpretation from fastcgi headers. It works as php_value and php_admin_value from the main conf file or apache sapi. See bug (request) #51595 [2010-04-19 09:14:02] f...@php.net thanks for the correction 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=51595 -- Edit this bug report at https://bugs.php.net/bug.php?id=51595&edit=1
Bug #60116 [Asn->]: escapeshellcmd() cannot escape the chars which causes shell injection.
Edit report at https://bugs.php.net/bug.php?id=60116&edit=1 ID: 60116 Updated by: hirok...@php.net Reported by:hirok...@php.net Summary:escapeshellcmd() cannot escape the chars which causes shell injection. -Status: Assigned +Status: To be documented Type: Bug Package:Filter related Operating System: Ubuntu Linux PHP Version:trunk-SVN-2011-10-23 (SVN) Assigned To:hirokawa Block user comment: N Private report: N 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. Previous Comments: [2011-10-23 15:08:28] tyr...@php.net judging from http://svn.php.net/viewvc?view=revision&revision=318342 this can be closed, right? [2011-10-23 13:49:52] hirok...@php.net Automatic comment from SVN on behalf of hirokawa Revision: http://svn.php.net/viewvc/?view=revision&revision=318342 Log: fixed bug #60116 escapeshellcmd() cannot escape the dangerous quotes. [2011-10-23 11:17:25] hirok...@php.net The following patch has been added/updated: Patch Name: php-escape.patch Revision: 1319368645 URL: https://bugs.php.net/patch-display.php?bug=60116&patch=php-escape.patch&revision=1319368645 [2011-10-23 11:16:45] hirok...@php.net Description: escapeshellcmd() escapes " and ' only if it isn't paired (it is documented in the PHP manual). For the test script to look for some keyword in the files of the specified directory (/var/data/), the double quotation in the user input as shown below cannot be escaped because it is paired (it is found by Mr. Tokumaru). $_GET['key'] = ':" "/etc/passwd'; The command line will be, grep ":" "/etc/passwd" /var/data/* The content of arbitrary file such as /etc/passwd will be shown. The attached patch (made by Mr. Ohgaki, slightly modified be me) will add an option flag for escapeshellcmd(). The recommended code to escape the quotation in this case will be, $key = escapeshellcmd($_GET['key'], ESCAPE_CMD_ALL); output: grep ":\" \"/etc/passwd" /var/data/* The option flag has the three different value. There is no backward incompatibility because the default behavior (ESCAPE_CMD_PAIR) is unchanged. ESCAPE_CMD_PAIR : escape if it is not paired (default) ESCAPE_CMD_END : escape except for end/beginning of the string ESCAPE_CMD_ALL : escape without exception (recommended) In Windows, the quotation is always escaped, but, in other environment, it is only escaped if it is not paired. It is highly recommended to apply this patch to prevent the possible shell command injection attack. Test script: --- Expected result: grep ":\" \"/etc/passwd" /var/data/* Actual result: -- grep ":" "/etc/passwd" /var/data/* [content of /etc/passwd] -- Edit this bug report at https://bugs.php.net/bug.php?id=60116&edit=1
[PHP-BUG] Bug #60121 [NEW]: fgetcsv ignores empty columns
From:
Operating system: All
PHP version: 5.3.8
Package: Filesystem function related
Bug Type: Bug
Bug description:fgetcsv ignores empty columns
Description:
The patch to bug #53848 has broken fgetcsv when it reads "empty" fields and
an
enclosure is used. Before this patch, the actual result was the same as the
expected result.
Test script:
---
print_r(str_getcsv("1\t2\t3", "\t", "'"));// This works
print_r(str_getcsv("1\t\t3", "\t", "")); // This works
print_r(str_getcsv("'1'\t\t'3'", "\t", "'")); // This one is broken (used
to work)
Expected result:
Array
(
[0] => 1
[1] => 2
[2] => 3
)
Array
(
[0] => 1
[1] =>
[2] => 3
)
Array
(
[0] => 1
[1] =>
[2] => 3
)
Actual result:
--
Array
(
[0] => 1
[1] => 2
[2] => 3
[3] => 3
)
Array
(
[0] => 1
[1] =>
[2] => 3
)
Array
(
[0] => 1
[1] => 3
)
--
Edit bug report at https://bugs.php.net/bug.php?id=60121&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60121&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60121&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60121&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60121&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60121&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60121&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60121&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60121&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60121&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60121&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60121&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60121&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60121&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60121&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60121&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60121&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60121&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60121&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60121&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60121&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60121&r=mysqlcfg
[PHP-BUG] Bug #60122 [NEW]: Many multi-row statements gives wrong result
From:
Operating system: windows 7
PHP version: 5.3.8
Package: PDO related
Bug Type: Bug
Bug description:Many multi-row statements gives wrong result
Description:
If you create two query of multi-row statements in one .php file and you
assign
them
to the same variable after processing one of them, the second query will
give only
result of only ONE statement.
If you assign the result of query to another variable, the result will be
correct.
So$another_var_name = $conn->query("SELECT 1 as one; SELECT 2 as two;
SELECT 3
as three;");
will work in Test script, otherwise result will be wrong.
Test script:
---
$q = $conn->query("SELECT 1 as one; SELECT 2 as two; SELECT
3 as three;");
do
{
$r=$q->fetchAll(PDO::FETCH_ASSOC);
echo "";
print_r($r);
}while($q->nextRowset());
$q = $conn->query("SELECT 1 as one; SELECT 2 as two; SELECT
3 as three;");
do
{
$r=$q->fetchAll(PDO::FETCH_ASSOC);
echo "";
print_r($r);
}while($q->nextRowset());
Expected result:
Array ( [0] => Array ( [one] => 1 ) )
Array ( [0] => Array ( [two] => 2 ) )
Array ( [0] => Array ( [three] => 3 ) )
Array ( [0] => Array ( [one] => 1 ) )
Array ( [0] => Array ( [two] => 2 ) )
Array ( [0] => Array ( [three] => 3 ) )
Actual result:
--
Array ( [0] => Array ( [one] => 1 ) )
Array ( [0] => Array ( [two] => 2 ) )
Array ( [0] => Array ( [three] => 3 ) )
Array ( [0] => Array ( [one] => 1 ) )
--
Edit bug report at https://bugs.php.net/bug.php?id=60122&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60122&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60122&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60122&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60122&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60122&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60122&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60122&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60122&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60122&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60122&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60122&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60122&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60122&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60122&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60122&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60122&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60122&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60122&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60122&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60122&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60122&r=mysqlcfg
[PHP-BUG] Bug #60123 [NEW]: Metaphone returns string longer than limit
From: Operating system: Windows XP SP3 PHP version: 5.3.8 Package: Unknown/Other Function Bug Type: Bug Bug description:Metaphone returns string longer than limit Description: The metaphone function accepts two parameters: an input string, and a string length limit. With certain input, it is possible to cause metaphone to return a string longer than the specified limit. The issue seems to arise when the string is nearing it's length limit and the following input character is an X, which can translate to a KS, pushing the string over its limit. Test script: --- Expected result: string(10) "ATMNSTRTRK" string(5) "ASTRK" Actual result: -- string(11) "ATMNSTRTRKS" string(6) "ASTRKS" -- Edit bug report at https://bugs.php.net/bug.php?id=60123&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60123&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60123&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60123&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60123&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60123&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60123&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60123&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60123&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60123&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60123&r=support Expected behavior: https://bugs.php.net/fix.php?id=60123&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60123&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60123&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60123&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60123&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60123&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60123&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60123&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60123&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60123&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60123&r=mysqlcfg
[PHP-BUG] Req #60124 [NEW]: Allow for Custom Application name in MSSQL connection
From: Operating system: FreeBSD (should work on any) PHP version: 5.3.8 Package: MSSQL related Bug Type: Feature/Change Request Bug description:Allow for Custom Application name in MSSQL connection Description: MSSQL (and FreeTDS) has the notion of Application Name on for the connection. In the php5 mssql module it hard codes that to 'PHP 5'. Ideally this would be a user configurable setting. When multiple PHP applications are connecting to the same MSSQL database it makes it much easier to distinguish between connections by this Application Name. Expected result: By Applying this patch it allows the user to set an application for the connection and it is visible in the MSSQL profiler and other tools. //Example Use: $dbhandle = mssql_pconnect($server_name, $user, $password, $new_link, "My PHP App"); -- Edit bug report at https://bugs.php.net/bug.php?id=60124&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60124&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60124&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60124&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60124&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60124&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60124&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60124&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60124&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60124&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60124&r=support Expected behavior: https://bugs.php.net/fix.php?id=60124&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60124&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60124&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60124&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60124&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60124&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60124&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60124&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60124&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60124&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60124&r=mysqlcfg
Req #60098 [Com]: Static constructors, or static intializers
Edit report at https://bugs.php.net/bug.php?id=60098&edit=1 ID: 60098 Comment by: dagguh at gmail dot com Reported by:syntaqx at gmail dot com Summary:Static constructors, or static intializers Status: Open Type: Feature/Change Request Package:SPL related Operating System: All PHP Version:5.4.0beta1 Block user comment: N Private report: N New Comment: You mean something like Static Initialization Blocks from Java? Yeah, I'd like to see them too. http://download.oracle.com/javase/tutorial/java/javaOO/initial.html Previous Comments: [2011-10-19 17:48:18] syntaqx at gmail dot com Description: I've noticed a fairly large trend in a lot of php frameworks, as well as in my own code, and I was curious about whether this is planned, the reasons as to why it might not be, or if it has even been brought up. I've tried to find any other requests about this, but haven't been very successful. Basically, my request is this: When a class comes into existence (whether the code is in the file you're currently in, or you're including it), a static constructor (a common method for it is "::init") is called. This is called only once, the first time the class exists, and would act as a protected method (allowing parent-child objects to call it incase of a class reset?). This would be pretty awesome, but I don't know if it's practical, or what all your thoughts might have been as I'm sure plenty of you have seen it floating around. Thanks a bunch for taking the time to read my request, I'm excited to hear what you think :) -- Edit this bug report at https://bugs.php.net/bug.php?id=60098&edit=1
Bug #60110 [Opn]: fclose(), file_put_contents(), copy() do not return false properly
Edit report at https://bugs.php.net/bug.php?id=60110&edit=1
ID: 60110
User updated by:tom at punkave dot com
Reported by:tom at punkave dot com
Summary:fclose(), file_put_contents(), copy() do not return
false properly
Status: Open
Type: Bug
Package:Filesystem function related
Operating System: all
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
How about a close_checks_flush php.ini flag which defaults to false in 5.3 and
to
true in 5.4?
Previous Comments:
[2011-10-21 21:35:52] tom at punkave dot com
This can definitely happen with the regular stdio stuff. stdio employs
buffering
as a matter of course. It is a serious bug, not a change in behavior.
As for stream wrappers, the documentation specifies what stream_flush is
supposed to return, and fflush() would already be failing for people with bad
stream wrappers who did not heed that documentation.
stream_close is not supposed to return anything but is not affected by this bug
because stream_flush has already been called (and cheerfully ignored) before
stream_close is called (I checked).
So there is no need to change the behavior of stream_close (which would be a bc
break). We just need to pay attention to what stream_flush is already telling
us.
[2011-10-21 21:23:22] cataphr...@php.net
See bug #53328. This is a good candidate for trunk, for stable versions I fear
(perhaps unfoundedly) that, because the return value of php_stream_close/free
is almost always ignored, some wrappers might have gotten away with incorrect
return values on the close handler.
[2011-10-21 19:38:23] tom at punkave dot com
Description:
The fclose() function does not check the result of flushing the stream:
if (!stream->is_persistent) {
zend_list_delete(stream->rsrc_id);
} else {
php_stream_pclose(stream);
}
RETURN_TRUE;
php_stream_pclose has a return value but it is ignored.
php_stream_pclose, in turn, calls _php_stream_free which flushes the stream but
does not check the return value either:
/* make sure everything is saved */
_php_stream_flush(stream, 1 TSRMLS_CC);
Contrary to the comment we did not make sure of anything (:
So the fix has to be made at least as deep as _php_stream_flush to be
effective.
I have verified that _php_stream_flush does pay attention to the result of the
underlying flush operation. Note that fflush() reports write errors
successfully
while fclose() doesn't).
In many environments, including stdio (plain old files), the final write to
disk
might not sometimes occur until the stream is flushed by _php_stream_flush. If
this fails, for instance because the disk is full, PHP pays no heed to the
error.
This is especially obvious if you use a stream wrapper that does its actual
writing when the stream is closed (for instance storing an object with a single
HTTP request), but again, it could happen with normal files too.
Because of this deeper issue with _php_stream_free, all other PHP convenience
functions for files such as copy() and file_put_contents() also fail to
correctly report false when the final flush of data to disk fails when closing
a
file.
This has serious consequences for any application that is counting on data
integrity, which would be pretty much every application that uses files I guess.
--
Edit this bug report at https://bugs.php.net/bug.php?id=60110&edit=1
Bug #49051 [Com]: XMLWriter::openURI() cannot resolve file path containing slash
Edit report at https://bugs.php.net/bug.php?id=49051&edit=1
ID: 49051
Comment by: sinthia at fireflowdesign dot com
Reported by:major at minet dot sk
Summary:XMLWriter::openURI() cannot resolve file path
containing slash
Status: No Feedback
Type: Bug
Package:XML Writer
Operating System: Vista 32bit
PHP Version:5.3.0
Block user comment: N
Private report: N
New Comment:
I am having the same problem with a relative path on windows7.
Previous Comments:
[2010-10-04 14:11:49] ekschperte at mysc dot de
I have the same problem...XP SP3 32bit
$xml->openURI('data/file.xml'); -> DOES NOT WORK!
The code works on 5.2.9. :-(
[2010-06-13 03:35:48] dandandare at yahoo dot es
PHP Version: 5.3.1
OS Version: XP SP3 32bit
$xml->openURI('file.xml'); -> ok!
$xml->openURI('../file.xml'); -> ok!
$xml->openURI('xml/file.xml'); -> DON'T WORK!
$xml->openURI('../xml/file.xml'); -> DON'T WORK!
Don't work when you tries to access to a directory, why?
[2010-02-24 01:00:02] 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".
[2010-02-16 10:09:30] paj...@php.net
@afpral dot com at gmail dot com
Be sure that the directory exists (data/).
[2010-02-16 09:57:30] afpral dot com at gmail dot com
Warning: XMLWriter::openUri() [xmlwriter.openuri]: Unable to resolve file path
With DIRECTORY_SEPARATOR uri to
not the same issue with only file name.
Parse filepath problem
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=49051
--
Edit this bug report at https://bugs.php.net/bug.php?id=49051&edit=1
[PHP-BUG] Bug #60126 [NEW]: Assigning node value results inserting selected node.
From: Operating system: any PHP version: 5.3.8 Package: SimpleXML related Bug Type: Bug Bug description:Assigning node value results inserting selected node. Description: Updating node value result inserting selected node. PHP should update value, NOT inserting selected node. This bug is located at ext/simplexml.c static int sxe_prop_dim_write(zval *object, zval *member, zval *value, zend_bool elements, zend_bool attribs, xmlNodePtr *pnewnode TSRMLS_DC) It seems the logic is broken for this case. Test script: --- value XML; $xml = simplexml_load_string($string); $xml->root->node = "NEW VALUE"; print $xml->asXML(); Expected result: value NEW VALUE Actual result: -- NEW VALUE -- Edit bug report at https://bugs.php.net/bug.php?id=60126&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60126&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60126&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60126&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60126&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60126&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60126&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60126&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60126&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60126&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60126&r=support Expected behavior: https://bugs.php.net/fix.php?id=60126&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60126&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60126&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60126&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60126&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60126&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60126&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60126&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60126&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60126&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60126&r=mysqlcfg
Bug #60126 [Opn]: Assigning node value results inserting selected node.
Edit report at https://bugs.php.net/bug.php?id=60126&edit=1 ID: 60126 User updated by:yohgaki at ohgaki dot net Reported by:yohgaki at ohgaki dot net Summary:Assigning node value results inserting selected node. Status: Open Type: Bug Package:SimpleXML related Operating System: any PHP Version:5.3.8 Block user comment: N Private report: N New Comment: Oops. I swapped Expected and Actual result, but I'm sure that you get the idea. Previous Comments: [2011-10-25 01:56:29] yohgaki at ohgaki dot net Description: Updating node value result inserting selected node. PHP should update value, NOT inserting selected node. This bug is located at ext/simplexml.c static int sxe_prop_dim_write(zval *object, zval *member, zval *value, zend_bool elements, zend_bool attribs, xmlNodePtr *pnewnode TSRMLS_DC) It seems the logic is broken for this case. Test script: --- value XML; $xml = simplexml_load_string($string); $xml->root->node = "NEW VALUE"; print $xml->asXML(); Expected result: value NEW VALUE Actual result: -- NEW VALUE -- Edit this bug report at https://bugs.php.net/bug.php?id=60126&edit=1
Bug #60126 [Opn->Csd]: Assigning node value results inserting selected node.
Edit report at https://bugs.php.net/bug.php?id=60126&edit=1 ID: 60126 User updated by:yohgaki at ohgaki dot net Reported by:yohgaki at ohgaki dot net Summary:Assigning node value results inserting selected node. -Status: Open +Status: Closed Type: Bug Package:SimpleXML related Operating System: any PHP Version:5.3.8 Block user comment: N Private report: N New Comment: Bogus. Forgot to ignore root node. Previous Comments: [2011-10-25 01:58:53] yohgaki at ohgaki dot net Oops. I swapped Expected and Actual result, but I'm sure that you get the idea. [2011-10-25 01:56:29] yohgaki at ohgaki dot net Description: Updating node value result inserting selected node. PHP should update value, NOT inserting selected node. This bug is located at ext/simplexml.c static int sxe_prop_dim_write(zval *object, zval *member, zval *value, zend_bool elements, zend_bool attribs, xmlNodePtr *pnewnode TSRMLS_DC) It seems the logic is broken for this case. Test script: --- value XML; $xml = simplexml_load_string($string); $xml->root->node = "NEW VALUE"; print $xml->asXML(); Expected result: value NEW VALUE Actual result: -- NEW VALUE -- Edit this bug report at https://bugs.php.net/bug.php?id=60126&edit=1
Req #59918 [Asn]: Progress for uploads > 2GB breaks (32bit issue?)
Edit report at https://bugs.php.net/bug.php?id=59918&edit=1 ID: 59918 Updated by: larue...@php.net Reported by:chris at easynethk dot com Summary:Progress for uploads > 2GB breaks (32bit issue?) Status: Assigned Type: Feature/Change Request Package:uploadprogress Operating System: CentOS 5.2 PHP Version:5.3.6 Assigned To:chregu Block user comment: N Private report: N New Comment: may be due to the read_byte variable in uploadprogress_php_rfc1867_file(uploadprogress.c) it was declared to be int, change it to size_t might fix this problem(not sure, didn't test). thanks Previous Comments: [2011-10-24 03:33:31] chris at easynethk dot com Where is the fix, then? :) [2011-10-24 02:37:20] larue...@php.net assign the 250 USD to author. :) [2011-10-24 01:21:21] chris at easynethk dot com Noone here that can supply a patch or some fix for this issue? I will PayPal 250 USD to the first person that supplies a fix :) [2011-09-24 03:06:21] wilcobeekhuizen at gmail dot com This problem also happens when uploading multiple files that are more than 2GB combined. bytes_total is negative and est_sec is sometimes a negative number and other times a positive number. Casting these numbers to an abs value (removing the negative sign) does not yield correct results. [2011-08-31 04:09:42] chris at easynethk dot com Description: Progress for uploads > 2 GB break. Even though we're using the uploadprogress on 64bit machines. Any chance you can solve this with the next update? Nowadays more modern browsers have the capability to upload files larger than 2GB, and this limitation should really be removed from the uploadprogress module to be ready for the future. Feedback is highly appreciated. -- Edit this bug report at https://bugs.php.net/bug.php?id=59918&edit=1
Bug #60121 [Opn->Csd]: fgetcsv ignores empty columns
Edit report at https://bugs.php.net/bug.php?id=60121&edit=1
ID: 60121
Updated by: larue...@php.net
Reported by:roborg at hotmail dot com
Summary:fgetcsv ignores empty columns
-Status: Open
+Status: Closed
Type: Bug
Package:Filesystem function related
Operating System: All
PHP Version:5.3.8
-Assigned To:
+Assigned To:laruence
Block user comment: N
Private report: N
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/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
see #55674, this has been fixed
Previous Comments:
[2011-10-24 14:43:36] roborg at hotmail dot com
Description:
The patch to bug #53848 has broken fgetcsv when it reads "empty" fields and an
enclosure is used. Before this patch, the actual result was the same as the
expected result.
Test script:
---
print_r(str_getcsv("1\t2\t3", "\t", "'"));// This works
print_r(str_getcsv("1\t\t3", "\t", "")); // This works
print_r(str_getcsv("'1'\t\t'3'", "\t", "'")); // This one is broken (used to
work)
Expected result:
Array
(
[0] => 1
[1] => 2
[2] => 3
)
Array
(
[0] => 1
[1] =>
[2] => 3
)
Array
(
[0] => 1
[1] =>
[2] => 3
)
Actual result:
--
Array
(
[0] => 1
[1] => 2
[2] => 3
[3] => 3
)
Array
(
[0] => 1
[1] =>
[2] => 3
)
Array
(
[0] => 1
[1] => 3
)
--
Edit this bug report at https://bugs.php.net/bug.php?id=60121&edit=1
