#48509 [Opn->Asn]: formatOutput does not work with saveHTML

2009-06-09 Thread chregu 
 ID:   48509
 Updated by:   chr...@php.net
 Reported By:  k...@php.net
-Status:   Open
+Status:   Assigned
 Bug Type: DOM XML related
 Operating System: Mac OS X 10.5.7
 PHP Version:  5.3CVS-2009-06-09 (CVS)
-Assigned To:  
+Assigned To:  chregu
 New Comment:

RIght, that never was backported to the 5_3 branch. But we're currently

in a commit freeze, so I can't check it in, but will as soon as I am 
allowed to do it.

That's the patch by the way:

http://cvs.php.net/viewvc.cgi/php-src/ext/dom/document.c?
r1=1.78&r2=1.79&pathrev=MAIN&view=patch


Previous Comments:


[2009-06-09 16:51:53] k...@php.net

Description:

While writing test cases on Oslo TestFest 2009 I just found that the
$dom->formatOutput does not work with $dom->saveHTML() (even though it
seems to have been resolved here: http://bugs.php.net/bug.php?id=35673)

xmllint says:

$ xmllint --format --html output.html 
http://www.w3.org/TR/REC-html40/loose.dtd";>


This is the title


so according to Hannes here this seems to be a bug in PHP 5.3 (may be
that it's fixed i HEAD but not backported?).

Reproduce code:
---
formatOutput = true;
$root = $doc->createElement('html');
$root = $doc->appendChild($root);
$head = $doc->createElement('head');
$head = $root->appendChild($head);
$title = $doc->createElement('title');
$title = $head->appendChild($title);
$text = $doc->createTextNode('This is the title');
$text = $title->appendChild($text);
echo $doc->saveHTML();
?>

Expected result:


  
This is the title
  


Actual result:
--
This is the title





-- 
Edit this bug report at http://bugs.php.net/?id=48509&edit=1

#48515 [NEW]: PHP.ini not overriding master variables

2009-06-09 Thread jackmcleod at infocode007 dot com 
From: jackmcleod at infocode007 dot com
Operating system: Windows XP SP2
PHP version:  5.2.9
PHP Bug Type: Unknown/Other Function
Bug description:  PHP.ini not overriding master variables

Description:

In php 5.2.3 everything was working fine, then i noticed magic quotes gpc
being on again and i did some testing with the php.ini file to find out it
was being completely ignored.
Server API  Apache 2.0 Handler 

Changing the values in the master file changes the values.


Reproduce code:
---
memory_limit = 128M (then restart the server)



Expected result:

When calling phpinfo();:

memory_limit128M32M

Actual result:
--
When calling phpinfo();:

memory_limit32M 32M

-- 
Edit bug report at http://bugs.php.net/?id=48515&edit=1
-- 
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48515&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48515&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48515&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48515&r=fixedcvs
Fixed in CVS and need be documented: 
http://bugs.php.net/fix.php?id=48515&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48515&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=48515&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=48515&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=48515&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=48515&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=48515&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=48515&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=48515&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48515&r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=48515&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48515&r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=48515&r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=48515&r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=48515&r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=48515&r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=48515&r=mysqlcfg

#48514 [NEW]: cURL extension uses non-unique resource type names

2009-06-09 Thread wharmby at uk dot ibm dot com 
From: wharmby at uk dot ibm dot com
Operating system: Windows XP
PHP version:  5.2CVS-2009-06-09 (snap)
PHP Bug Type: cURL related
Bug description:  cURL extension uses non-unique resource type names

Description:

The cURL extension currently registers 2 resource types and instances of
these resources are returned by the curl_init() and curl_multi_init()
api's. 

However, it is not currently possible to programaticaly determine which
type of curl resource a variable represents as get_resource_type() returns
"curl" for both types of resource.

I expected to get a different names for each of the 2 resource types; e.g
"curl" and "curl_multi"




Reproduce code:
---


Expected result:

resource(4) of type (curl)
string(4) "curl"
resource(5) of type (curl_multi)
string(4) "curl_multi"



Actual result:
--
resource(4) of type (curl)
string(4) "curl"
resource(5) of type (curl)
string(4) "curl"

-- 
Edit bug report at http://bugs.php.net/?id=48514&edit=1
-- 
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48514&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48514&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48514&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48514&r=fixedcvs
Fixed in CVS and need be documented: 
http://bugs.php.net/fix.php?id=48514&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48514&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=48514&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=48514&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=48514&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=48514&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=48514&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=48514&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=48514&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48514&r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=48514&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48514&r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=48514&r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=48514&r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=48514&r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=48514&r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=48514&r=mysqlcfg

#48453 [Asn]: fetch_assoc() problem

2009-06-09 Thread gubbov53 at hotmail dot com 
 ID:   48453
 User updated by:  gubbov53 at hotmail dot com
 Reported By:  gubbov53 at hotmail dot com
 Status:   Assigned
 Bug Type: MySQLi related
 Operating System: Windows Vista
 PHP Version:  5.2.9
 Assigned To:  mysql
 New Comment:

A temp solution to have it working if you have code with fetch_assoc()
is to replace fetch_assoc() with fetch_fields() (to get keys),
fetch_row() (to get values), and array_combine(). See example below...



query($query);
  $num_results=$result->num_rows;
  echo "Number of books found: ".$num_results."";

  $finfo = $result->fetch_fields(); $nc=0; foreach ($finfo as $val)
{$row_key[$nc++]=$val->name;} //---
  for ($i=0; $i<$num_results; $i++) {
//$row=$result->fetch_assoc();
   
$row_val=$result->fetch_row();$row=array_combine($row_key,$row_val);
//---
echo "".($i+1)." Title: ";
echo htmlspecialchars(stripslashes($row['title']));
echo "Author: ";
echo stripslashes($row['author']);
  }
  $result->free();
  $db->close();
?>




Previous Comments:


[2009-06-06 08:06:54] jacobus0223 at hotmail dot com

I have this problem too and also have the same problem with
fetch_object().  The browser hangs and finally times out.  

I also note that there was a problem with these same two functions back
in 2002 -- http://bugs.php.net/bug.php?id=18622.



[2009-06-04 08:44:18] paj...@php.net

There is a script to test.



[2009-06-04 08:41:15] gubbov53 at hotmail dot com

Tried with the latest PHP Version 5.2.10RC2-dev but the problem
remains.



[2009-06-03 20:39:54] j...@php.net

Please read this: http://bugs.php.net/how-to-report.php



[2009-06-03 12:48:40] gubbov53 at hotmail dot com

To have this problem set up a small MySQL db by running the following
as root:

create database books_db;
use books_db;
create table books
(  isbn char(13) not null primary key,
   author char(50),
   title char(100),
   price float(4,2)
);
grant select, insert, update, delete
on books_db.*
to books_u...@localhost identified by 'password';
insert into books values
  ("0-672-31697-8", "Michael Morgan", "Java 2 for Professional
Developers", 34.99),
  ("0-672-31745-1", "Thomas Down", "Installing Debian GNU/Linux",
24.99);
---
Then run this file in IE:
--



query($query);
  $num_results=$result->num_rows;
  echo "Number of books found: ".$num_results."";
  for ($i=0; $i<$num_results; $i++) {
$row=$result->fetch_assoc(); // loops here...
echo "".($i+1)." Title: ";
echo htmlspecialchars(stripslashes($row['title']));
echo "Author: ";
echo stripslashes($row['author']);
  }
  $result->free();
  $db->close();
?>





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/48453

-- 
Edit this bug report at http://bugs.php.net/?id=48453&edit=1

#48019 [Com]: ReflectionMethod's invoke() and call_user_func() do not return by reference

2009-06-09 Thread pulni4kiya at abv dot bg 
 ID:   48019
 Comment by:   pulni4kiya at abv dot bg
 Reported By:  pulni4kiya at abv dot bg
 Status:   Open
 Bug Type: Feature/Change Request
 Operating System: *
 PHP Version:  5.2.9
 New Comment:

Sorry for writing again but it would have been good if you said
anything about this bug. And yes I still think it's a bug, not a
'feature/change request'.


Previous Comments:


[2009-04-19 22:50:10] pulni4kiya at abv dot bg

Description:

The problem is that ReflectionMethod's invoke() method does not return
reference (when it should)! Neither does call_user_func() for that
matter.

Reproduce code:
---
class A {
public static $c = 100;

public static function &D() {
return self::$c;
}
}

echo A::$c; //prints 100
$cRef1 =& A::D();
$cRef1 = 200;
echo A::$c; //prints 200
$a = new ReflectionClass('A');
$d = $a->getMethod('D');
$cRef2 =& $d->invoke(null); //DOES NOT RETURN REFERENCE!!!
$cRef2 = 300;
echo A::$c; //prints 200

Expected result:

100200300

Actual result:
--
100200200





-- 
Edit this bug report at http://bugs.php.net/?id=48019&edit=1

#48505 [Opn->Csd]: PHP-Informix ifx_fetch_row, text data type crash solution

2009-06-09 Thread kalle 
 ID:   48505
 Updated by:   ka...@php.net
 Reported By:  amitshahc at hotmail dot com
-Status:   Open
+Status:   Closed
 Bug Type: Informix related
 Operating System: RHEL5, any linux
 PHP Version:  5.2.9
 New Comment:

The informix database driver is not bundled with PHP, plus it doesn't
seems to be maintained anymore:
http://pecl.php.net/package/informix

Try re-report the bug there, even though I wouldn't expect a response,
sorry


Previous Comments:


[2009-06-09 13:51:07] amitshahc at hotmail dot com

sorry, this bug means not solutions but let us consider it as a trick
or tip or the way to overcome the bug.

Thanks



[2009-06-09 13:47:51] amitshahc at hotmail dot com

Description:

Solution: related to PHP Bugs: #32954 & #8715.


I think it's memory issue with apache handling the informix result id.
with text datatype. i don't know exactly as i am not ESQL/C developer.
but i used a combination of settings before executing the select query
which have the text field in the result.

Set 
ifx_blobinfile_mode(1);
ifx_textasvarchar(0);

will return the blob id, in text field value instead of the giving text
contect directly into that field. 

then do 
ifx_get_blob($row['text_field_name']). 
will return the file name. and then read that file content, store it in
the variable. and delete the file. 

doing 
ifx_free_blob($row['text_field_name']); 
again crashes the php script sometimes. so don't do it. 

but you can do ifx_free_result($resultId); at the end of the script.

All The Best...
Amit Shah






-- 
Edit this bug report at http://bugs.php.net/?id=48505&edit=1

#48511 [NEW]: libxml_get_errors() returns an empty array but libxml_get_last_error() doesn't

2009-06-09 Thread geoffers+phpbugs at gmail dot com 
From: geoffers+phpbugs at gmail dot com
Operating system: Mac OS 10.5.7
PHP version:  5.3CVS-2009-06-09 (CVS)
PHP Bug Type: XML Writer
Bug description:  libxml_get_errors() returns an empty array but 
libxml_get_last_error() doesn't

Description:

I would expect the last member of the array returned by
libxml_get_errors() to be equal to libxml_get_last_error(), but the former
returns an empty array while the latter returns the expected error object.

Reproduce code:
---
openMemory();
$foo->startElement("\xEF\xBF\xBF");
var_dump(libxml_get_last_error());
var_dump(libxml_get_errors());
var_dump(libxml_get_last_error() == end(libxml_get_errors()));

Expected result:

Warning: XMLWriter::startElement(): Char 0x out of allowed range in
/Users/gsnedders/Desktop/test.php on line 5

Warning: XMLWriter::startElement(): Invalid Element Name in
/Users/gsnedders/Desktop/test.php on line 5
object(LibXMLError)#2 (6) {
  ["level"]=>
  int(3)
  ["code"]=>
  int(9)
  ["column"]=>
  int(0)
  ["message"]=>
  string(33) "Char 0x out of allowed range
"
  ["file"]=>
  string(0) ""
  ["line"]=>
  int(0)
}
array(1) {
  [0]=>
  object(LibXMLError)#2 (6) {
["level"]=>
int(3)
["code"]=>
int(9)
["column"]=>
int(0)
["message"]=>
string(33) "Char 0x out of allowed range
"
["file"]=>
string(0) ""
["line"]=>
int(0)
  }
}
bool(true)

Actual result:
--
Warning: XMLWriter::startElement(): Char 0x out of allowed range in
/Users/gsnedders/Desktop/test.php on line 5

Warning: XMLWriter::startElement(): Invalid Element Name in
/Users/gsnedders/Desktop/test.php on line 5
object(LibXMLError)#2 (6) {
  ["level"]=>
  int(3)
  ["code"]=>
  int(9)
  ["column"]=>
  int(0)
  ["message"]=>
  string(33) "Char 0x out of allowed range
"
  ["file"]=>
  string(0) ""
  ["line"]=>
  int(0)
}
array(0) {
}
bool(false)

-- 
Edit bug report at http://bugs.php.net/?id=48511&edit=1
-- 
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48511&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48511&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48511&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48511&r=fixedcvs
Fixed in CVS and need be documented: 
http://bugs.php.net/fix.php?id=48511&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48511&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=48511&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=48511&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=48511&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=48511&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=48511&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=48511&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=48511&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48511&r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=48511&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48511&r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=48511&r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=48511&r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=48511&r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=48511&r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=48511&r=mysqlcfg

#48509 [NEW]: formatOutput does not work with saveHTML

2009-06-09 Thread k...@php.net 
From: k...@php.net
Operating system: Mac OS X 10.5.7
PHP version:  5.3CVS-2009-06-09 (CVS)
PHP Bug Type: DOM XML related
Bug description:  formatOutput does not work with saveHTML

Description:

While writing test cases on Oslo TestFest 2009 I just found that the
$dom->formatOutput does not work with $dom->saveHTML() (even though it
seems to have been resolved here: http://bugs.php.net/bug.php?id=35673)

xmllint says:

$ xmllint --format --html output.html 
http://www.w3.org/TR/REC-html40/loose.dtd";>


This is the title


so according to Hannes here this seems to be a bug in PHP 5.3 (may be that
it's fixed i HEAD but not backported?).

Reproduce code:
---
formatOutput = true;
$root = $doc->createElement('html');
$root = $doc->appendChild($root);
$head = $doc->createElement('head');
$head = $root->appendChild($head);
$title = $doc->createElement('title');
$title = $head->appendChild($title);
$text = $doc->createTextNode('This is the title');
$text = $title->appendChild($text);
echo $doc->saveHTML();
?>

Expected result:


  
This is the title
  


Actual result:
--
This is the title

-- 
Edit bug report at http://bugs.php.net/?id=48509&edit=1
-- 
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48509&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48509&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48509&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48509&r=fixedcvs
Fixed in CVS and need be documented: 
http://bugs.php.net/fix.php?id=48509&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48509&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=48509&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=48509&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=48509&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=48509&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=48509&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=48509&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=48509&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48509&r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=48509&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48509&r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=48509&r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=48509&r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=48509&r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=48509&r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=48509&r=mysqlcfg

#41874 [Asn->Csd]: Separate STDOUT and STDERR in exec functions

2009-06-09 Thread pajoye 
 ID:   41874
 Updated by:   paj...@php.net
 Reported By:  ckeefer at us dot nomura dot com
-Status:   Assigned
+Status:   Closed
 Bug Type: Program Execution
 Operating System: win32 only
 PHP Version:  5CVS, 6CVS (2008-11-01)
 Assigned To:  pajoye
 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.

Fixed in 5.3+


Previous Comments:


[2008-10-24 16:13:15] j...@php.net

Assigned to the Windows port maintainer.



[2007-07-19 20:00:23] j...@php.net

As I'm not any win32 expert (nor really care about it) I'll deassign
this and forget that change, perhaps someone else who know the win32
stuff picks this up.



[2007-07-18 15:47:23] ckeefer at us dot nomura dot com

I don't actually see how this is an improvement as output was only
mixed if you don't redirect, which is expected.  If I do something like
php progname.php > logfile.txt, I would previously redirect STDIN to the
logfile as expected and stderr would still come to the console so I
could monitor the program's progress.  This is the usual behavior in
shell programs, etc.  This is how cmd line php was working through
version 5.21.  5.22 on changed behavior in that from Win32, the STDERR
disappears completely.  If you can tell me where STDERR went and how to
get to it from exec, I will happily do that.  I have hundreds (if not
thousands) of php scripts that do this.  This new behavior breaks all of
them.  If I do php progname.php 2>&1 > logfile.txt, even if this works,
I get mixed STDIN and STDERR output in the logfile.txt.  This will force
me to either stay at version 5.21 or earlier, or revise every script we
have that currently uses the exec function.

Again I ask: Did anything change with the compiler or other development
tools used to create the Window Binary?  Microsoft has been known to
modify libraries in undocumented ways.

Thanks
Chip Keefer



[2007-07-18 14:55:27] j...@php.net

Since this is actually improvement from previous behaviour where the
output was mixed, I'm changing this to a FR. I'll look into adding an
extra parameter to store STDERR in. In the meantime I suggest you use
proc_open() or popen() which give you more control over these..



[2007-07-18 13:01:40] ckeefer at us dot nomura dot com

>Oddly, 5.2.2+ versions still work correctly with cygwin/bash 3.1
Using the same Win32 binary, not a Cygwin binary.

To j...@php.net:  That is a good suggestion for just getting STDERR
output and I use it often on Unix and Linux systems when I need, and
don't care if outputs are mixed.  I haven't tested if this construct
works with W32.  Unfortunately, I need STDIN and STDERR separate.

I also have a question:  Did the version of compiler or libraries used
to compile the binary change? MS is notorious for making undocumented
changes to their development tools.

Thanks,
Chip Keefer



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/41874

-- 
Edit this bug report at http://bugs.php.net/?id=41874&edit=1

#48506 [Opn->Ver]: upcoming apr closes descriptors by default

2009-06-09 Thread scottmac 
 ID:  48506
 Updated by:  scott...@php.net
 Reported By: arekm at maven dot pl
-Status:  Open
+Status:  Verified
 Bug Type:Feature/Change Request
 PHP Version: 5.2.9
-Assigned To: 
+Assigned To: scottmac
 New Comment:

The details are here
https://issues.apache.org/bugzilla/show_bug.cgi?id=46425


Previous Comments:


[2009-06-09 13:47:52] arekm at maven dot pl

Description:

Upcoming apr 2.0.0 (or 1.3 with backported patch) uses O_CLOEXEC for
own descriptors by default.

This means that when using shell_exec() the run script/binary has no
stdin/stdout/stderr due to O_CLOEXEC. This also means that if any output
is produced then script ends with EPIPE.

Tested with apache + apr 1.3 with backported patch.

http://svn.apache.org/viewvc/apr/apr/trunk/CHANGES?r1=747357&r2=748988



Reproduce code:
---


Run from apache + php + apr 1.3 + backported O_CLOEXEC patch like this
one
http://cvs.pld-linux.org/cgi-bin/cvsweb/packages/apr/apr-bug-46425.patch?rev=1.8

Expected result:

run "ls -l" and produce some output about file not existing

Actual result:
--
30120 lstat("/notexistingfile", 0x18f55f0) = -1 ENOENT (No such file or
directory)
30120 write(2, "ls: ", 4)   = -1 EBADF (Bad file
descriptor)
30120 write(2, "cannot access /notexistingfile", 30) = -1 EBADF (Bad
file descriptor)
30120 write(2, ": No such file or directory", 27) = -1 EBADF (Bad file
descriptor)
30120 write(2, "\n", 1) = -1 EBADF (Bad file
descriptor)
30120 close(1)  = 0
30120 close(2)  = -1 EBADF (Bad file
descriptor)
30120 exit_group(2)

As you can see there is no file descriptor 2 and this means that ls
output is lost.


Probably the best for php is to always provide own descriptors without
relying on apache provided one.   





-- 
Edit this bug report at http://bugs.php.net/?id=48506&edit=1

#48508 [NEW]: Segfault with "include 'file.phar.bz2'

2009-06-09 Thread webmaster at ajeux dot com 
From: webmaster at ajeux dot com
Operating system: Linux 2.6.28
PHP version:  5.3CVS-2009-06-09 (snap)
PHP Bug Type: PHAR related
Bug description:  Segfault with "include 'file.phar.bz2'

Description:

Trying to include a specific .phar leads to a segfault under Linux.

The .phar is a bz2 archive, and very small (just one file inside).
Source of the file can be found here : 
http://uploadfile.org/download.php?id=EqxNUSSdIgcpKKCgrkgG

Bug seems to happen with any .phar.bz2 file.

Reproduce code:
---
http://bugs.php.net/?id=48508&edit=1
-- 
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48508&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48508&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48508&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48508&r=fixedcvs
Fixed in CVS and need be documented: 
http://bugs.php.net/fix.php?id=48508&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48508&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=48508&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=48508&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=48508&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=48508&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=48508&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=48508&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=48508&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48508&r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=48508&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48508&r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=48508&r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=48508&r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=48508&r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=48508&r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=48508&r=mysqlcfg

#48507 [NEW]: fgetcsv ignoring special characters

2009-06-09 Thread krynble at yahoo dot com dot br 
From: krynble at yahoo dot com dot br
Operating system: Unix
PHP version:  5.2.9
PHP Bug Type: Filesystem function related
Bug description:  fgetcsv ignoring special characters

Description:

Problem using fgetcsv ignoring special characters at the begining of a 
string.

The example I had was using the word "ÓTICA" with the "#" character as 
separator.

Reproduce code:
---
Consider a file with the following contents: WEIRD#ÓTICA#BEHAVIOR

When using fgetcsv to parse this file, I get an output like this:

Array(
   [0] => WEIRD,
   [1] => TICA,
   [2] => BEHAVIOR
)

Expected result:

Array(
   [0] => WEIRD,
   [1] => ÓTICA,
   [2] => BEHAVIOR
)

Actual result:
--
Array(
   [0] => WEIRD,
   [1] => TICA,
   [2] => BEHAVIOR
)

-- 
Edit bug report at http://bugs.php.net/?id=48507&edit=1
-- 
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48507&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48507&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48507&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48507&r=fixedcvs
Fixed in CVS and need be documented: 
http://bugs.php.net/fix.php?id=48507&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48507&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=48507&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=48507&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=48507&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=48507&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=48507&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=48507&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=48507&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48507&r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=48507&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48507&r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=48507&r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=48507&r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=48507&r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=48507&r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=48507&r=mysqlcfg

#48505 [Opn]: PHP-Informix ifx_fetch_row, text data type crash solution

2009-06-09 Thread amitshahc at hotmail dot com 
 ID:   48505
 User updated by:  amitshahc at hotmail dot com
 Reported By:  amitshahc at hotmail dot com
 Status:   Open
 Bug Type: Informix related
 Operating System: RHEL5, any linux
 PHP Version:  5.2.9
 New Comment:

sorry, this bug means not solutions but let us consider it as a trick
or tip or the way to overcome the bug.

Thanks


Previous Comments:


[2009-06-09 13:47:51] amitshahc at hotmail dot com

Description:

Solution: related to PHP Bugs: #32954 & #8715.


I think it's memory issue with apache handling the informix result id.
with text datatype. i don't know exactly as i am not ESQL/C developer.
but i used a combination of settings before executing the select query
which have the text field in the result.

Set 
ifx_blobinfile_mode(1);
ifx_textasvarchar(0);

will return the blob id, in text field value instead of the giving text
contect directly into that field. 

then do 
ifx_get_blob($row['text_field_name']). 
will return the file name. and then read that file content, store it in
the variable. and delete the file. 

doing 
ifx_free_blob($row['text_field_name']); 
again crashes the php script sometimes. so don't do it. 

but you can do ifx_free_result($resultId); at the end of the script.

All The Best...
Amit Shah






-- 
Edit this bug report at http://bugs.php.net/?id=48505&edit=1

#47712 [Fbk]: (mysqlnd) last fetched row may get corrupted after calling mysql_free_result()

2009-06-09 Thread andrey 
 ID:   47712
 Updated by:   and...@php.net
 Reported By:  ninzya at inbox dot lv
 Status:   Feedback
 Bug Type: MySQL related
 Operating System: Windows XP
 PHP Version:  5.3.0RC2
 Assigned To:  mysql
 New Comment:

Turning on is only possible through a recompilation. Maybe we can add
an ini option (INI_SYSTEM) to switch it without recompilation. But
currently the CVS is locked for changes.


Previous Comments:


[2009-06-09 11:05:57] ninzya at inbox dot lv

Well, seems something is wrong with concurrent access to zval cache on
windows. Try turning zval cache on and test my code on windows machine.



[2009-06-09 09:54:26] and...@php.net

The only change I did was to switch off the zval caching code so every
time a zval is needed a new one is created by Zend instead of using our
cache.



[2009-06-09 09:53:12] and...@php.net

 Hi,
maybe it is, I think it should be. I did not rely on phpt for testing.
I just put it on a Apache2 MPM, Linux, and ran 2 million requests,
concurrency of 150, thread-safe build. I asked ab to run with verbosity
of 2, and logged the output to a file. Then I did a grep on
Conten-Length, then I uniq-ued and sorted the results. Just 5 results.
One is correct, others were the errors because of exhausted resources.



[2009-06-08 13:52:46] ninzya at inbox dot lv

I have just tested my code on linux machine and got no problems. Seems
this bug affects only windows build.

I have downloaded latest available PHP 5.3.0RC3 snap from snaps.php.net
(PHP 5.3.0RC3-dev (built: Jun  8 2009 14:06:20)), the bug is gone now.
If this is your patched snap, then seems you have found the issue. If
not, mayble the solar activity has decreased (we're lucky and the bug
was fixed by another dev).

Anyway, i'm glad it's working now.



[2009-06-08 13:26:07] ninzya at inbox dot lv

Hello, Andrey.

Well, the script you are using is not exactly the same i have provided.
Try testing for values of $row keys, see if the contained data is the
data you expect, as i did in my case. Do not rely on PHPT, try
benchmarking locally. I will try my code on linux machine and report in
a couple of minutes.



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/47712

-- 
Edit this bug report at http://bugs.php.net/?id=47712&edit=1

#48506 [NEW]: upcoming apr closes descriptors by default

2009-06-09 Thread arekm at maven dot pl 
From: arekm at maven dot pl
Operating system: 
PHP version:  5.2.9
PHP Bug Type: Feature/Change Request
Bug description:  upcoming apr closes descriptors by default

Description:

Upcoming apr 2.0.0 (or 1.3 with backported patch) uses O_CLOEXEC for own
descriptors by default.

This means that when using shell_exec() the run script/binary has no
stdin/stdout/stderr due to O_CLOEXEC. This also means that if any output is
produced then script ends with EPIPE.

Tested with apache + apr 1.3 with backported patch.

http://svn.apache.org/viewvc/apr/apr/trunk/CHANGES?r1=747357&r2=748988



Reproduce code:
---


Run from apache + php + apr 1.3 + backported O_CLOEXEC patch like this one
http://cvs.pld-linux.org/cgi-bin/cvsweb/packages/apr/apr-bug-46425.patch?rev=1.8

Expected result:

run "ls -l" and produce some output about file not existing

Actual result:
--
30120 lstat("/notexistingfile", 0x18f55f0) = -1 ENOENT (No such file or
directory)
30120 write(2, "ls: ", 4)   = -1 EBADF (Bad file descriptor)
30120 write(2, "cannot access /notexistingfile", 30) = -1 EBADF (Bad file
descriptor)
30120 write(2, ": No such file or directory", 27) = -1 EBADF (Bad file
descriptor)
30120 write(2, "\n", 1) = -1 EBADF (Bad file descriptor)
30120 close(1)  = 0
30120 close(2)  = -1 EBADF (Bad file descriptor)
30120 exit_group(2)

As you can see there is no file descriptor 2 and this means that ls output
is lost.


Probably the best for php is to always provide own descriptors without
relying on apache provided one.   

-- 
Edit bug report at http://bugs.php.net/?id=48506&edit=1
-- 
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48506&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48506&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48506&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48506&r=fixedcvs
Fixed in CVS and need be documented: 
http://bugs.php.net/fix.php?id=48506&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48506&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=48506&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=48506&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=48506&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=48506&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=48506&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=48506&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=48506&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48506&r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=48506&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48506&r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=48506&r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=48506&r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=48506&r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=48506&r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=48506&r=mysqlcfg

#48505 [NEW]: PHP-Informix ifx_fetch_row, text data type crash solution

2009-06-09 Thread amitshahc at hotmail dot com 
From: amitshahc at hotmail dot com
Operating system: RHEL5, any linux
PHP version:  5.2.9
PHP Bug Type: Informix related
Bug description:  PHP-Informix ifx_fetch_row, text data type crash solution

Description:

Solution: related to PHP Bugs: #32954 & #8715.


I think it's memory issue with apache handling the informix result id.
with text datatype. i don't know exactly as i am not ESQL/C developer. but
i used a combination of settings before executing the select query which
have the text field in the result.

Set 
ifx_blobinfile_mode(1);
ifx_textasvarchar(0);

will return the blob id, in text field value instead of the giving text
contect directly into that field. 

then do 
ifx_get_blob($row['text_field_name']). 
will return the file name. and then read that file content, store it in
the variable. and delete the file. 

doing 
ifx_free_blob($row['text_field_name']); 
again crashes the php script sometimes. so don't do it. 

but you can do ifx_free_result($resultId); at the end of the script.

All The Best...
Amit Shah


-- 
Edit bug report at http://bugs.php.net/?id=48505&edit=1
-- 
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48505&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48505&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48505&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48505&r=fixedcvs
Fixed in CVS and need be documented: 
http://bugs.php.net/fix.php?id=48505&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48505&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=48505&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=48505&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=48505&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=48505&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=48505&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=48505&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=48505&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48505&r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=48505&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48505&r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=48505&r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=48505&r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=48505&r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=48505&r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=48505&r=mysqlcfg

#47042 [Opn->Csd]: cgi sapi is incorrectly removing the SCRIPT_FILENAME for non apache

2009-06-09 Thread dsp 
 ID:   47042
 Updated by:   d...@php.net
 Reported By:  sriram dot natarajan at sun dot com
-Status:   Open
+Status:   Closed
 Bug Type: CGI related
 Operating System: linux , solaris
 PHP Version:  5.2.9
 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:


[2009-06-09 00:39:08] php at dzm dot com

I can verify that Sriram's patch works correctly (13-Mar) on a patched
PHP 5.2.9 FCGI on Fedora 10.

Can anyone validate this for Windows/IIS and get this into PHP 5.2.10?



[2009-05-09 18:40:02] php at dzm dot com

This behavior remains broken in PHP 5.2.9. Is there any chance at all
of the patch being integrated into 5.2.10?



[2009-03-16 23:55:37] j...@php.net

See also bug #47625



[2009-03-13 00:10:22] sriram dot natarajan at sun dot com

hi
 this fix is not available with the latest php snapshot. my latest
patch needs to be looked into and considered fixing it for 5.3 as well
as 5.2.9

[sn123...@samp]'php5'>diff -u php-5.2.9/sapi/cgi/cgi_main.c.ORIG
php-5.2.9/sapi/cgi/cgi_main.c
--- php-5.2.9/sapi/cgi/cgi_main.c.ORIG  Sat Feb 28 00:44:54 2009
+++ php-5.2.9/sapi/cgi/cgi_main.c   Sat Feb 28 00:46:00 2009
@@ -961,7 +961,8 @@
}

if (env_path_translated != NULL &&
env_redirect_url != NULL &&
-   orig_script_filename != NULL &&
script_path_translated != NULL) {
+   env_path_translated !=
script_path_translated &&
+   strcmp(env_path_translated,
script_path_translated) != 0) {
/* 
   pretty much apache specific.  If we
have a redirect_url
   then our script_filename and
script_name point to the

thanks
sriram



[2009-03-03 09:56:55] sriram dot natarajan at sun dot com

i have tested this patch with apache 2.0 and 2.2 configurations within
cgi and was able to get applications like joomla working fine.

can some one kindly look into the attached patch and provide your
feedback

thanks



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/47042

-- 
Edit this bug report at http://bugs.php.net/?id=47042&edit=1

#48471 [Opn]: Memory request by objects optimization

2009-06-09 Thread busia at tiscali dot it 
 ID:   48471
 User updated by:  busia at tiscali dot it
 Reported By:  busia at tiscali dot it
 Status:   Open
 Bug Type: Feature/Change Request
 Operating System: Irrilevant
 PHP Version:  5.3CVS-2009-06-04 (snap)
 New Comment:

I saw that when I create more than 1023 objects, the unremovable cache
of the objects between 1024° and 4095° grow as 64 bytes for object,
between 4096° and 8191° grows as 128 bytes for object. It grows
exponentially and this is a biggest problem.


Previous Comments:


[2009-06-04 13:02:19] busia at tiscali dot it

Description:

In bug report #48434 lbarn...@php.net wrote me:
---
PHP uses an array internally to store all objects. When you create more
objects, the array is grown. When you destroy some objects, the array is
not resized, so that creating other objects is faster.

This is the difference you see; ~32 bytes per object.

This is not due to the allocator. There is a few other caches of this
kind in PHP that make it running faster.
---

Using many objects this is a problem, I need a function to force
resizing of the internal object array. I know that this would slow down
the script but this function (like mysql_free_result) would be useful in
many situations (like working on many objects array). Is it possible to
have a function like that?

Thanks






-- 
Edit this bug report at http://bugs.php.net/?id=48471&edit=1

#47712 [Com]: (mysqlnd) last fetched row may get corrupted after calling mysql_free_result()

2009-06-09 Thread ninzya at inbox dot lv 
 ID:   47712
 Comment by:   ninzya at inbox dot lv
 Reported By:  ninzya at inbox dot lv
 Status:   Feedback
 Bug Type: MySQL related
 Operating System: Windows XP
 PHP Version:  5.3.0RC2
 Assigned To:  mysql
 New Comment:

Well, seems something is wrong with concurrent access to zval cache on
windows. Try turning zval cache on and test my code on windows machine.


Previous Comments:


[2009-06-09 09:54:26] and...@php.net

The only change I did was to switch off the zval caching code so every
time a zval is needed a new one is created by Zend instead of using our
cache.



[2009-06-09 09:53:12] and...@php.net

 Hi,
maybe it is, I think it should be. I did not rely on phpt for testing.
I just put it on a Apache2 MPM, Linux, and ran 2 million requests,
concurrency of 150, thread-safe build. I asked ab to run with verbosity
of 2, and logged the output to a file. Then I did a grep on
Conten-Length, then I uniq-ued and sorted the results. Just 5 results.
One is correct, others were the errors because of exhausted resources.



[2009-06-08 13:52:46] ninzya at inbox dot lv

I have just tested my code on linux machine and got no problems. Seems
this bug affects only windows build.

I have downloaded latest available PHP 5.3.0RC3 snap from snaps.php.net
(PHP 5.3.0RC3-dev (built: Jun  8 2009 14:06:20)), the bug is gone now.
If this is your patched snap, then seems you have found the issue. If
not, mayble the solar activity has decreased (we're lucky and the bug
was fixed by another dev).

Anyway, i'm glad it's working now.



[2009-06-08 13:26:07] ninzya at inbox dot lv

Hello, Andrey.

Well, the script you are using is not exactly the same i have provided.
Try testing for values of $row keys, see if the contained data is the
data you expect, as i did in my case. Do not rely on PHPT, try
benchmarking locally. I will try my code on linux machine and report in
a couple of minutes.



[2009-06-08 13:17:46] and...@php.net

Just tried again. 2 million requests, concurrency of 150, which led to
load of 90 on the box - pretty hefty, where a problem should show itself
and again no problem except that in some cases connection to MySQL
couldn't be established, which is to be expected. MySQL was set up to
have 1000 maximal connections, so it is not the bottleneck, just system
resources.



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/47712

-- 
Edit this bug report at http://bugs.php.net/?id=47712&edit=1

#48504 [Opn->Bgs]: document_element contains nothing

2009-06-09 Thread ikrabbe dot ask at web dot de 
 ID:   48504
 User updated by:  ikrabbe dot ask at web dot de
 Reported By:  ikrabbe dot ask at web dot de
-Status:   Open
+Status:   Bogus
 Bug Type: DOM XML related
 Operating System: Linux
 PHP Version:  5.2.9
 New Comment:

Sorry, I misspelled the item: document_element is called
documentElement.


Previous Comments:


[2009-06-09 10:53:32] ikrabbe dot ask at web dot de

Actually:
if ( !$xmldocu->document_element )
  echo "NULL Document";
reveals a NULL root node !  Thats actually a bug.  Please either
correct this behaviour or describe whats meant by "document_element" in
the documentation.



[2009-06-09 10:48:36] ikrabbe dot ask at web dot de

Description:

on
$xml="abc";
$xmldoc = new DOMDocument();
$xmldoc->loadXML($xml);
I get for
echo "item 0=".$xmldoc->childNodes->item(0)->nodeName."\n";
echo "root =".$xmldoc->document_element->nodeName."\n";
the output:
item 0=a
root=
I assumed that document_element should be the same as
childNodes->item(0), so I assume that is a bug.


Reproduce code:
---
see above

Expected result:

see above

Actual result:
--
see above





-- 
Edit this bug report at http://bugs.php.net/?id=48504&edit=1

#48504 [Opn]: document_element contains nothing

2009-06-09 Thread ikrabbe dot ask at web dot de 
 ID:   48504
 User updated by:  ikrabbe dot ask at web dot de
 Reported By:  ikrabbe dot ask at web dot de
 Status:   Open
 Bug Type: DOM XML related
 Operating System: Linux
 PHP Version:  5.2.9
 New Comment:

Actually:
if ( !$xmldocu->document_element )
  echo "NULL Document";
reveals a NULL root node !  Thats actually a bug.  Please either
correct this behaviour or describe whats meant by "document_element" in
the documentation.


Previous Comments:


[2009-06-09 10:48:36] ikrabbe dot ask at web dot de

Description:

on
$xml="abc";
$xmldoc = new DOMDocument();
$xmldoc->loadXML($xml);
I get for
echo "item 0=".$xmldoc->childNodes->item(0)->nodeName."\n";
echo "root =".$xmldoc->document_element->nodeName."\n";
the output:
item 0=a
root=
I assumed that document_element should be the same as
childNodes->item(0), so I assume that is a bug.


Reproduce code:
---
see above

Expected result:

see above

Actual result:
--
see above





-- 
Edit this bug report at http://bugs.php.net/?id=48504&edit=1

#48504 [NEW]: document_element contains nothing

2009-06-09 Thread ikrabbe dot ask at web dot de 
From: ikrabbe dot ask at web dot de
Operating system: Linux
PHP version:  5.2.9
PHP Bug Type: DOM XML related
Bug description:  document_element contains nothing

Description:

on
$xml="abc";
$xmldoc = new DOMDocument();
$xmldoc->loadXML($xml);
I get for
echo "item 0=".$xmldoc->childNodes->item(0)->nodeName."\n";
echo "root =".$xmldoc->document_element->nodeName."\n";
the output:
item 0=a
root=
I assumed that document_element should be the same as childNodes->item(0),
so I assume that is a bug.


Reproduce code:
---
see above

Expected result:

see above

Actual result:
--
see above

-- 
Edit bug report at http://bugs.php.net/?id=48504&edit=1
-- 
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48504&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48504&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48504&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48504&r=fixedcvs
Fixed in CVS and need be documented: 
http://bugs.php.net/fix.php?id=48504&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48504&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=48504&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=48504&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=48504&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=48504&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=48504&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=48504&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=48504&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48504&r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=48504&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48504&r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=48504&r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=48504&r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=48504&r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=48504&r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=48504&r=mysqlcfg

#48503 [NEW]: invalid conversion from 'void*' to 'zval*' in zend_execute.h

2009-06-09 Thread webmaster at ajeux dot com 
From: webmaster at ajeux dot com
Operating system: Linux 2.6.28
PHP version:  5.3CVS-2009-06-09 (CVS)
PHP Bug Type: Compile Failure
Bug description:  invalid conversion from 'void*' to 'zval*' in zend_execute.h

Description:

Latest snapshot (php5.3-200906090830) failed to compile. The same bug is
encountered in php5.3-200906081430.

gcc version 4.3.0 20080428.

It seems bug is related to ext/intl.

Reproduce code:
---
./configure '--with-libdir=lib64' '--enable-zip' '--with-xsl'
'--enable-wddx' '--with-tidy' '--enable-soap' '--with-bz2' '--with-imap'
'--with-imap-ssl' '--with-kerberos' '--with-mysql=mysqlnd'
'--with-mysqli=mysqlnd' '--with-openssl' '--with-pdo-mysql=mysqlnd'
'--with-pdo-sqlite' '--with-pspell' '--with-pgsql' '--with-pdo-pgsql'
'--with-zlib' '--enable-bcmath' '--enable-calendar' '--with-curl'
'--with-curlwrappers' '--enable-dba' '--enable-exif' '--enable-ftp'
'--with-gd' '--with-gmp' '--enable-pcntl' '--enable-shmop'
'--enable-sockets' '--enable-sysvmsg' '--enable-sysvsem' '--enable-sysvshm'
'--with-xmlrpc' '--with-ldap' '--enable-mbstring' '--with-png-dir'
'--with-jpeg-dir' '--with-xpm-dir' '--with-freetype-dir' '--with-gdbm'
'--with-mcrypt' '--with-gettext' '--with-readline' '--enable-intl'
'--enable-gcov' && make && make test



Expected result:

Make succeed :)

Actual result:
--
In file included from
/usr/src/phptest/php5.3-200906090830/Zend/zend_API.h:30,
 from /usr/src/phptest/php5.3-200906090830/main/php.h:38,
 from ext/intl/php_intl.h:23,
 from
/usr/src/phptest/php5.3-200906090830/ext/intl/msgformat/msgformat_helpers.cpp:26:
/usr/src/phptest/php5.3-200906090830/Zend/zend_execute.h: In function
'void zend_arg_types_stack_2_pop(zend_ptr_stack*, zval**,
zend_function**)':
/usr/src/phptest/php5.3-200906090830/Zend/zend_execute.h:301: error:
invalid conversion from 'void*' to 'zval*'
/usr/src/phptest/php5.3-200906090830/Zend/zend_execute.h:302: error:
invalid conversion from 'void*' to 'zend_function*'
/usr/src/phptest/php5.3-200906090830/Zend/zend_execute.h: In function
'void zend_arg_types_stack_3_pop(zend_ptr_stack*, zend_class_entry**,
zval**, zend_function**)':
/usr/src/phptest/php5.3-200906090830/Zend/zend_execute.h:311: error:
invalid conversion from 'void*' to 'zend_class_entry*'
/usr/src/phptest/php5.3-200906090830/Zend/zend_execute.h:312: error:
invalid conversion from 'void*' to 'zval*'
/usr/src/phptest/php5.3-200906090830/Zend/zend_execute.h:313: error:
invalid conversion from 'void*' to 'zend_function*'
make: *** [ext/intl/msgformat/msgformat_helpers.lo] Error 1


-- 
Edit bug report at http://bugs.php.net/?id=48503&edit=1
-- 
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48503&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48503&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48503&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48503&r=fixedcvs
Fixed in CVS and need be documented: 
http://bugs.php.net/fix.php?id=48503&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48503&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=48503&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=48503&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=48503&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=48503&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=48503&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=48503&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=48503&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48503&r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=48503&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48503&r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=48503&r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=48503&r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=48503&r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=48503&r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=48503&r=mysqlcfg

#48503 [Opn->Csd]: invalid conversion from 'void*' to 'zval*' in zend_execute.h

2009-06-09 Thread pajoye 
 ID:   48503
 Updated by:   paj...@php.net
 Reported By:  webmaster at ajeux dot com
-Status:   Open
+Status:   Closed
 Bug Type: Compile Failure
 Operating System: Linux 2.6.28
 PHP Version:  5.3CVS-2009-06-09 (CVS)
-Assigned To:  
+Assigned To:  pajoye
 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:


[2009-06-09 10:02:00] webmaster at ajeux dot com

Description:

Latest snapshot (php5.3-200906090830) failed to compile. The same bug
is encountered in php5.3-200906081430.

gcc version 4.3.0 20080428.

It seems bug is related to ext/intl.

Reproduce code:
---
./configure '--with-libdir=lib64' '--enable-zip' '--with-xsl'
'--enable-wddx' '--with-tidy' '--enable-soap' '--with-bz2' '--with-imap'
'--with-imap-ssl' '--with-kerberos' '--with-mysql=mysqlnd'
'--with-mysqli=mysqlnd' '--with-openssl' '--with-pdo-mysql=mysqlnd'
'--with-pdo-sqlite' '--with-pspell' '--with-pgsql' '--with-pdo-pgsql'
'--with-zlib' '--enable-bcmath' '--enable-calendar' '--with-curl'
'--with-curlwrappers' '--enable-dba' '--enable-exif' '--enable-ftp'
'--with-gd' '--with-gmp' '--enable-pcntl' '--enable-shmop'
'--enable-sockets' '--enable-sysvmsg' '--enable-sysvsem'
'--enable-sysvshm' '--with-xmlrpc' '--with-ldap' '--enable-mbstring'
'--with-png-dir' '--with-jpeg-dir' '--with-xpm-dir'
'--with-freetype-dir' '--with-gdbm' '--with-mcrypt' '--with-gettext'
'--with-readline' '--enable-intl' '--enable-gcov' && make && make test



Expected result:

Make succeed :)

Actual result:
--
In file included from
/usr/src/phptest/php5.3-200906090830/Zend/zend_API.h:30,
 from
/usr/src/phptest/php5.3-200906090830/main/php.h:38,
 from ext/intl/php_intl.h:23,
 from
/usr/src/phptest/php5.3-200906090830/ext/intl/msgformat/msgformat_helpers.cpp:26:
/usr/src/phptest/php5.3-200906090830/Zend/zend_execute.h: In function
'void zend_arg_types_stack_2_pop(zend_ptr_stack*, zval**,
zend_function**)':
/usr/src/phptest/php5.3-200906090830/Zend/zend_execute.h:301: error:
invalid conversion from 'void*' to 'zval*'
/usr/src/phptest/php5.3-200906090830/Zend/zend_execute.h:302: error:
invalid conversion from 'void*' to 'zend_function*'
/usr/src/phptest/php5.3-200906090830/Zend/zend_execute.h: In function
'void zend_arg_types_stack_3_pop(zend_ptr_stack*, zend_class_entry**,
zval**, zend_function**)':
/usr/src/phptest/php5.3-200906090830/Zend/zend_execute.h:311: error:
invalid conversion from 'void*' to 'zend_class_entry*'
/usr/src/phptest/php5.3-200906090830/Zend/zend_execute.h:312: error:
invalid conversion from 'void*' to 'zval*'
/usr/src/phptest/php5.3-200906090830/Zend/zend_execute.h:313: error:
invalid conversion from 'void*' to 'zend_function*'
make: *** [ext/intl/msgformat/msgformat_helpers.lo] Error 1






-- 
Edit this bug report at http://bugs.php.net/?id=48503&edit=1

#47712 [Fbk]: (mysqlnd) last fetched row may get corrupted after calling mysql_free_result()

2009-06-09 Thread andrey 
 ID:   47712
 Updated by:   and...@php.net
 Reported By:  ninzya at inbox dot lv
 Status:   Feedback
 Bug Type: MySQL related
 Operating System: Windows XP
 PHP Version:  5.3.0RC2
 Assigned To:  mysql
 New Comment:

The only change I did was to switch off the zval caching code so every
time a zval is needed a new one is created by Zend instead of using our
cache.


Previous Comments:


[2009-06-09 09:53:12] and...@php.net

 Hi,
maybe it is, I think it should be. I did not rely on phpt for testing.
I just put it on a Apache2 MPM, Linux, and ran 2 million requests,
concurrency of 150, thread-safe build. I asked ab to run with verbosity
of 2, and logged the output to a file. Then I did a grep on
Conten-Length, then I uniq-ued and sorted the results. Just 5 results.
One is correct, others were the errors because of exhausted resources.



[2009-06-08 13:52:46] ninzya at inbox dot lv

I have just tested my code on linux machine and got no problems. Seems
this bug affects only windows build.

I have downloaded latest available PHP 5.3.0RC3 snap from snaps.php.net
(PHP 5.3.0RC3-dev (built: Jun  8 2009 14:06:20)), the bug is gone now.
If this is your patched snap, then seems you have found the issue. If
not, mayble the solar activity has decreased (we're lucky and the bug
was fixed by another dev).

Anyway, i'm glad it's working now.



[2009-06-08 13:26:07] ninzya at inbox dot lv

Hello, Andrey.

Well, the script you are using is not exactly the same i have provided.
Try testing for values of $row keys, see if the contained data is the
data you expect, as i did in my case. Do not rely on PHPT, try
benchmarking locally. I will try my code on linux machine and report in
a couple of minutes.



[2009-06-08 13:17:46] and...@php.net

Just tried again. 2 million requests, concurrency of 150, which led to
load of 90 on the box - pretty hefty, where a problem should show itself
and again no problem except that in some cases connection to MySQL
couldn't be established, which is to be expected. MySQL was set up to
have 1000 maximal connections, so it is not the bottleneck, just system
resources.



[2009-06-08 12:46:49] and...@php.net

Hi, I switched on the zval cache and tried to reproduce the problem,
with no success.
I tested with Apache2 MPM. `ab` concurrency level starting from 20 up
to 100. Time from 30 to 45 seconds. I got, with your code, only 3 types
of errors. I added mysql_connect() myself
- mysql_connect() fails because cannot have more connections on the
unix socket. Using TCP/IP exhausts the resources earlier for connecting
to MySQL
- mysql_query() tries to connect, although the connection has failed,
typical for mysql_query()! It fails :
-- password problem
-- no resources

I did not see any corruption whatsoever. Difference from you is that I
tested on Linux, as server. ab was running on a Mac connected over a
FastEthernet switch.

Here follows the code I used:





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/47712

-- 
Edit this bug report at http://bugs.php.net/?id=47712&edit=1

#47712 [Fbk]: (mysqlnd) last fetched row may get corrupted after calling mysql_free_result()

2009-06-09 Thread andrey 
 ID:   47712
 Updated by:   and...@php.net
 Reported By:  ninzya at inbox dot lv
 Status:   Feedback
 Bug Type: MySQL related
 Operating System: Windows XP
 PHP Version:  5.3.0RC2
 Assigned To:  mysql
 New Comment:

 Hi,
maybe it is, I think it should be. I did not rely on phpt for testing.
I just put it on a Apache2 MPM, Linux, and ran 2 million requests,
concurrency of 150, thread-safe build. I asked ab to run with verbosity
of 2, and logged the output to a file. Then I did a grep on
Conten-Length, then I uniq-ued and sorted the results. Just 5 results.
One is correct, others were the errors because of exhausted resources.


Previous Comments:


[2009-06-08 13:52:46] ninzya at inbox dot lv

I have just tested my code on linux machine and got no problems. Seems
this bug affects only windows build.

I have downloaded latest available PHP 5.3.0RC3 snap from snaps.php.net
(PHP 5.3.0RC3-dev (built: Jun  8 2009 14:06:20)), the bug is gone now.
If this is your patched snap, then seems you have found the issue. If
not, mayble the solar activity has decreased (we're lucky and the bug
was fixed by another dev).

Anyway, i'm glad it's working now.



[2009-06-08 13:26:07] ninzya at inbox dot lv

Hello, Andrey.

Well, the script you are using is not exactly the same i have provided.
Try testing for values of $row keys, see if the contained data is the
data you expect, as i did in my case. Do not rely on PHPT, try
benchmarking locally. I will try my code on linux machine and report in
a couple of minutes.



[2009-06-08 13:17:46] and...@php.net

Just tried again. 2 million requests, concurrency of 150, which led to
load of 90 on the box - pretty hefty, where a problem should show itself
and again no problem except that in some cases connection to MySQL
couldn't be established, which is to be expected. MySQL was set up to
have 1000 maximal connections, so it is not the bottleneck, just system
resources.



[2009-06-08 12:46:49] and...@php.net

Hi, I switched on the zval cache and tried to reproduce the problem,
with no success.
I tested with Apache2 MPM. `ab` concurrency level starting from 20 up
to 100. Time from 30 to 45 seconds. I got, with your code, only 3 types
of errors. I added mysql_connect() myself
- mysql_connect() fails because cannot have more connections on the
unix socket. Using TCP/IP exhausts the resources earlier for connecting
to MySQL
- mysql_query() tries to connect, although the connection has failed,
typical for mysql_query()! It fails :
-- password problem
-- no resources

I did not see any corruption whatsoever. Difference from you is that I
tested on Linux, as server. ab was running on a Mac connected over a
FastEthernet switch.

Here follows the code I used:





[2009-06-08 10:36:49] and...@php.net

 Is is possible to provide a package which we can run, even it is not
20-30lines of code, so we can try to reproduce the problem?

In the meanwhile I have committed a change to mysqlnd which I suppose
should lead to the problem disappearing - switching the zval cache off.
Could you try downloading and testing a binary from
http://windows.php.net/snapshots/

New snapshot should be ready in a few hours. I suppose you will need
the VC6 build.

Thank you!
Andrey



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/47712

-- 
Edit this bug report at http://bugs.php.net/?id=47712&edit=1

#48491 [Fbk->Opn]: Crash at start-up

2009-06-09 Thread jom at grosjo dot net 
 ID:   48491
 User updated by:  jom at grosjo dot net
 Reported By:  jom at grosjo dot net
-Status:   Feedback
+Status:   Open
 Bug Type: Reproducible crash
 Operating System: Linux OpenSUSE 11.0 x86_64
 PHP Version:  5.3.0RC2
 New Comment:

latest cvs does not compile !

In file included from
/data/admin/softs/php5.3-200906090630/Zend/zend_API.h:30,
 from
/data/admin/softs/php5.3-200906090630/main/php.h:38,
 from ext/intl/php_intl.h:23,
 from
/data/admin/softs/php5.3-200906090630/ext/intl/msgformat/msgformat_helpers.cpp:26:
/data/admin/softs/php5.3-200906090630/Zend/zend_execute.h: In function
'void zend_arg_types_stack_2_pop(zend_ptr_stack*, zval**,
zend_function**)':
/data/admin/softs/php5.3-200906090630/Zend/zend_execute.h:301: error:
invalid conversion from 'void*' to 'zval*'
/data/admin/softs/php5.3-200906090630/Zend/zend_execute.h:302: error:
invalid conversion from 'void*' to 'zend_function*'
/data/admin/softs/php5.3-200906090630/Zend/zend_execute.h: In function
'void zend_arg_types_stack_3_pop(zend_ptr_stack*, zend_class_entry**,
zval**, zend_function**)':
/data/admin/softs/php5.3-200906090630/Zend/zend_execute.h:311: error:
invalid conversion from 'void*' to 'zend_class_entry*'
/data/admin/softs/php5.3-200906090630/Zend/zend_execute.h:312: error:
invalid conversion from 'void*' to 'zval*'
/data/admin/softs/php5.3-200906090630/Zend/zend_execute.h:313: error:
invalid conversion from 'void*' to 'zend_function*'
make: *** [ext/intl/msgformat/msgformat_helpers.lo] Error 1


Previous Comments:


[2009-06-07 19:08:38] der...@php.net

Please try using this CVS snapshot:

  http://snaps.php.net/php5.3-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/



[2009-06-07 18:18:19] jom at grosjo dot net

Description:

./sapi/cli/php crash at start-up time


Reproduce code:
---
# gdb ./sapi/cli/php 
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show
copying"
and "show warranty" for details.
This GDB was configured as "x86_64-suse-linux"...
(gdb) run
Starting program: /data/admin/softs/php-5.3.0RC2/sapi/cli/php 
[Thread debugging using libthread_db enabled]
warning: Lowest section in /usr/lib/libicudata.so.38 is .hash at
0158
[New Thread 0x7f700dfe8700 (LWP 32397)]
PHP Warning:  PHP Startup: It is not safe to rely on the system's
timezone settings. You are *required* to use the date.timezone setting
or the date_default_timezone_set() function. In case you used any of
those methods and you are still getting this warning, you most likely
misspelled the timezone identifier. We selected 'Europe/Helsinki' for
'EEST/3.0/DST' instead in Unknown on line 0

Warning: PHP Startup: It is not safe to rely on the system's timezone
settings. You are *required* to use the date.timezone setting or the
date_default_timezone_set() function. In case you used any of those
methods and you are still getting this warning, you most likely
misspelled the timezone identifier. We selected 'Europe/Helsinki' for
'EEST/3.0/DST' instead in Unknown on line 0

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f700dfe8700 (LWP 32397)]
0x007d9140 in zend_hash_find (ht=0x10527f0, arKey=0x8e2e49
"Africa/Cairo", nKeyLength=16, pData=0x7fff15ef97a8)
at /data/admin/softs/php-5.3.0RC2/Zend/zend_hash.c:880
880 p = ht->arBuckets[nIndex];
(gdb) next

Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
(gdb) quit


Actual result:
--
Segmentation fault





-- 
Edit this bug report at http://bugs.php.net/?id=48491&edit=1