#39990 [NEW]: Cannot foreach over overloaded properties
From: michael dot walter at gmail dot com
Operating system: Windows XP
PHP version: 5.2.0
PHP Bug Type: Compile Failure
Bug description: Cannot foreach over overloaded properties
Description:
This is using PHP 5.2.1 RC 1 (the one Edin posted to PHP-DEV recently).
Reproduce code:
---
?php
class Klass
{
public function __get($name_)
{
return array('Hello', 'World');
}
};
$obj=new Klass();
foreach($obj-arr as $value)
echo $value;
?
Expected result:
HelloWorld
Actual result:
--
PHP Notice: Indirect modification of overloaded property Klass::$arr has
no effect in test.php on line 11
Notice: Indirect modification of overloaded property Klass::$arr has no
effect in test.php on line 11
HelloWorld
--
Edit bug report at http://bugs.php.net/?id=39990edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=39990r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=39990r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=39990r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39990r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=39990r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=39990r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39990r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39990r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=39990r=support
Expected behavior:http://bugs.php.net/fix.php?id=39990r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=39990r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=39990r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39990r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39990r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39990r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39990r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=39990r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=39990r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=39990r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39990r=mysqlcfg
#39987 [Opn]: loss of resources
ID: 39987
User updated by: wojtekm86 at konto dot pl
Reported By: wojtekm86 at konto dot pl
Status: Open
Bug Type: Semaphore related
Operating System: Linux
PHP Version: 5.2.0
New Comment:
I think that there is also a problem with parameter max_acquire because
value in column nsems always equals 3
Previous Comments:
[2006-12-29 17:45:15] wojtekm86 at konto dot pl
Next code.
I have a test script with code as follows:
?php
$id = sem_get(10);
sem_acquire($id);
for($ind = 0; $ind 1; $ind++) { }
sem_release($id);
?
I run it only once.
The result I get after execute command ipcs -s on the server:
-- Semaphore Arrays
keysemid owner perms nsems
0x000a 131075 www_php-a 6663
It seems that there is a problem with semaphores' removal after
release.
[2006-12-29 17:33:32] wojtekm86 at konto dot pl
I think it doesn't.
In my script I have class Semaphore.
There are methods like acquire() and release().
After each sem_acquire instruction I wrote:
echo('I\'ve acquired semaphore key: ' . $this-key . 'br');
After each sem_release instruction I wrote:
echo('I\'ve released semaphore key: ' . $this-key . 'br');
I have executed script only once.
The result I saw is:
I've acquired semaphore key: 1376159737
I've released semaphore key: 1376159737
I've acquired semaphore key: 1376159747
I've released semaphore key: 1376159747
I've acquired semaphore key: 1376159737
I've released semaphore key: 1376159737
I've acquired semaphore key: 1376159748
I've released semaphore key: 1376159748
I've acquired semaphore key: 1376159737
I've released semaphore key: 1376159737
I've acquired semaphore key: 1376159749
I've released semaphore key: 1376159749
As you can see each semaphore is released.
But when I run command ipcs -s on my server I get:
-- Semaphore Arrays
keysemid owner perms nsems
0x520687e6 131075 www_php-a 6003
0x520687f9 163844 www_php-a 6003
0x520687fa 196613 www_php-a 6003
0x520687fc 229382 www_php-a 6003
0x520687e9 262151 www_php-a 6003
0x520687fd 294920 www_php-a 6003
0x520687fe 327689 www_php-a 6003
0x520687ff 360458 www_php-a 6003
0x52068800 393227 www_php-a 6003
0x52068801 425996 www_php-a 6003
0x52068802 458765 www_php-a 6003
0x52068803 491534 www_php-a 6003
0x52068804 524303 www_php-a 6003
0x52068805 557072 www_php-a 6003
You can see that there are not removed semaphores.
[2006-12-29 17:14:48] [EMAIL PROTECTED]
Cannot reproduce.
sem_release() DOES remove the semaphor if no other process uses it.
[2006-12-29 17:01:23] wojtekm86 at konto dot pl
Description:
It's impossible to correct remove semaphores with sem_remove function
when I use them to provide execution of concurrent processes.
When the last process releases the semaphore I should be able to remove
it. But I don't know if another process haven't acquired the semaphore.
For safety reasons I don't remove released semaphores from system.
Now, If I get 128 semaphores and I execute sem_get one more time I will
get warning.
So, I can't remove semaphores (because I don't know if another process
is using it) and I can't get next semaphore.
Reproduce code:
---
$id = sem_get(SOME_ID);
sem_acquire($id);
HERE IS CRITICAL REGION
sem_release($id);
Expected result:
Expected result (and correct, I think) is removal of unused semaphore
in sem_release function if another process didn't acquire it and isn't
waiting for doing this.
Release and Removal of semaphore should be one chain of instructions
without possibility of separation (e.g. by interruption).
Actual result:
--
System reaches the maximum number of semaphores and warning is
reported.
The warning is: Warning: sem_get() [function.sem-get]: failed for key
0x5202e59f: No space
left on device in /home/cicik/ftp/php-art/klasy/semafor.php on line 8
--
Edit this bug report at http://bugs.php.net/?id=39987edit=1
#39991 [NEW]: session_write_close
From: mauricebis at gmail dot com Operating system: linux PHP version: 4.4.4 PHP Bug Type: Filesystem function related Bug description: session_write_close Description: I experienced a race situation with session_write_close where the lock (acquired in session_start) was released before the updated $_SESSION variables were visible to other processes. Another process blocked on session_start was allowed to proceed but could not read the session variables supposedly written through session_write_close. -- Edit bug report at http://bugs.php.net/?id=39991edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39991r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39991r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39991r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39991r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39991r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39991r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39991r=needscript Try newer version:http://bugs.php.net/fix.php?id=39991r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39991r=support Expected behavior:http://bugs.php.net/fix.php?id=39991r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39991r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39991r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39991r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39991r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39991r=dst IIS Stability:http://bugs.php.net/fix.php?id=39991r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39991r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39991r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39991r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39991r=mysqlcfg
#39984 [Opn-Fbk]: Response header sent as 302 despite being set to 301
ID: 39984 Updated by: [EMAIL PROTECTED] Reported By: marc dot bau at gmx dot net -Status: Open +Status: Feedback Bug Type: IIS related Operating System: WinXP PHP Version: 5.2.0 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip Using the latests snaps I get: HTTP/1.1 301 Undescribed from both IIS 5.1 and IIS 7. Previous Comments: [2006-12-29 19:16:56] marc dot bau at gmx dot net same results with ISAPI Plugin php5isapi.dll: GET /test.php HTTP/1.1 Host: localhost User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Language: de,en;q=0.8,en-us;q=0.6,de-de;q=0.4,es;q=0.2 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Cookie: PHPSESSID=m9qi6v871710hj32f7b5cq6317; ASPSESSIONIDQQBCCSTD=MIFPNOKCDKGFBIKNGDIINLMM; CFID=3396; CFTOKEN=156ca9b801cf2d95%2DCF7CD840%2DBCDB%2D4EA9%2D271106C3DB1FE210; JSESSIONID=e0307f68472e511136a6 HTTP/1.x 302 Object Moved Server: Microsoft-IIS/5.1 Date: Fri, 29 Dec 2006 19:15:30 GMT Connection: close Content-Type: text/html X-Powered-By: PHP/5.2.0 Location: http://example.com [2006-12-29 18:36:01] marc dot bau at gmx dot net Installing Apache on Windows makes no sense to me. I know it is working with Apache 2.0 and CGI on a Linux (SuSE 9.3) box. ASP Code Example - works: %@ Language=VBScript % % Response.Status=301 Moved Permanently Response.AddHeader Location, http://www.example.com/; % ASP Headers results: GET /test.asp HTTP/1.1 Host: localhost User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Language: de,en;q=0.8,en-us;q=0.6,de-de;q=0.4,es;q=0.2 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Cookie: PHPSESSID=m9qi6v871710hj32f7b5cq6317; ASPSESSIONIDQQBCCSTD=MIFPNOKCDKGFBIKNGDIINLMM HTTP/1.x 301 Moved Permanently Server: Microsoft-IIS/5.1 Date: Fri, 29 Dec 2006 18:27:01 GMT X-Powered-By: ASP.NET Location: http://www.example.com/ Content-Length: 0 Content-Type: text/html Cache-Control: private ColdFusion MX 7.02 Example - Code: CFHEADER statusCode=301 statusText=Moved Permanently CFHEADER name=Location value=http://www.example.com/; CFMX Header Results: GET /test.cfm HTTP/1.1 Host: localhost User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Language: de,en;q=0.8,en-us;q=0.6,de-de;q=0.4,es;q=0.2 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Cookie: PHPSESSID=m9qi6v871710hj32f7b5cq6317; ASPSESSIONIDQQBCCSTD=MIFPNOKCDKGFBIKNGDIINLMM HTTP/1.x 301 Moved Permanently Server: Microsoft-IIS/5.1 Date: Fri, 29 Dec 2006 18:33:27 GMT X-Powered-By: ASP.NET Connection: close Set-Cookie: CFID=3396;expires=Fri, 12-Jan-2007 18:33:27 GMT;path=/ Set-Cookie: CFTOKEN=156ca9b801cf2d95%2DCF7CD840%2DBCDB%2D4EA9%2D271106C3DB1FE210;expires=Fri, 12-Jan-2007 18:33:27 GMT;path=/ Set-Cookie: JSESSIONID=e0307f68472e511136a6;path=/ Location: http://www.example.com/ Content-Language: de-DE Content-Type: text/html; charset=UTF-8 All on the same machine this PHP 5.2 is installed, too. Now - i think - IIS is not the cause of this bug. [2006-12-29 18:12:20] [EMAIL PROTECTED] I mean that IIS might change this code for some reason. One of the possible ways to check it out would be to install Apache with PHP CGI and verify that it works ok. Since they share the same code, it would mean that the problem is somewhere else. [2006-12-29 18:05:52] marc dot bau at gmx dot net What are you talking about regarding Please make sure IIS does not translate 301 to 302. ? [2006-12-29 18:03:38] marc dot bau at gmx dot net GET /test.php HTTP/1.1 Host: localhost User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Language: de,en;q=0.8,en-us;q=0.6,de-de;q=0.4,es;q=0.2 Accept-Encoding: gzip,deflate Accept-Charset:
#37669 [Asn-Bgs]: Setting a node's value from array returned by xpath does not work
ID: 37669
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Assigned
+Status: Bogus
Bug Type: SimpleXML related
Operating System: Linux (Gentoo, RHEL)
PHP Version: 5.1.4
Assigned To: helly
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
You have to use DOM there. All you were doing was replacing the item at
index 0 in the $nodes array with the string World.
Previous Comments:
[2006-06-20 14:25:24] [EMAIL PROTECTED]
Marcus, could you pla take a look at it?
[2006-06-02 04:39:49] [EMAIL PROTECTED]
I've come up with a workaround which imports the SimpleXML obkect into
DOM and then converts back, but this, of course, defeats the purpose of
SimpleXML. For reference I will post it here for others who need a
solution to this problem:
$domnode = dom_import_simplexml($xml);
$dom = new DOMDocument();
$domnode = $dom-importNode($domnode, true);
$dom-appendChild($domnode);
$x = new DOMXPath($dom);
$n = $x-evaluate('/root/node');
while ($n-item(0)-firstChild) {
$n-item(0)-removeChild($n-firstChild);
}
$n-item(0)-appendChild($dom-createTextNode('World'));
$xml = simplexml_import_dom($dom);
[2006-06-02 00:44:25] [EMAIL PROTECTED]
Description:
When trying to set the value (inside text) of a node from an array
returned from an xpath call nothing happens. Setting an attribute works
fine, however. Setting via normal - access works as expected.
Reproduce code:
---
$xml = simplexml_load_string('rootnode/node2//root');
if (is_array($nodes = $xml-xpath('node'))
sizeof($nodes) 0
is_object($nodes[0])) {
$nodes[0]['value'] = 'Hello';
$nodes[0] = 'World';
}
$xml-node2 = 'World';
header('Content-Type: text/xml');
echo $xml-asXML();
Expected result:
rootnode value=HelloWorld/nodenode2World/node2/root
Actual result:
--
rootnode value=Hello/node2World/node2/root
--
Edit this bug report at http://bugs.php.net/?id=37669edit=1
#39760 [Asn-Csd]: cloning fails on nested SimpleXML-Object
ID: 39760 Updated by: [EMAIL PROTECTED] Reported By: saschagros at bluewin dot ch -Status: Assigned +Status: Closed Bug Type: SimpleXML related Operating System: Windows/Linux PHP Version: 5.2.0 Assigned To: helly New Comment: 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. Previous Comments: [2006-12-06 22:20:13] saschagros at bluewin dot ch Description: clone $simpleXML-subElement1-subElement2 does not work as excepted. It does not return a clone of itself but a clone of it's parent. Tested on: Windows with PHP 5.2.0 Linux with PHP 5.2.0 Linux with PHP 5.0.4 Reproduce code: --- $xml = '?xml version=1.0 ? test level1 level2atext1/level2a level2btext2/level2b /level1 /test'; $test = simplexml_load_string($xml); print_r($test-level1-level2a); $test2 = clone $test; print_r($test2-level1-level2a); $test3 = clone $test-level1-level2a; print_r($test3); Expected result: SimpleXMLElement Object ( [0] = text1 ) SimpleXMLElement Object ( [0] = text1 ) SimpleXMLElement Object ( [0] = text1 ) Actual result: -- SimpleXMLElement Object ( [0] = text1 ) SimpleXMLElement Object ( [0] = text1 ) SimpleXMLElement Object ( [level2a] = text1 [level2b] = text2 ) -- Edit this bug report at http://bugs.php.net/?id=39760edit=1
#39992 [NEW]: proc_terminate() leaves children of child running
From: [EMAIL PROTECTED]
Operating system: linux
PHP version: 6CVS-2006-12-30 (CVS)
PHP Bug Type: Program Execution
Bug description: proc_terminate() leaves children of child running
Description:
With the short reproduce code below, PHP fork()s a new process (sh), that
itself forks a new one (php). proc_terminate() kill()s the sh process, but
the php one doesn't get killed.
I'm not really sure what is causing this problem, but it is breaking
run-tests.php on timeout.
Reproduce code:
---
?php
$cmd='php -r while(1){} 21';
$proc = proc_open($cmd, array(), $pipes);
var_dump(proc_terminate($proc));
?
--
Edit bug report at http://bugs.php.net/?id=39992edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=39992r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=39992r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=39992r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39992r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=39992r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=39992r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39992r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39992r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=39992r=support
Expected behavior:http://bugs.php.net/fix.php?id=39992r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=39992r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=39992r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39992r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39992r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39992r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39992r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=39992r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=39992r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=39992r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39992r=mysqlcfg
#39992 [Opn]: proc_terminate() leaves children of child running
ID: 39992
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Program Execution
Operating System: linux
PHP Version: 6CVS-2006-12-30 (CVS)
New Comment:
Ah I forgot: removing the 21 part everything works fine.
Previous Comments:
[2006-12-30 15:52:20] [EMAIL PROTECTED]
Description:
With the short reproduce code below, PHP fork()s a new process (sh),
that itself forks a new one (php). proc_terminate() kill()s the sh
process, but the php one doesn't get killed.
I'm not really sure what is causing this problem, but it is breaking
run-tests.php on timeout.
Reproduce code:
---
?php
$cmd='php -r while(1){} 21';
$proc = proc_open($cmd, array(), $pipes);
var_dump(proc_terminate($proc));
?
--
Edit this bug report at http://bugs.php.net/?id=39992edit=1
#39990 [Opn-Asn]: Cannot foreach over overloaded properties
ID: 39990
Updated by: [EMAIL PROTECTED]
Reported By: michael dot walter at gmail dot com
-Status: Open
+Status: Assigned
-Bug Type: Compile Failure
+Bug Type: Scripting Engine problem
Operating System: Windows XP
PHP Version: 5.2.0
-Assigned To:
+Assigned To: dmitry
Previous Comments:
[2006-12-30 08:11:45] michael dot walter at gmail dot com
Description:
This is using PHP 5.2.1 RC 1 (the one Edin posted to PHP-DEV recently).
Reproduce code:
---
?php
class Klass
{
public function __get($name_)
{
return array('Hello', 'World');
}
};
$obj=new Klass();
foreach($obj-arr as $value)
echo $value;
?
Expected result:
HelloWorld
Actual result:
--
PHP Notice: Indirect modification of overloaded property Klass::$arr
has no effect in test.php on line 11
Notice: Indirect modification of overloaded property Klass::$arr has no
effect in test.php on line 11
HelloWorld
--
Edit this bug report at http://bugs.php.net/?id=39990edit=1
#39502 [Asn-Fbk]: PDO_MySQL segfaults
ID: 39502
Updated by: [EMAIL PROTECTED]
Reported By: indeyets at gmail dot com
-Status: Assigned
+Status: Feedback
Bug Type: PDO related
Operating System: FreeBSD
PHP Version: 5.2.0
Assigned To: wez
New Comment:
Can you see if using the latest CVS makes any difference?
Previous Comments:
[2006-11-16 10:00:02] indeyets at gmail dot com
still segfaults.
backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x28fbba2a in mysql_more_results () from
/usr/local/lib/mysql/libmysqlclient.so.15
(gdb) bt
#0 0x28fbba2a in mysql_more_results () from
/usr/local/lib/mysql/libmysqlclient.so.15
#1 0x2916bcbc in pdo_mysql_stmt_dtor (stmt=0x852bda0) at
/usr/ports/lang/php5/work/php-5.2.0/ext/pdo_mysql/mysql_statement.c:80
#2 0x2915fb9a in free_statement () from
/usr/local/lib/php/20060613-debug/pdo.so
#3 0x2915fc0f in pdo_dbstmt_free_storage () from
/usr/local/lib/php/20060613-debug/pdo.so
#4 0x288fc438 in ?? () from /usr/local/libexec/apache22/libphp5.so
#5 0x288fc2f3 in ?? () from /usr/local/libexec/apache22/libphp5.so
#6 0x288dc9ac in ?? () from /usr/local/libexec/apache22/libphp5.so
#7 0x288d0873 in ?? () from /usr/local/libexec/apache22/libphp5.so
#8 0x288d0a2c in ?? () from /usr/local/libexec/apache22/libphp5.so
#9 0x288dcc7b in ?? () from /usr/local/libexec/apache22/libphp5.so
#10 0x288e87d1 in ?? () from /usr/local/libexec/apache22/libphp5.so
#11 0x288f8b87 in ?? () from /usr/local/libexec/apache22/libphp5.so
#12 0x288f8ebd in ?? () from /usr/local/libexec/apache22/libphp5.so
#13 0x288fc129 in ?? () from /usr/local/libexec/apache22/libphp5.so
#14 0x288d0735 in ?? () from /usr/local/libexec/apache22/libphp5.so
#15 0x288de202 in ?? () from /usr/local/libexec/apache22/libphp5.so
#16 0x28895434 in ?? () from /usr/local/libexec/apache22/libphp5.so
#17 0x28943a78 in ?? () from /usr/local/libexec/apache22/libphp5.so
#18 0x2894407e in ?? () from /usr/local/libexec/apache22/libphp5.so
#19 0x08071f42 in ap_run_handler ()
#20 0x0807230d in ap_invoke_handler ()
#21 0x0807c92d in ap_internal_redirect ()
#22 0x2872bd34 in handler_redirect () from
/usr/local/libexec/apache22/mod_rewrite.so
#23 0x08071f42 in ap_run_handler ()
#24 0x0807230d in ap_invoke_handler ()
#25 0x0807cce9 in ap_process_request ()
#26 0x0807a8f1 in ap_process_http_connection ()
#27 0x080777e2 in ap_run_process_connection ()
#28 0x08080367 in child_main ()
#29 0x08080530 in make_child ()
#30 0x08080a73 in ap_mpm_run ()
#31 0x08061f40 in main ()
(gdb) list
80 mysql_free_result(res);
81 }
82 }
83 }
84 #endif
85 efree(S);
86 return 1;
87 }
88
89 static int pdo_mysql_stmt_execute(pdo_stmt_t *stmt TSRMLS_DC)
(gdb) print res
No symbol res in current context.
(gdb) frame 1
#1 0x2916bcbc in pdo_mysql_stmt_dtor (stmt=0x852bda0) at
/usr/ports/lang/php5/work/php-5.2.0/ext/pdo_mysql/mysql_statement.c:80
80 mysql_free_result(res);
(gdb) list
75 break;
76 }
77
78 res = mysql_store_result(S-H-server);
79 if (res) {
80 mysql_free_result(res);
81 }
82 }
83 }
84 #endif
(gdb) print res
No symbol res in current context.
(gdb) print S
$1 = (pdo_mysql_stmt *) 0x84ed090
(gdb) print S-H
No symbol H in current context.
(gdb) print S-H
$2 = (pdo_mysql_db_handle *) 0x84a3080
(gdb) print S-H-server
$3 = (MYSQL *) 0x5a5a5a5a
[2006-11-14 16:13:46] [EMAIL PROTECTED]
Try this patch:
http://bb.prohost.org/patch/pdo_my.txt
[2006-11-13 17:53:27] indeyets at gmail dot com
MySQL 5.0.21
reproduce code is difficult, as it happens inside of a very big CMS
the problem is temporarily solved for us, by commenting out this block:
http://cvs.php.net/viewcvs.cgi/php-src/ext/pdo_mysql/mysql_statement.c?r1=1.48.2.12r2=1.48.2.13
[2006-11-13 17:49:24] [EMAIL PROTECTED]
What version of MySQL are you using and can you provide the
reproduce code.
[2006-11-13 17:00:34] indeyets at gmail dot com
Description:
PDO_MySQL still segfaults in 5.2.0
related bugs:
http://bugs.php.net/bug.php?id=37445
http://bugs.php.net/bug.php?id=37438
backtrace of 5.2.0 is in Actual Result field
Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
0x28fbba2a in mysql_more_results () from
/usr/local/lib/mysql/libmysqlclient.so.15
(gdb) bt
#0 0x28fbba2a in mysql_more_results () from
/usr/local/lib/mysql/libmysqlclient.so.15
#1 0x2916bcb8 in pdo_mysql_stmt_dtor (stmt=0x85211cc) at
/usr/ports/lang/php5/work/php-5.2.0/ext/pdo_mysql/mysql_statement.c:79
#2 0x2915fb9a in free_statement () from
/usr/local/lib/php/20060613-debug/pdo.so
#3 0x2915fc0f in pdo_dbstmt_free_storage () from
/usr/local/lib/php/20060613-debug/pdo.so
#4
#39993 [NEW]: tr_TR.UTF-8 locale has problems with PHP
From: tunix at raptiye dot org Operating system: Arch Linux PHP version: 5.2.0 PHP Bug Type: *Unicode Issues Bug description: tr_TR.UTF-8 locale has problems with PHP Description: I type ?php echo date(l); ? into an empty php file and then run it in command line prompt, and it prints this error message: Fatal error: date(): Timezone database is corrupt - this should *never* happen! in Command line code on line 1 If I use tr_TR.UTF-8 locale, then I can produce this error. But if I use tr_TR.ISO8859-9 or C locales, it doesn't print the error message. Although, tr_TR.ISO8859-9 and C locales return Saturday which is English. It should return Cumartesi (turkish). GNU date command works fine with UTF-8 locale. [19:07] ([EMAIL PROTECTED] ~)$ TZ=Europe/Istanbul LANG=tr_TR.UTF-8 date +%A Cumartesi Reproduce code: --- [19:06] ([EMAIL PROTECTED] ~)$ TZ=Europe/Istanbul LANG=tr_TR.UTF-8 php -r date(l); Fatal error: date(): Timezone database is corrupt - this should *never* happen! in Command line code on line 1 Expected result: It's supposed to be: [19:06] ([EMAIL PROTECTED] ~)$ TZ=Europe/Istanbul LANG=tr_TR.UTF-8 php -r date(l); Cumartesi -- Edit bug report at http://bugs.php.net/?id=39993edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39993r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39993r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39993r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39993r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39993r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39993r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39993r=needscript Try newer version:http://bugs.php.net/fix.php?id=39993r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39993r=support Expected behavior:http://bugs.php.net/fix.php?id=39993r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39993r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39993r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39993r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39993r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39993r=dst IIS Stability:http://bugs.php.net/fix.php?id=39993r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39993r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39993r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39993r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39993r=mysqlcfg
#39989 [Com]: header location doesn't send explanation
ID: 39989 Comment by: l dot bigonville at edpnet dot be Reported By: Laurent Bigonville l dot bigonville at edpnet dot Status: Feedback Bug Type: HTTP related Operating System: Debian Sarge PHP Version: 5.2.0 New Comment: I use php in cgi mode. The problem seems to come from apache 2.0(.54) not from php. I'v made an other test using a simple shell script #! /bin/sh echo Status: 302 echo With apache 2.2 it returns HTTP/1.1 302 Found but with apache 2.0 it returns HTTP/1.1 302 If I change the script to #! /bin/sh echo Status: 302 echo It returns HTTP/1.1 302 Found i both cases Previous Comments: [2006-12-30 02:03:28] [EMAIL PROTECTED] What SAPI are you using? [2006-12-30 01:06:35] l dot bigonville at edpnet dot be I think it's because php_cgi return Status: 302 with no explanation [2006-12-30 00:33:09] l dot bigonville at edpnet dot be This is odd the problem occurs with the dotdeb packages on sarge but not with debian's official packages on etch.. [2006-12-30 00:24:39] Laurent Bigonville l dot bigonville at edpnet dot Description: the header location doesn't conform to RFC. The response header must finish with at least a space character. Reproduce code: --- header(Location: http://url/); Expected result: According to RFC2616 §6.1 the response message must consist in HTTP-Version SP Status-Code SP Reason-Phrase CRLF. (ie HTTP/1.1 302 Found). Actual result: -- Currently, php send HTTP/1.1 302 with even no space at the end of the response -- Edit this bug report at http://bugs.php.net/?id=39989edit=1
#39989 [Com]: header location doesn't send explanation
ID: 39989 Comment by: l dot bigonville at edpnet dot be Reported By: Laurent Bigonville l dot bigonville at edpnet dot Status: Feedback Bug Type: HTTP related Operating System: Debian Sarge PHP Version: 5.2.0 New Comment: Oups the last part of the message must read: If I change the script to #! /bin/sh echo Status: 302 Found echo It returns HTTP/1.1 302 Found i both cases Previous Comments: [2006-12-30 20:30:32] l dot bigonville at edpnet dot be I use php in cgi mode. The problem seems to come from apache 2.0(.54) not from php. I'v made an other test using a simple shell script #! /bin/sh echo Status: 302 echo With apache 2.2 it returns HTTP/1.1 302 Found but with apache 2.0 it returns HTTP/1.1 302 If I change the script to #! /bin/sh echo Status: 302 echo It returns HTTP/1.1 302 Found i both cases [2006-12-30 02:03:28] [EMAIL PROTECTED] What SAPI are you using? [2006-12-30 01:06:35] l dot bigonville at edpnet dot be I think it's because php_cgi return Status: 302 with no explanation [2006-12-30 00:33:09] l dot bigonville at edpnet dot be This is odd the problem occurs with the dotdeb packages on sarge but not with debian's official packages on etch.. [2006-12-30 00:24:39] Laurent Bigonville l dot bigonville at edpnet dot Description: the header location doesn't conform to RFC. The response header must finish with at least a space character. Reproduce code: --- header(Location: http://url/); Expected result: According to RFC2616 §6.1 the response message must consist in HTTP-Version SP Status-Code SP Reason-Phrase CRLF. (ie HTTP/1.1 302 Found). Actual result: -- Currently, php send HTTP/1.1 302 with even no space at the end of the response -- Edit this bug report at http://bugs.php.net/?id=39989edit=1
#39993 [Opn-Fbk]: tr_TR.UTF-8 locale has problems with PHP
ID: 39993 Updated by: [EMAIL PROTECTED] Reported By: tunix at raptiye dot org -Status: Open +Status: Feedback Bug Type: *Unicode Issues Operating System: Arch Linux PHP Version: 5.2.0 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip Previous Comments: [2006-12-30 18:22:08] tunix at raptiye dot org Description: I type ?php echo date(l); ? into an empty php file and then run it in command line prompt, and it prints this error message: Fatal error: date(): Timezone database is corrupt - this should *never* happen! in Command line code on line 1 If I use tr_TR.UTF-8 locale, then I can produce this error. But if I use tr_TR.ISO8859-9 or C locales, it doesn't print the error message. Although, tr_TR.ISO8859-9 and C locales return Saturday which is English. It should return Cumartesi (turkish). GNU date command works fine with UTF-8 locale. [19:07] ([EMAIL PROTECTED] ~)$ TZ=Europe/Istanbul LANG=tr_TR.UTF-8 date +%A Cumartesi Reproduce code: --- [19:06] ([EMAIL PROTECTED] ~)$ TZ=Europe/Istanbul LANG=tr_TR.UTF-8 php -r date(l); Fatal error: date(): Timezone database is corrupt - this should *never* happen! in Command line code on line 1 Expected result: It's supposed to be: [19:06] ([EMAIL PROTECTED] ~)$ TZ=Europe/Istanbul LANG=tr_TR.UTF-8 php -r date(l); Cumartesi -- Edit this bug report at http://bugs.php.net/?id=39993edit=1
#39969 [Com]: ini setting short_open_tag has no effect when using --enable-maintainer-zts
ID: 39969 Comment by: yahikootje+bugs at gmail dot com Reported By: yahikootje at gmail dot com Status: Open Bug Type: PHP options/info functions Operating System: Linux 2.6.17-gentoo-r8 PHP Version: 6CVS-2006-12-27 (CVS) New Comment: While digging a bit deeper I found that zend_post_startup() is only called when ZTS is enabled. This function calls compilers_global_ctor() which in turn calls zend_set_default_compile_time_values(). In that function the values for CG(short_tags) and CG(asp_tags) are reset to the default values, cancelling the effect off setting the ini values. Removing the call to zend_set_default_compile_time_values() in compilers_global_ctor() seems to solve the problem, but I can not say for sure it won't cause any other problems. Previous Comments: [2006-12-27 23:36:56] yahikootje at gmail dot com Description: When compiling PHP with --enable-maintainer-zts, setting the short_open_tag and asp_tag ini settings in php.ini have no effect. Compiling without --enable-maintainer-zts doesn't this problem. The values that are used for these ini settings (when compiled with --enable-maintainer-zts) are the default values that are set in zend_set_default_compile_time_values() I noticed this issue in PHP-5.2.1RC1, but it is also present in current HEAD (and probably also in older PHP versions). If more information is needed, just ask. Reproduce code: --- ?php echo long open php tags . PHP_EOL ? ? echo short open php tags . PHP_EOL ? % echo asp open php tag . PHP_EOL % with php.ini containing: short_open_tag = Off asp_tags = On Expected result: long open php tags ? echo short open php tags . PHP_EOL ? asp open php tag Actual result: -- long open php tags short open php tags % echo asp open php tag . PHP_EOL % -- Edit this bug report at http://bugs.php.net/?id=39969edit=1
#39984 [Fbk-Opn]: Response header sent as 302 despite being set to 301
ID: 39984 User updated by: marc dot bau at gmx dot net Reported By: marc dot bau at gmx dot net -Status: Feedback +Status: Open Bug Type: IIS related Operating System: WinXP PHP Version: 5.2.0 New Comment: hi. i've tested this and nothing is changed. I set a 301 and get a 302. HTTP/1.x 302 Object Moved Server: Microsoft-IIS/5.1 Date: Sat, 30 Dec 2006 21:22:05 GMT Connection: close Content-Type: text/html X-Powered-By: PHP/5.2.1RC2-dev Location: http://www.example.com Previous Comments: [2006-12-30 13:22:47] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip Using the latests snaps I get: HTTP/1.1 301 Undescribed from both IIS 5.1 and IIS 7. [2006-12-29 19:16:56] marc dot bau at gmx dot net same results with ISAPI Plugin php5isapi.dll: GET /test.php HTTP/1.1 Host: localhost User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Language: de,en;q=0.8,en-us;q=0.6,de-de;q=0.4,es;q=0.2 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Cookie: PHPSESSID=m9qi6v871710hj32f7b5cq6317; ASPSESSIONIDQQBCCSTD=MIFPNOKCDKGFBIKNGDIINLMM; CFID=3396; CFTOKEN=156ca9b801cf2d95%2DCF7CD840%2DBCDB%2D4EA9%2D271106C3DB1FE210; JSESSIONID=e0307f68472e511136a6 HTTP/1.x 302 Object Moved Server: Microsoft-IIS/5.1 Date: Fri, 29 Dec 2006 19:15:30 GMT Connection: close Content-Type: text/html X-Powered-By: PHP/5.2.0 Location: http://example.com [2006-12-29 18:36:01] marc dot bau at gmx dot net Installing Apache on Windows makes no sense to me. I know it is working with Apache 2.0 and CGI on a Linux (SuSE 9.3) box. ASP Code Example - works: %@ Language=VBScript % % Response.Status=301 Moved Permanently Response.AddHeader Location, http://www.example.com/; % ASP Headers results: GET /test.asp HTTP/1.1 Host: localhost User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Language: de,en;q=0.8,en-us;q=0.6,de-de;q=0.4,es;q=0.2 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Cookie: PHPSESSID=m9qi6v871710hj32f7b5cq6317; ASPSESSIONIDQQBCCSTD=MIFPNOKCDKGFBIKNGDIINLMM HTTP/1.x 301 Moved Permanently Server: Microsoft-IIS/5.1 Date: Fri, 29 Dec 2006 18:27:01 GMT X-Powered-By: ASP.NET Location: http://www.example.com/ Content-Length: 0 Content-Type: text/html Cache-Control: private ColdFusion MX 7.02 Example - Code: CFHEADER statusCode=301 statusText=Moved Permanently CFHEADER name=Location value=http://www.example.com/; CFMX Header Results: GET /test.cfm HTTP/1.1 Host: localhost User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Language: de,en;q=0.8,en-us;q=0.6,de-de;q=0.4,es;q=0.2 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Cookie: PHPSESSID=m9qi6v871710hj32f7b5cq6317; ASPSESSIONIDQQBCCSTD=MIFPNOKCDKGFBIKNGDIINLMM HTTP/1.x 301 Moved Permanently Server: Microsoft-IIS/5.1 Date: Fri, 29 Dec 2006 18:33:27 GMT X-Powered-By: ASP.NET Connection: close Set-Cookie: CFID=3396;expires=Fri, 12-Jan-2007 18:33:27 GMT;path=/ Set-Cookie: CFTOKEN=156ca9b801cf2d95%2DCF7CD840%2DBCDB%2D4EA9%2D271106C3DB1FE210;expires=Fri, 12-Jan-2007 18:33:27 GMT;path=/ Set-Cookie: JSESSIONID=e0307f68472e511136a6;path=/ Location: http://www.example.com/ Content-Language: de-DE Content-Type: text/html; charset=UTF-8 All on the same machine this PHP 5.2 is installed, too. Now - i think - IIS is not the cause of this bug. [2006-12-29 18:12:20] [EMAIL PROTECTED] I mean that IIS might change this code for some reason. One of the possible ways to check it out would be to install Apache with PHP CGI and verify that it works ok. Since they share the same code, it would mean that the problem is somewhere else. [2006-12-29 18:05:52] marc dot bau at gmx dot net What are you talking about regarding Please make sure IIS does not translate 301 to 302. ? The remainder of the
#39991 [Opn-Fbk]: session_write_close
ID: 39991 Updated by: [EMAIL PROTECTED] Reported By: mauricebis at gmail dot com -Status: Open +Status: Feedback Bug Type: Filesystem function related Operating System: linux PHP Version: 4.4.4 New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to Open. Thank you for your interest in PHP. Previous Comments: [2006-12-30 11:10:35] mauricebis at gmail dot com Description: I experienced a race situation with session_write_close where the lock (acquired in session_start) was released before the updated $_SESSION variables were visible to other processes. Another process blocked on session_start was allowed to proceed but could not read the session variables supposedly written through session_write_close. -- Edit this bug report at http://bugs.php.net/?id=39991edit=1
#39975 [Opn-Asn]: Some error in C/C++ syntax
ID: 39975 Updated by: [EMAIL PROTECTED] Reported By: kprzemek at coig dot katowice dot pl -Status: Open +Status: Assigned Bug Type: Compile Failure Operating System: IBM AIX 5.3 PHP Version: 5.2.0 -Assigned To: +Assigned To: tony2001 Previous Comments: [2006-12-29 19:24:43] orchard at engr dot wisc dot edu I had to fix the following error to get the Sun C compiler to compile the program (I changed the comment to standard C syntax): [eceserv1] 203% diff spl_iterators.c.orig spl_iterators.c 1484c1484 return;// NULL --- return;/* // NULL */ [2006-12-29 09:03:21] kprzemek at coig dot katowice dot pl Here is the step-by-step description of all errors consecutively as they appear.My compiler is: VisualAge C++ Professional / C for AIX Compiler, Version 5 Now the errors: # api.h new/php_stream_filter_api.h 65c65 PSFS_PASS_ON, /* filter generated output buckets; pass them on to next in chain */ --- PSFS_PASS_ON/* filter generated output buckets; pass them on to next in chain */ ++ /dv/usr/local/DEV/php-5.2.0/main/streams/php_stream_filter_api.h, line 65.21: 1506-275 (S) Unexpected text ',' encountered. = # diff openssl.c new/openssl.c 61c61 ZEND_END_ARG_INFO(); --- ZEND_END_ARG_INFO() 72c72 OPENSSL_KEYTYPE_DEFAULT = OPENSSL_KEYTYPE_RSA, --- OPENSSL_KEYTYPE_DEFAULT = OPENSSL_KEYTYPE_RSA ++ /dv/usr/local/DEV/php-5.2.0/ext/openssl/openssl.c, line 61.28: 1506-137 (E) Declaration must declare at least one declarator, tag, or the members of an enumeration. /dv/usr/local/DEV/php-5.2.0/ext/openssl/openssl.c, line 72.54: 1506-275 (S) Unexpected text ',' encountered. make: *** [ext/openssl/openssl.lo] Error 1 == # diff php_pcre.c new/php_pcre.c 55c55 PHP_PCRE_BAD_UTF8_ERROR, --- PHP_PCRE_BAD_UTF8_ERROR 59.34 ZEND_DECLARE_MODULE_GLOBALS(pcre); --- ZEND_DECLARE_MODULE_GLOBALS(pcre) + /dv/usr/local/DEV/php-5.2.0/ext/pcre/php_pcre.c, line 55.32: 1506-275 (S) Unexpected text ',' encountered. /dv/usr/local/DEV/php-5.2.0/ext/pcre/php_pcre.c, line 59.34: 1506-137 (E) Declaration must declare at least one declarator, tag, or the members of an enumeration. make: *** [ext/pcre/php_pcre.lo] Error 1 = # diff parse_date.c new/parse_date.c 88c88,91 typedef unsigned char uchar; --- /* Typ z sys/types.h !! * * typedef unsigned char uchar; */ + php-5.2.0/ext/date/lib/parse_date.c, line 88.23: 1506-334 (S) Identifier uchar has already been defined on line 519 of /usr/include/sys/types.h. php-5.2.0/ext/date/lib/parse_date.c, line 337.94: 1506-068 (S) Operation between types illegal type* and illegal type* is not allowed. php-5.2.0/ext/date/lib/parse_date.c, line 346.90: 1506-068 (S) Operation between types illegal type* and illegal type* is not allowed. php-5.2.0/ext/date/lib/parse_date.c, line 376.38: 1506-068 (S) Operation between types illegal type* and illegal type* is not allowed. php-5.2.0/ext/date/lib/parse_date.c, line 377.36: 1506-068 (S) Operation between types illegal type* and illegal type* is not allowed. php-5.2.0/ext/date/lib/parse_date.c, line 811.11: 1506-281 (S) Prefix and postfix increment and decrement operators cannot be applied to illegal type*. and MORE lines like that: php-5.2.0/ext/date/lib/parse_date.c, line 1015.19: 1506-281 (S) Prefix and postfix increment and decrement operators cannot be applied to illegal type*. = # diff php_hash_tiger.h new/php_hash_tiger.h 28,29c28,29 unsigned char passes:1; unsigned char length:7; --- unsigned int passes:1; unsigned int length:7; + /dv/usr/local/DEV/php-5.2.0/ext/hash/php_hash_tiger.h, line 28.9: 1506-009 (S) Bit-field passes must be of type signed int, unsigned int or int. /dv/usr/local/DEV/php-5.2.0/ext/hash/php_hash_tiger.h, line 29.9: 1506-009 (S) Bit-field length must be of type signed int, unsigned int or int. make: *** [ext/hash/hash_tiger.lo] Error 1 === # diff spl_directory.h new/spl_directory.h 38c38 SPL_FS_FILE, --- SPL_FS_FILE + /dv/usr/local/DEV/php-5.2.0/ext/spl/spl_directory.h, line 38.20: 1506-275 (S) Unexpected text ',' encountered. == # diff spl_iterators.h new/spl_iterators.h 95c95 REGIT_USE_KEY= 0x0001, --- REGIT_USE_KEY= 0x0001 104c104 REGIT_MODE_MAX, --- REGIT_MODE_MAX + /dv/usr/local/DEV/php-5.2.0/ext/spl/spl_iterators.h, line 95.46: 1506-275 (S) Unexpected text ',' encountered. /dv/usr/local/DEV/php-5.2.0/ext/spl/spl_iterators.h, line 104.23: 1506-275 (S) Unexpected text ',' encountered. = # diff php_spl.c new/php_spl.c 646c646 ZEND_END_ARG_INFO(); ---
#39989 [Fbk]: header location doesn't send explanation
ID: 39989 Updated by: [EMAIL PROTECTED] Reported By: Laurent Bigonville l dot bigonville at edpnet dot Status: Feedback Bug Type: HTTP related Operating System: Debian Sarge PHP Version: 5.2.0 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip Previous Comments: [2006-12-30 20:31:57] l dot bigonville at edpnet dot be Oups the last part of the message must read: If I change the script to #! /bin/sh echo Status: 302 Found echo It returns HTTP/1.1 302 Found i both cases [2006-12-30 20:30:32] l dot bigonville at edpnet dot be I use php in cgi mode. The problem seems to come from apache 2.0(.54) not from php. I'v made an other test using a simple shell script #! /bin/sh echo Status: 302 echo With apache 2.2 it returns HTTP/1.1 302 Found but with apache 2.0 it returns HTTP/1.1 302 If I change the script to #! /bin/sh echo Status: 302 echo It returns HTTP/1.1 302 Found i both cases [2006-12-30 02:03:28] [EMAIL PROTECTED] What SAPI are you using? [2006-12-30 01:06:35] l dot bigonville at edpnet dot be I think it's because php_cgi return Status: 302 with no explanation [2006-12-30 00:33:09] l dot bigonville at edpnet dot be This is odd the problem occurs with the dotdeb packages on sarge but not with debian's official packages on etch.. 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/39989 -- Edit this bug report at http://bugs.php.net/?id=39989edit=1
#39993 [Fbk-Asn]: tr_TR.UTF-8 locale has problems with PHP
ID: 39993 Updated by: [EMAIL PROTECTED] Reported By: tunix at raptiye dot org -Status: Feedback +Status: Assigned Bug Type: *Unicode Issues Operating System: Arch Linux PHP Version: 5.2.0 -Assigned To: +Assigned To: derick New Comment: Its is reproducible with the snapshot. I believe this happens because of strcasecmp() (used in seek_to_tz_position()) behaving weird with tr_TR locale (I remember some similar problems in the past), using something like tolower() memcmp() should do the trick. Previous Comments: [2006-12-30 20:46:30] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip [2006-12-30 18:22:08] tunix at raptiye dot org Description: I type ?php echo date(l); ? into an empty php file and then run it in command line prompt, and it prints this error message: Fatal error: date(): Timezone database is corrupt - this should *never* happen! in Command line code on line 1 If I use tr_TR.UTF-8 locale, then I can produce this error. But if I use tr_TR.ISO8859-9 or C locales, it doesn't print the error message. Although, tr_TR.ISO8859-9 and C locales return Saturday which is English. It should return Cumartesi (turkish). GNU date command works fine with UTF-8 locale. [19:07] ([EMAIL PROTECTED] ~)$ TZ=Europe/Istanbul LANG=tr_TR.UTF-8 date +%A Cumartesi Reproduce code: --- [19:06] ([EMAIL PROTECTED] ~)$ TZ=Europe/Istanbul LANG=tr_TR.UTF-8 php -r date(l); Fatal error: date(): Timezone database is corrupt - this should *never* happen! in Command line code on line 1 Expected result: It's supposed to be: [19:06] ([EMAIL PROTECTED] ~)$ TZ=Europe/Istanbul LANG=tr_TR.UTF-8 php -r date(l); Cumartesi -- Edit this bug report at http://bugs.php.net/?id=39993edit=1
#39987 [Opn-Bgs]: loss of resources
ID: 39987
Updated by: [EMAIL PROTECTED]
Reported By: wojtekm86 at konto dot pl
-Status: Open
+Status: Bogus
Bug Type: Semaphore related
Operating System: Linux
PHP Version: 5.2.0
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
if you want to remove the semaphore you need to call the
sem_remove() function. Closing the semaphore won't remove it
no more so then closing a file will remove it from disk.
Previous Comments:
[2006-12-30 10:54:20] wojtekm86 at konto dot pl
I think that there is also a problem with parameter max_acquire because
value in column nsems always equals 3
[2006-12-29 17:45:15] wojtekm86 at konto dot pl
Next code.
I have a test script with code as follows:
?php
$id = sem_get(10);
sem_acquire($id);
for($ind = 0; $ind 1; $ind++) { }
sem_release($id);
?
I run it only once.
The result I get after execute command ipcs -s on the server:
-- Semaphore Arrays
keysemid owner perms nsems
0x000a 131075 www_php-a 6663
It seems that there is a problem with semaphores' removal after
release.
[2006-12-29 17:33:32] wojtekm86 at konto dot pl
I think it doesn't.
In my script I have class Semaphore.
There are methods like acquire() and release().
After each sem_acquire instruction I wrote:
echo('I\'ve acquired semaphore key: ' . $this-key . 'br');
After each sem_release instruction I wrote:
echo('I\'ve released semaphore key: ' . $this-key . 'br');
I have executed script only once.
The result I saw is:
I've acquired semaphore key: 1376159737
I've released semaphore key: 1376159737
I've acquired semaphore key: 1376159747
I've released semaphore key: 1376159747
I've acquired semaphore key: 1376159737
I've released semaphore key: 1376159737
I've acquired semaphore key: 1376159748
I've released semaphore key: 1376159748
I've acquired semaphore key: 1376159737
I've released semaphore key: 1376159737
I've acquired semaphore key: 1376159749
I've released semaphore key: 1376159749
As you can see each semaphore is released.
But when I run command ipcs -s on my server I get:
-- Semaphore Arrays
keysemid owner perms nsems
0x520687e6 131075 www_php-a 6003
0x520687f9 163844 www_php-a 6003
0x520687fa 196613 www_php-a 6003
0x520687fc 229382 www_php-a 6003
0x520687e9 262151 www_php-a 6003
0x520687fd 294920 www_php-a 6003
0x520687fe 327689 www_php-a 6003
0x520687ff 360458 www_php-a 6003
0x52068800 393227 www_php-a 6003
0x52068801 425996 www_php-a 6003
0x52068802 458765 www_php-a 6003
0x52068803 491534 www_php-a 6003
0x52068804 524303 www_php-a 6003
0x52068805 557072 www_php-a 6003
You can see that there are not removed semaphores.
[2006-12-29 17:14:48] [EMAIL PROTECTED]
Cannot reproduce.
sem_release() DOES remove the semaphor if no other process uses it.
[2006-12-29 17:01:23] wojtekm86 at konto dot pl
Description:
It's impossible to correct remove semaphores with sem_remove function
when I use them to provide execution of concurrent processes.
When the last process releases the semaphore I should be able to remove
it. But I don't know if another process haven't acquired the semaphore.
For safety reasons I don't remove released semaphores from system.
Now, If I get 128 semaphores and I execute sem_get one more time I will
get warning.
So, I can't remove semaphores (because I don't know if another process
is using it) and I can't get next semaphore.
Reproduce code:
---
$id = sem_get(SOME_ID);
sem_acquire($id);
HERE IS CRITICAL REGION
sem_release($id);
Expected result:
Expected result (and correct, I think) is removal of unused semaphore
in sem_release function if another process didn't acquire it and isn't
waiting for doing this.
Release and Removal of semaphore should be one chain of instructions
without possibility of separation (e.g. by interruption).
Actual result:
--
System reaches the maximum number of semaphores and warning is
reported.
The warning is: Warning: sem_get() [function.sem-get]: failed for key
#39993 [Asn]: tr_TR.UTF-8 locale has problems with PHP
ID: 39993 Updated by: [EMAIL PROTECTED] Reported By: tunix at raptiye dot org Status: Assigned Bug Type: Date/time related Operating System: Arch Linux PHP Version: 5.2.0 Assigned To: derick New Comment: Another option that is a bit more performance friendly is something like this: http://bb.prohost.org/patch/date.txt Previous Comments: [2006-12-30 23:08:23] [EMAIL PROTECTED] Its is reproducible with the snapshot. I believe this happens because of strcasecmp() (used in seek_to_tz_position()) behaving weird with tr_TR locale (I remember some similar problems in the past), using something like tolower() memcmp() should do the trick. [2006-12-30 20:46:30] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip [2006-12-30 18:22:08] tunix at raptiye dot org Description: I type ?php echo date(l); ? into an empty php file and then run it in command line prompt, and it prints this error message: Fatal error: date(): Timezone database is corrupt - this should *never* happen! in Command line code on line 1 If I use tr_TR.UTF-8 locale, then I can produce this error. But if I use tr_TR.ISO8859-9 or C locales, it doesn't print the error message. Although, tr_TR.ISO8859-9 and C locales return Saturday which is English. It should return Cumartesi (turkish). GNU date command works fine with UTF-8 locale. [19:07] ([EMAIL PROTECTED] ~)$ TZ=Europe/Istanbul LANG=tr_TR.UTF-8 date +%A Cumartesi Reproduce code: --- [19:06] ([EMAIL PROTECTED] ~)$ TZ=Europe/Istanbul LANG=tr_TR.UTF-8 php -r date(l); Fatal error: date(): Timezone database is corrupt - this should *never* happen! in Command line code on line 1 Expected result: It's supposed to be: [19:06] ([EMAIL PROTECTED] ~)$ TZ=Europe/Istanbul LANG=tr_TR.UTF-8 php -r date(l); Cumartesi -- Edit this bug report at http://bugs.php.net/?id=39993edit=1
#38542 [Opn-Asn]: proc_get_status : wrong PID
ID: 38542
Updated by: [EMAIL PROTECTED]
Reported By: php at bouchery dot com
-Status: Open
+Status: Assigned
Bug Type: Program Execution
-Operating System: Windows XP
+Operating System: Windows
PHP Version: 5.1.5
-Assigned To:
+Assigned To: nlopess
New Comment:
problem verified. it is returning hProcess instead of dwProcessId of
the PROCESS_INFORMATION structure. I'll patch it.
Previous Comments:
[2006-08-22 13:10:27] php at bouchery dot com
Same problem :
PID = 1844
Image Name PID Session Name Session#Mem
Usage
= ==
notepad.exe 4432 Console 0 3 220
K
INFO: No tasks running with the specified criteria.
[2006-08-22 13:05:33] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
[2006-08-22 09:25:52] php at bouchery dot com
Description:
proc_get_status return the wrong PID
Reproduce code:
---
?php
$cmd = 'notepad';
$descriptorspec = array( 0 = array('pipe', 'r' ), 1 = array('pipe',
'w' ), 2 = array('pipe', 'w' ) );
$process = proc_open($cmd, $descriptorspec, $pipes);
$status = proc_get_status( $process );
echo 'PID = ', $status['pid'], \n;
passthru( 'tasklist /fi imagename eq notepad.exe');
echo \n\n;
passthru( 'tasklist /fi pid eq ' . $status['pid'] . '' );
echo \n\n;
?
Expected result:
proc_get_status should return the notepad's PID
Actual result:
--
It returns a PID which doesn't exist or associate to a process which is
not related to the script context.
--
Edit this bug report at http://bugs.php.net/?id=38542edit=1
