#50509 [Com]: "make install-pear-installer" does not honor $INSTALL_ROOT

[php at group dot apple dot com]

 ID:   50509
 Comment by:   php at group dot apple dot com
 Reported By:  thomas dot parrott at jellyfish dot co dot uk
 Status:   Assigned
 Bug Type: PHAR related
 Operating System: CentOS 5.4
 PHP Version:  5.2.12
 Assigned To:  cellog
 New Comment:

Looks like the same bug reported as https://pear.php.net/bugs/bug.php?
id=17067


Previous Comments:


[2009-12-18 00:33:47] j...@php.net

Assigned to the PEAR maintainer.



[2009-12-17 17:27:41] thomas dot parrott at jellyfish dot co dot uk

Description:

When building PHP as an RPM, "make install-pear-installer" does not
provide the ability to install in a non-root environment, but still
reference root file paths like /usr/lib/php in the files generated.

Expected result:

I expect the make install-pear-installer command to provide an option
for BUILD_ROOT like PHP does, in order to install files into a non-root
location.






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

#50875 [Com]: Objects loaded using PDO are *empty* when the __construct method is called

[contact at weirdog dot com]

 ID:   50875
 Comment by:   contact at weirdog dot com
 Reported By:  contact at weirdog dot com
 Status:   Feedback
 Bug Type: PDO related
 Operating System: Linux
 PHP Version:  5.2.12
 New Comment:

There are no binaries snapshots currently available. I tried with the
QA Release of PHP 5.2 (5.2.13RC2) and it doesn't work either, which
might not be surprising since the snapshot is older than the modified
status date of the bug report.


Previous Comments:


[2010-02-15 23:00:00] fel...@php.net

Please try using this snapshot:

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

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





[2010-02-11 23:29:26] michael at twofishcreative dot com

See this post to the PHP internals list, and follow ups, about this
change http://news.php.net/php.internals/46748.



[2010-01-28 20:17:13] contact at weirdog dot com

Description:

Objects loaded using PDO are *empty* (as in "they have no properties")
when the __construct() method is called.

This was not the case before version 5.2.12. Usualy, properties loaded
from the database where already applyed when the __construct() method
was called.

This is really annoying since further initialisation during the
__construct() method is now impossible.

Reproduce code:
---
class WdActiveRecord
{
public function __construct()
{
var_dump($this);
}
}

$stmt = $db->query('SELECT * FROM nodes WHERE nid = 498');

$stmt->fetchObject('WdActiveRecord');

Expected result:

object(site_pages_WdActiveRecord)[68]
  public 'nid' => string '498' (length=3)
  public 'parentid' => string '0' (length=1)
  public 'pattern' => string 'about' (length=5)
  public 'weight' => string '9' (length=1)
  public 'layout' => string 'page' (length=5)
  public 'location' => string '' (length=22)
  public 'is_navigation_excluded' => string '0' (length=1)
  public 'is_restricted' => string '0' (length=1)
  public 'uid' => string '9' (length=1)
  public 'title' => string 'À propos' (length=16)
  public 'slug' => string 'apropos' (length=15)
  public 'created' => string '2009-11-29 18:13:17' (length=19)
  public 'modified' => string '2009-11-29 18:17:29' (length=19)
  public 'constructor' => string 'site.pages' (length=10)
  public 'is_online' => string '1' (length=1)
  public 'language' => string '' (length=0)
  public 'tnid' => string '0' (length=1)
  public 'is_translation_deprecated' => string '0' (length=1)

Actual result:
--
object(site_pages_WdActiveRecord)#68 (0) { }





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

#51094 [NEW]: parse_ini_file() with INI_SCANNER_RAW cuts a value that includes a semi-colon

[viaujoc at videotron dot ca]

From: viaujoc at videotron dot ca
Operating system: Win2003
PHP version:  5.3.1
PHP Bug Type: Filesystem function related
Bug description:  parse_ini_file() with INI_SCANNER_RAW cuts a value that 
includes a semi-colon

Description:

When using parse_ini_file() function with $scanner_mode=INI_SCANNER_RAW,
any semi-colon (;) in the value is seen as the end of the value, even if it
is enclosed in quotes.

The behavior of parse_ini_file() in PHP 5.3 with either $scanner_mode at
RAW or NORMAL cannot reproduce the  behavior of PHP 5.2.

Reproduce code:
---
test.ini:
[TheSection]
MyKey="my;value\$"

example.php:


Expected result:

array(1) {
  ["TheSection"]=>
  array(1) {
["MyKey"]=>
string(10) "my;value\$"
  }
}

Actual result:
--
In PHP 5.2 (without the $scanner_mode parameter in parse_ini_file()):
array(1) {
  ["TheSection"]=>
  array(1) {
["MyKey"]=>
string(10) "my;value\$"
  }
}
(the value is returned exactly as it appears in test.ini)

In PHP 5.3 (with $scanner_mode=INI_SCANNER_RAW):
array(1) {
  ["TheSection"]=>
  array(1) {
["MyKey"]=>
string(3) ""my"
  }
}
(notice that everything after the semi-colon has been truncated and the
quote as the first character of the string)

In PHP 5.3 (with $scanner_mode=INI_SCANNER_NORMAL):
array(1) {
  ["TheSection"]=>
  array(1) {
["MyKey"]=>
string(9) "my;value$"
  }
}
(notice the missing backslash (\) between the "e" and "$")

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

#40913 [Com]: PDO::PARAM_LOB does not bind to a stream for fetching a BLOB

[jcook at macmillanmarketing dot com]

 ID:   40913
 Comment by:   jcook at macmillanmarketing dot com
 Reported By:  dennis at inmarket dot lviv dot ua
 Status:   Verified
 Bug Type: PDO related
 Operating System: Win XP
 PHP Version:  5.2.6
 Assigned To:  wez
 New Comment:

I've just been able to reproduce this bug today running PHP 5.3.1 on 
Windows.

Reproduce Code:

$db = db::getConn();
$st = $db->prepare($sql);
$st->execute(array(':id' => $id));
$st->bindColumn(1, $image, PDO::PARAM_LOB);
$st->fetch(PDO::FETCH_BOUND);
header ('Content-type: image/jpeg');
fpassthru($image);// this call fails with 'supplied argument is not a
valid stream resource'

Expected result:
Resource

Actual result:
string

I can work around this error for what I'm trying to do but it would be

nice if this was fixed.


Previous Comments:


[2009-07-27 15:12:53] ralph dot reckert at web dot de

That error still does not seem to be solved in the current PHP version
5.3.0 nor in 5.2.10. At least it is not listed in the ChangeLog list of
fixed bugs of that versions. 

It would be nice if, four years after PDO was released and almost two
and a half years after that bug was first reported, someone could try to
fix it, really test that fix and make shure it finds it's way into some
release version of PHP. 

Until then, in my opinion the status of this bug report should be
OPEN!

Best regards,
Ralph



[2009-06-30 14:13:16] ralfbecker at egroupware dot org

Hi,
I still can reproduce the Problem with php5.3.0RC2.
Ralf



[2009-05-29 14:25:59] linuxuser586 at yahoo dot com

Problem still exists on Windows 2003 with PHP Version 5.2.10RC2-dev
Build Date May 29 2009 11:39:28



[2009-05-03 01:00:03] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".



[2009-04-25 14:44:38] j...@php.net

Please try using this CVS snapshot:

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

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





The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/40913

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

#51092 [Opn->Fbk]: HTTP redirection broken in 5.3.1

[pajoye]

 ID:   51092
 Updated by:   paj...@php.net
 Reported By:  cpuidle at gmx dot de
-Status:   Open
+Status:   Feedback
 Bug Type: HTTP related
 Operating System: WinXP SP3
 PHP Version:  5.3.1
 New Comment:

Works for me, please try 5.3.2RC2.


Previous Comments:


[2010-02-19 19:34:08] cpuidle at gmx dot de

Before anybody points me to the HTTP 1.1 spec- this one doesn't
redirect either on 5.3.1:



Best regards,
Andreas



[2010-02-19 19:24:07] cpuidle at gmx dot de

Same script btw is working in 5.2.6. on same machine.



[2010-02-19 19:16:46] cpuidle at gmx dot de

Description:

Sending Location headers in php 5.3.1 does set return status to 302 but
does not relay the location header to the client app- preventing
redirection from working.

Reproduce code:
---


Expected result:

Should open the other.php page.

Actual result:
--
Nothing. Following output is captured by Firefox- it shows that the
location header is missing:

GET /videodb/test.php HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2)
Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729)
Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Cookie: VDBuserid=1; VDBusername=admin; VDBpassword=368368530;
PHPSESSID=1ka2had3fipg89rkt7o9v6s601
Cache-Control: max-age=0

HTTP/1.1 302 Found
Date: Fri, 19 Feb 2010 19:10:41 GMT
Server: Apache/2.2.11 (Win32) PHP/5.3.1
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 20
Keep-Alive: timeout=5, max=98
Connection: Keep-Alive
Content-Type: text/html; charset=utf-8






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

#51092 [Com]: HTTP redirection broken in 5.3.1

[cpuidle at gmx dot de]

 ID:   51092
 Comment by:   cpuidle at gmx dot de
 Reported By:  cpuidle at gmx dot de
 Status:   Open
 Bug Type: HTTP related
 Operating System: WinXP SP3
 PHP Version:  5.3.1
 New Comment:

Before anybody points me to the HTTP 1.1 spec- this one doesn't
redirect either on 5.3.1:



Best regards,
Andreas


Previous Comments:


[2010-02-19 19:24:07] cpuidle at gmx dot de

Same script btw is working in 5.2.6. on same machine.



[2010-02-19 19:16:46] cpuidle at gmx dot de

Description:

Sending Location headers in php 5.3.1 does set return status to 302 but
does not relay the location header to the client app- preventing
redirection from working.

Reproduce code:
---


Expected result:

Should open the other.php page.

Actual result:
--
Nothing. Following output is captured by Firefox- it shows that the
location header is missing:

GET /videodb/test.php HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2)
Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729)
Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Cookie: VDBuserid=1; VDBusername=admin; VDBpassword=368368530;
PHPSESSID=1ka2had3fipg89rkt7o9v6s601
Cache-Control: max-age=0

HTTP/1.1 302 Found
Date: Fri, 19 Feb 2010 19:10:41 GMT
Server: Apache/2.2.11 (Win32) PHP/5.3.1
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 20
Keep-Alive: timeout=5, max=98
Connection: Keep-Alive
Content-Type: text/html; charset=utf-8






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

#51092 [Com]: HTTP redirection broken in 5.3.1

[cpuidle at gmx dot de]

 ID:   51092
 Comment by:   cpuidle at gmx dot de
 Reported By:  cpuidle at gmx dot de
 Status:   Open
 Bug Type: HTTP related
 Operating System: WinXP SP3
 PHP Version:  5.3.1
 New Comment:

Same script btw is working in 5.2.6. on same machine.


Previous Comments:


[2010-02-19 19:16:46] cpuidle at gmx dot de

Description:

Sending Location headers in php 5.3.1 does set return status to 302 but
does not relay the location header to the client app- preventing
redirection from working.

Reproduce code:
---


Expected result:

Should open the other.php page.

Actual result:
--
Nothing. Following output is captured by Firefox- it shows that the
location header is missing:

GET /videodb/test.php HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2)
Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729)
Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Cookie: VDBuserid=1; VDBusername=admin; VDBpassword=368368530;
PHPSESSID=1ka2had3fipg89rkt7o9v6s601
Cache-Control: max-age=0

HTTP/1.1 302 Found
Date: Fri, 19 Feb 2010 19:10:41 GMT
Server: Apache/2.2.11 (Win32) PHP/5.3.1
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 20
Keep-Alive: timeout=5, max=98
Connection: Keep-Alive
Content-Type: text/html; charset=utf-8






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

#51092 [NEW]: HTTP redirection broken in 5.3.1

[cpuidle at gmx dot de]

From: cpuidle at gmx dot de
Operating system: WinXP SP3
PHP version:  5.3.1
PHP Bug Type: HTTP related
Bug description:  HTTP redirection broken in 5.3.1

Description:

Sending Location headers in php 5.3.1 does set return status to 302 but
does not relay the location header to the client app- preventing
redirection from working.

Reproduce code:
---


Expected result:

Should open the other.php page.

Actual result:
--
Nothing. Following output is captured by Firefox- it shows that the
location header is missing:

GET /videodb/test.php HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2)
Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Cookie: VDBuserid=1; VDBusername=admin; VDBpassword=368368530;
PHPSESSID=1ka2had3fipg89rkt7o9v6s601
Cache-Control: max-age=0

HTTP/1.1 302 Found
Date: Fri, 19 Feb 2010 19:10:41 GMT
Server: Apache/2.2.11 (Win32) PHP/5.3.1
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 20
Keep-Alive: timeout=5, max=98
Connection: Keep-Alive
Content-Type: text/html; charset=utf-8


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

#44639 [Com]: PDO quotes integers in prepared statement

[php at javierparra dot com dot mx]

 ID:   44639
 Comment by:   php at javierparra dot com dot mx
 Reported By:  jgauld at blueyonder dot co dot uk
 Status:   Open
 Bug Type: PDO related
 Operating System: *
 PHP Version:  5.*
 New Comment:

@ nathan dot h at makemeheal dot com
It's because you're using trim()
trim returns a string, try casting it directly as an int:
 (int) trim($_GET['skip'])

In 5.3 still doesn't work using the ? syntax.


Previous Comments:


[2010-02-16 00:05:44] nathan dot h at makemeheal dot com

Has this been fixed?
Interestingly, if you put value directly:
$fetchPictures->bindValue(':skip', 0, PDO::PARAM_INT);
this works.
But if I do 
$fetchPictures->bindValue(':skip', trim($_GET['skip']),
PDO::PARAM_INT);
It doesn't work.

Also, for some reason I don't have issues with this one:
$fetchPictures->bindValue(':max', $max, PDO::PARAM_INT);



[2009-11-19 22:04:21] j...@php.net

Fixed invalid version. Please don't invent your own strings there. It
needs to start always with the major version number..



[2009-10-25 19:29:28] mailmichael at yahoo dot com

Ran into same issue.  Relatively new to php and mysql.  

It seems PDOStatement wants to bind values as strings, even overriding
the explicit data type!  It seems the safest way to use PDOStatements
with integers is to use bindValue, intval() for value and PDO::PARAM_INT
for explicit data type: 

$pdoStmt->bindValue(':limit', intval($limit_value), PDO::PARAM_INT);  

Here is my test code: 

setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_WARNING); 
$pdoStmt = $pdoh->prepare('SELECT 1 LIMIT :limit'); 
$pdoStmt->execute(Array(':limit' => 0)); 
$pdoStmt->bindValue(':limit', 0); 
$pdoStmt->execute(); 
$pdoStmt->bindValue(':limit', '0', PDO::PARAM_INT); 
$pdoStmt->execute(); 
?> 

5.2.6-3ubuntu4.2
( ! ) Warning: PDOStatement::execute() [pdostatement.execute]:
SQLSTATE[42000]: Syntax error or access violation: 1064 You have an
error in your SQL syntax; check the manual that corresponds to your
MySQL server version for the right syntax to use near ''0'' at line 1 in
pdotest.php on line 6

( ! ) Warning: PDOStatement::execute() [pdostatement.execute]:
SQLSTATE[42000]: Syntax error or access violation: 1064 You have an
error in your SQL syntax; check the manual that corresponds to your
MySQL server version for the right syntax to use near ''0'' at line 1 in
pdotest.php on line 8

( ! ) Warning: PDOStatement::execute() [pdostatement.execute]:
SQLSTATE[42000]: Syntax error or access violation: 1064 You have an
error in your SQL syntax; check the manual that corresponds to your
MySQL server version for the right syntax to use near ''0'' at line 1 in
pdotest.php on line 10



[2009-09-24 09:03:55] u...@php.net

Related reports: http://bugs.php.net/bug.php?id=49651 ,
http://bugs.php.net/49381



[2009-09-22 21:18:23] sjo...@php.net

The third parameter to bindValue defaults to PDO::PARAM_STR. This is
different than the original bug reporter said, so it must be changed in
the meantime. Because the datatype is PDO::PARAM_STR, the int is cast to
a string and quoted.

It would make sense to use the PHP type to determine the most logical
PDO::PARAM_* type. See also bug #44597, which is essentially the same
problem but with booleans and execute() instead of bindValue().



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

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

#51087 [Bgs]: spl_autoload doesn't handle classes starting with T_NS_SEPARATOR properly

[andrey at ning dot com]

 ID:   51087
 User updated by:  andrey at ning dot com
 Reported By:  andrey at ning dot com
 Status:   Bogus
 Bug Type: SPL related
 Operating System: any
 PHP Version:  5.3.2RC2
 New Comment:

The issue I'm describing is similar, but different it terms of how
spl_autoload handles the cases I'm describing. 
spl_autoload should NOT try going further in the list of autoload
handlers when the class is already loaded, but the bug is it considers
classes "foo\bar" and "\foo\bar" different and loading "foo\bar" doesn't
make "\foo\bar" to appear as loaded.


Previous Comments:


[2010-02-19 08:31:29] j...@php.net

-Status: Open
+Status: Bogus

Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same. 

Thank you for your interest in PHP.

See bug #50731



[2010-02-19 01:17:35] andrey at ning dot com

Description:

When several autoload handlers are registered with
spl_autoload_register, and the class starting with T_NS_SEPARATOR (\)
AND created using the variable class name is autoloaded, spl_autoload
does not stop at the first successful item and goes thru the whole
stack.


Reproduce code:
---
// Source files:
// foo-bar1.php
namespace foo; class bar1 {}

// foo-bar2.php
namespace foo; class bar2 {}

// foo-baz1.php
namespace foo; class baz1 {}

// foo-baz2.php
namespace foo; class baz2 {}

// test.php
function autoload1($class) {
echo "autoload1($class) is called!\n";
$path = array_filter(explode('\\', $class), 'strlen');
require join('-', $path) . ".php";
}
function autoload2($class) {
echo "autoload2($class) is called!\n";
$path = array_filter(explode('\\', $class), 'strlen');
require join('-', $path) . ".php";
}
spl_autoload_register('autoload1');
spl_autoload_register('autoload2');

$f = new foo\bar1;
$f = new \foo\baz1;
$class = "foo\\bar2"; $f = new $class;
$class = "\\foo\\baz2"; $f = new $class;


Expected result:

autoload1(foo\bar1) is called!
autoload1(foo\baz1) is called!
autoload1(foo\bar2) is called!
autoload1(\foo\baz2) is called!


Actual result:
--
autoload1(foo\bar1) is called!
autoload1(foo\baz1) is called!
autoload1(foo\bar2) is called!
autoload1(\foo\baz2) is called!
autoload2(\foo\baz2) is called!
PHP Fatal error:  Cannot redeclare class foo\baz2






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

#51091 [Opn->Asn]: Persistent PDO Connections Crash

[johannes]

 ID:   51091
 Updated by:   johan...@php.net
 Reported By:  achristianson at yakabod dot com
-Status:   Open
+Status:   Assigned
 Bug Type: Reproducible crash
 Operating System: CentOS 5.4
 PHP Version:  5.3.1
-Assigned To:  
+Assigned To:  dmitry
 New Comment:

Dmitry, can you take a look? - Thanks.


Previous Comments:


[2010-02-19 16:09:24] achristianson at yakabod dot com

I gave it a try with

zend.enable_gc = Off

The segmentation fault no longer occurs



[2010-02-19 15:34:36] ras...@php.net

Looks like a gc issue.  Confirm by setting:

zend.enable_gc = Off

in your php.ini



[2010-02-19 15:29:20] achristianson at yakabod dot com

Description:

* create persistent connection to database; store it to a variable
* create an additional persistent connection to database: store it in 
the same variable
* allocate a bunch of memory
* PHP segfaults

Reproduce code:
---
;dbname=', '',
'',
  array( PDO::ATTR_PERSISTENT => true ));
}

Expected result:

no segmentation fault

Actual result:
--
[New Thread 0xb7f396c0 (LWP 3416)]

Program received signal SIGSEGV, Segmentation fault.
0x0853a746 in zobj_mark_grey (obj=0xb7b8e07c, pz=0xbfd1f0c8) at 
/root/php-5.3.1/Zend/zend_gc.c:383
383 p = Z_OBJPROP_P(pz)->pListHead;
(gdb) bt
#0  0x0853a746 in zobj_mark_grey (obj=0xb7b8e07c, pz=0xbfd1f0c8) at 
/root/php-5.3.1/Zend/zend_gc.c:383
#1  0x0853a81e in gc_mark_roots () at /root/php-
5.3.1/Zend/zend_gc.c:410
#2  0x0853af64 in gc_collect_cycles () at /root/php-
5.3.1/Zend/zend_gc.c:628
#3  0x0853a1a9 in gc_zobj_possible_root (zv=0xa06bac8) at /root/php-
5.3.1/Zend/zend_gc.c:221
#4  0x08539f78 in gc_zval_possible_root (zv=0xa06bac8) at /root/php-
5.3.1/Zend/zend_gc.c:143
#5  0x08508570 in _zval_ptr_dtor (zval_ptr=0xbfd1f1ec, 
__zend_filename=0x88fb070 "/root/php-5.3.1/Zend/zend_vm_execute.h", 
__zend_lineno=28199) at /root/php-5.3.1/Zend/zend_gc.h:183
#6  0x085d7d24 in ZEND_ASSIGN_DIM_SPEC_CV_UNUSED_HANDLER 
(execute_data=0x9cccd20) at /root/php-
5.3.1/Zend/zend_vm_execute.h:28199
#7  0x08543e68 in execute (op_array=0x9d12f70) at /root/php-
5.3.1/Zend/zend_vm_execute.h:104
#8  0x08518b68 in zend_execute_scripts (type=8, retval=0x0, 
file_count=3) at /root/php-5.3.1/Zend/zend.c:1194
#9  0x084aecdb in php_execute_script (primary_file=0xbfd216a4) at 
/root/php-5.3.1/main/main.c:2225
#10 0x085e4fa0 in main (argc=2, argv=0xbfd21804) at /root/php-
5.3.1/sapi/cli/php_cli.c:1190





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

#51091 [Com]: Persistent PDO Connections Crash

[achristianson at yakabod dot com]

 ID:   51091
 Comment by:   achristianson at yakabod dot com
 Reported By:  achristianson at yakabod dot com
 Status:   Open
 Bug Type: Reproducible crash
 Operating System: CentOS 5.4
 PHP Version:  5.3.1
 New Comment:

I gave it a try with

zend.enable_gc = Off

The segmentation fault no longer occurs


Previous Comments:


[2010-02-19 15:34:36] ras...@php.net

Looks like a gc issue.  Confirm by setting:

zend.enable_gc = Off

in your php.ini



[2010-02-19 15:29:20] achristianson at yakabod dot com

Description:

* create persistent connection to database; store it to a variable
* create an additional persistent connection to database: store it in 
the same variable
* allocate a bunch of memory
* PHP segfaults

Reproduce code:
---
;dbname=', '',
'',
  array( PDO::ATTR_PERSISTENT => true ));
}

Expected result:

no segmentation fault

Actual result:
--
[New Thread 0xb7f396c0 (LWP 3416)]

Program received signal SIGSEGV, Segmentation fault.
0x0853a746 in zobj_mark_grey (obj=0xb7b8e07c, pz=0xbfd1f0c8) at 
/root/php-5.3.1/Zend/zend_gc.c:383
383 p = Z_OBJPROP_P(pz)->pListHead;
(gdb) bt
#0  0x0853a746 in zobj_mark_grey (obj=0xb7b8e07c, pz=0xbfd1f0c8) at 
/root/php-5.3.1/Zend/zend_gc.c:383
#1  0x0853a81e in gc_mark_roots () at /root/php-
5.3.1/Zend/zend_gc.c:410
#2  0x0853af64 in gc_collect_cycles () at /root/php-
5.3.1/Zend/zend_gc.c:628
#3  0x0853a1a9 in gc_zobj_possible_root (zv=0xa06bac8) at /root/php-
5.3.1/Zend/zend_gc.c:221
#4  0x08539f78 in gc_zval_possible_root (zv=0xa06bac8) at /root/php-
5.3.1/Zend/zend_gc.c:143
#5  0x08508570 in _zval_ptr_dtor (zval_ptr=0xbfd1f1ec, 
__zend_filename=0x88fb070 "/root/php-5.3.1/Zend/zend_vm_execute.h", 
__zend_lineno=28199) at /root/php-5.3.1/Zend/zend_gc.h:183
#6  0x085d7d24 in ZEND_ASSIGN_DIM_SPEC_CV_UNUSED_HANDLER 
(execute_data=0x9cccd20) at /root/php-
5.3.1/Zend/zend_vm_execute.h:28199
#7  0x08543e68 in execute (op_array=0x9d12f70) at /root/php-
5.3.1/Zend/zend_vm_execute.h:104
#8  0x08518b68 in zend_execute_scripts (type=8, retval=0x0, 
file_count=3) at /root/php-5.3.1/Zend/zend.c:1194
#9  0x084aecdb in php_execute_script (primary_file=0xbfd216a4) at 
/root/php-5.3.1/main/main.c:2225
#10 0x085e4fa0 in main (argc=2, argv=0xbfd21804) at /root/php-
5.3.1/sapi/cli/php_cli.c:1190





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

#51091 [Opn]: Persistent PDO Connections Crash

[rasmus]

 ID:   51091
 Updated by:   ras...@php.net
 Reported By:  achristianson at yakabod dot com
 Status:   Open
 Bug Type: Reproducible crash
 Operating System: CentOS 5.4
 PHP Version:  5.3.1
 New Comment:

Looks like a gc issue.  Confirm by setting:

zend.enable_gc = Off

in your php.ini


Previous Comments:


[2010-02-19 15:29:20] achristianson at yakabod dot com

Description:

* create persistent connection to database; store it to a variable
* create an additional persistent connection to database: store it in 
the same variable
* allocate a bunch of memory
* PHP segfaults

Reproduce code:
---
;dbname=', '',
'',
  array( PDO::ATTR_PERSISTENT => true ));
}

Expected result:

no segmentation fault

Actual result:
--
[New Thread 0xb7f396c0 (LWP 3416)]

Program received signal SIGSEGV, Segmentation fault.
0x0853a746 in zobj_mark_grey (obj=0xb7b8e07c, pz=0xbfd1f0c8) at 
/root/php-5.3.1/Zend/zend_gc.c:383
383 p = Z_OBJPROP_P(pz)->pListHead;
(gdb) bt
#0  0x0853a746 in zobj_mark_grey (obj=0xb7b8e07c, pz=0xbfd1f0c8) at 
/root/php-5.3.1/Zend/zend_gc.c:383
#1  0x0853a81e in gc_mark_roots () at /root/php-
5.3.1/Zend/zend_gc.c:410
#2  0x0853af64 in gc_collect_cycles () at /root/php-
5.3.1/Zend/zend_gc.c:628
#3  0x0853a1a9 in gc_zobj_possible_root (zv=0xa06bac8) at /root/php-
5.3.1/Zend/zend_gc.c:221
#4  0x08539f78 in gc_zval_possible_root (zv=0xa06bac8) at /root/php-
5.3.1/Zend/zend_gc.c:143
#5  0x08508570 in _zval_ptr_dtor (zval_ptr=0xbfd1f1ec, 
__zend_filename=0x88fb070 "/root/php-5.3.1/Zend/zend_vm_execute.h", 
__zend_lineno=28199) at /root/php-5.3.1/Zend/zend_gc.h:183
#6  0x085d7d24 in ZEND_ASSIGN_DIM_SPEC_CV_UNUSED_HANDLER 
(execute_data=0x9cccd20) at /root/php-
5.3.1/Zend/zend_vm_execute.h:28199
#7  0x08543e68 in execute (op_array=0x9d12f70) at /root/php-
5.3.1/Zend/zend_vm_execute.h:104
#8  0x08518b68 in zend_execute_scripts (type=8, retval=0x0, 
file_count=3) at /root/php-5.3.1/Zend/zend.c:1194
#9  0x084aecdb in php_execute_script (primary_file=0xbfd216a4) at 
/root/php-5.3.1/main/main.c:2225
#10 0x085e4fa0 in main (argc=2, argv=0xbfd21804) at /root/php-
5.3.1/sapi/cli/php_cli.c:1190





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

#51091 [NEW]: Persistent PDO Connections Crash

[achristianson at yakabod dot com]

From: achristianson at yakabod dot com
Operating system: CentOS 5.4
PHP version:  5.3.1
PHP Bug Type: Reproducible crash
Bug description:  Persistent PDO Connections Crash

Description:

* create persistent connection to database; store it to a variable
* create an additional persistent connection to database: store it in 
the same variable
* allocate a bunch of memory
* PHP segfaults

Reproduce code:
---
;dbname=', '',
'',
  array( PDO::ATTR_PERSISTENT => true ));
}

Expected result:

no segmentation fault

Actual result:
--
[New Thread 0xb7f396c0 (LWP 3416)]

Program received signal SIGSEGV, Segmentation fault.
0x0853a746 in zobj_mark_grey (obj=0xb7b8e07c, pz=0xbfd1f0c8) at 
/root/php-5.3.1/Zend/zend_gc.c:383
383 p = Z_OBJPROP_P(pz)->pListHead;
(gdb) bt
#0  0x0853a746 in zobj_mark_grey (obj=0xb7b8e07c, pz=0xbfd1f0c8) at 
/root/php-5.3.1/Zend/zend_gc.c:383
#1  0x0853a81e in gc_mark_roots () at /root/php-
5.3.1/Zend/zend_gc.c:410
#2  0x0853af64 in gc_collect_cycles () at /root/php-
5.3.1/Zend/zend_gc.c:628
#3  0x0853a1a9 in gc_zobj_possible_root (zv=0xa06bac8) at /root/php-
5.3.1/Zend/zend_gc.c:221
#4  0x08539f78 in gc_zval_possible_root (zv=0xa06bac8) at /root/php-
5.3.1/Zend/zend_gc.c:143
#5  0x08508570 in _zval_ptr_dtor (zval_ptr=0xbfd1f1ec, 
__zend_filename=0x88fb070 "/root/php-5.3.1/Zend/zend_vm_execute.h", 
__zend_lineno=28199) at /root/php-5.3.1/Zend/zend_gc.h:183
#6  0x085d7d24 in ZEND_ASSIGN_DIM_SPEC_CV_UNUSED_HANDLER 
(execute_data=0x9cccd20) at /root/php-
5.3.1/Zend/zend_vm_execute.h:28199
#7  0x08543e68 in execute (op_array=0x9d12f70) at /root/php-
5.3.1/Zend/zend_vm_execute.h:104
#8  0x08518b68 in zend_execute_scripts (type=8, retval=0x0, 
file_count=3) at /root/php-5.3.1/Zend/zend.c:1194
#9  0x084aecdb in php_execute_script (primary_file=0xbfd216a4) at 
/root/php-5.3.1/main/main.c:2225
#10 0x085e4fa0 in main (argc=2, argv=0xbfd21804) at /root/php-
5.3.1/sapi/cli/php_cli.c:1190

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

#50998 [Opn]: unaligned memory access in hash_tiger.c

[srinatar]

 ID:   50998
 Updated by:   srina...@php.net
 Reported By:  geissert at debian dot org
 Status:   Open
 Bug Type: hash related
 Operating System: linux ia64
 PHP Version:  5.3SVN-2010-02-12
 New Comment:

looks like this is Intel Itanium specific and not reproduced in other 
platforms


Previous Comments:


[2010-02-10 21:06:30] geissert at debian dot org

Failed test: ext/hash/tests/mhash_001.phpt

Output:
MHASH_MD5
ok

MHASH_SHA1
ok

MHASH_HAVAL256
ok

MHASH_HAVAL192
ok

MHASH_HAVAL224
ok

MHASH_HAVAL160
ok

MHASH_RIPEMD160
ok

MHASH_GOST
ok

Bus error (core dumped)



[2010-02-10 19:06:50] geissert at debian dot org

Description:

ext/hash/hash_tiger.c's TigerFinalize makes an unaligned memory access
at:

tiger_compress(context->passes, ((php_hash_uint64 *)
context->buffer), context->state);







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

#50915 [Opn->Asn]: ldap extension with Solaris libldap patched for ldap urls

[srinatar]

 ID:   50915
 Updated by:   srina...@php.net
 Reported By:  strube at physik3 dot gwdg dot de
-Status:   Open
+Status:   Assigned
 Bug Type: Feature/Change Request
 Operating System: Solaris 10
-PHP Version:  5.2.12
+PHP Version:  5.3
-Assigned To:  
+Assigned To:  srinatar
 New Comment:

thanks for the patch. I will find time - after couple of weeks - to do

more testing on this patch and try to port it to 5.3/trunk as well

- Sriram


Previous Comments:


[2010-02-16 08:55:04] j...@php.net

Moved to correct place. ext/ldap works best with OpenLDAP anyway but of
course we can add one more implementation in the future. If someone has
time. And access to such machine to test this.. :)



[2010-02-15 15:15:16] strube at physik3 dot gwdg dot de

Oops, this was not a problem of my patch, I simply forgot to copy the
certificate files to the PHP_PREFIX/ssl of my 5.3.1 test installation!
At least LAM and PLA work just as with 5.2.12. "trunk" will take some
time, I cannot do this now.



[2010-02-15 14:58:06] strube at physik3 dot gwdg dot de

First test show that there are indeed issues with PHP 5.3.1. I found
that neither LAM nor PLA work with SLL, using ldaps://server or
server:636 (but do work without SSL); an error in the call
ldapssl_client_init is indicated, although that part of ldap.c patched
by me is identical for 5.2.12 and 5.3.1 (however, the line numbers of
the second patch hunk must be @@ -330,6 +334,42 @@ for 5.3.1, contrary
to my previous statements).
As we are not be able to upgrade to 5.3.x in the near future because of
compatibility issues with our PHP applications, I am sorry I cannot
invest time do extensive tests presently.



[2010-02-15 12:33:50] paj...@php.net

hi,

Thanks for your work so far.


It is important to understand that 5.2.x is in Maintenance mode. We
don't accept features addition there. 5.3.x accepts only minors and well
tested features additions. trunk is the development tree.

Can you provide a patch against the PHP_5_3 branch and trunk please?
And please test 5.3/trunk as well instead of 5.2 only.



[2010-02-15 11:42:46] strube at physik3 dot gwdg dot de

Well, I prefer our own servers over pastebin.com and put my patch in
ftp://ftp.physik3.gwdg.de/pub/HWS/php_ldap_solaris.patch (also visible
as http://www.physik3.gwdg.de/~strube/soft/php_ldap_solaris.patch)
which will exist at least for a year, probably much longer.
More details: The line numbers are correct for recent versions of PHP
5.2.x and 5.3.x; for 4.4.9, patching works with offset (-1 and -38
lines). Execution has only been tested with php 5.2.x (x = 12 and
slightly less), especially with LAM
(http://www.ldap-account-manager.org/) and PLA
(http://phpldapadmin.sourceforge.net/), both with and without SSL. SASL
has not been tested (so far I have not got it working even without
PHP).
The first hunk of the patch is required for building at all, the second
one, to allow ldap[s] URLs and to use SSL.
Note on SSL usage: this is independent of PHP's configure option
--with-openssl, since the Solaris libldap.so is linked with the
(Mozilla-type) SSL libraries from /usr/lib/mps/ (from Solaris 10 on; in
Solaris 9, ldapssl_client_init is a dummy function). The LDAP server's
CA certificate (or chain) has to be put into PHP_PREFIX/ssl/ (you may
change this path in my patch) in the Mozilla-like form of cert8.db,
key3.db, secmod.db (tools [e.g., certutil] in /usr/sfw/bin/, docs in
http://www.mozilla.org/projects/security/pki/nss/tools/).



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

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

#51079 [Fbk->Opn]: fsockopen will not work on 'localhost'

[tony at marston-home dot demon dot co dot uk]

 ID:   51079
 User updated by:  tony at marston-home dot demon dot co dot uk
 Reported By:  tony at marston-home dot demon dot co dot uk
-Status:   Feedback
+Status:   Open
 Bug Type: Sockets related
 Operating System: Windows XP
 PHP Version:  5.2.12
 New Comment:

I have tried 5.2.13RC2, but it produces the same error. I have not
tried 5.3.2RC2 as I do not have an error with 5.3.0 (which may be
because my copy of 5.3.0 does not have IPv6 support enabled).


Previous Comments:


[2010-02-19 12:51:20] paj...@php.net

-Status: Bogus
+Status: Feedback

Have you tried with 5.2.13RC2 and 5.3.2RC2?



[2010-02-19 10:58:02] tony at marston-home dot demon dot co dot uk

Rasmus, before you post a comment like that I suggest you first make
yourself aware of the facts.
(1) I am not the only one who has reported it, see
http://bugs.php.net/bug.php?id=47437 where the suggested "fix" was to
disable IPv6 support in Windows.
(2) Nobody has ever said that they cannot reproduce the problem.

This problem exists in Windows XP with IPv6 support enabled, and with
PHP 5.2.12 also with IPv6 support enabled.

None of my web browsers (IE, Firefox, Opera, Safari) has a problem with
resolving 'localhost' to 127.0.0.1

gethostbyname('localhost') returns '127.0.0.1' without any problem.

The CURL extension can send requests to 'localhost' without a problem.

I have another Windows XP PC with IPv6 support enabled, running PHP
5.3.0 with IPv6 support disabled, and fsockopen() will accept
'localhost' without falling over.

So why can't fsockopen() in 5.2.12 deal with 'localhost', only
'127.0.0.1'?

Do NOT tell me that this is a Windows XP issue and that I should
disable IPv6 support. IPv4 and IPv6 are designed to run alongside each
other and are NOT mutually exclusive. The only function on my PC that
has a problem with that is fsockopen(), so stop procrastinating and FIX
IT!



[2010-02-18 17:44:10] ras...@php.net

You are going to have to debug it yourself.  Nobody has been able to 
reproduce your problem and you are the only one who has reported it.  
We can't fix something we can't see.



[2010-02-18 11:20:44] tony at marston-home dot demon dot co dot uk

The previous bugs reports have been closed WITHOUT a satisfactory
explanation. It is not good enough to say "disable IPv6 support in your
operating system" as the problem CLEARLY lies within the code for
fsockopen.

If IPv6 support is enabled in the operating system it does NOT mean
that only IPv6 addresses are allowed, it means that both IPv5 and IPv6
addresses are supported.

All of my web browsers (IE, Firefox, Opera, Safari) have no problem in
translating 'localhost' to '127.0.0.1'.

The PHP gethostbyname() function has no problem in translating
'localhost' to '127.0.0.1'.

The PHP cURL extension has no problem in translating 'localhost' to
'127.0.0.1'.

fsockopen() when running in PHP 5.3.0 has no problem in translating
'localhost' to '127.0.0.1'.

So why does fsockopen() in php 5.2.12 have a problem?



[2010-02-18 11:04:43] j...@php.net

-Status: Open
+Status: Bogus

Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same. 

Thank you for your interest in PHP.



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/51079

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

#51090 [Com]: setTime on a DateTime object reapplying DateTime::sub()

[aj at dl10design dot co dot uk]

 ID:   51090
 Comment by:   aj at dl10design dot co dot uk
 Reported By:  aj at dl10design dot co dot uk
 Status:   Open
 Bug Type: Date/time related
 Operating System: Centos 5
 PHP Version:  5.3.1
 New Comment:

Temporary workaround is to add

$datetime->sub(new DateInterval("P0D"));

after

$datetime->sub(new DateInterval("P2D"));


Previous Comments:


[2010-02-19 13:56:13] aj at dl10design dot co dot uk

Description:

When using set time after modifying the date by using sub, the sub is 
re-applied as well.

Reproduce code:
---
date_default_timezone_set('Europe/London');

$datetime = new DateTime('2010-02-19 14:52:10');

$datetime->sub(new DateInterval("P2D"));
// Date should now be 2010-02-17
echo $datetime->format("Y-m-d H:i:s") . "";

$datetime->setTime(15,0,0);
// Date and time should now be 2010-02-17 15:00:00
// BUT it is 2010-02-15 15:00:00
echo $datetime->format("Y-m-d H:i:s");

Expected result:

Only the time should have be changed

Actual result:
--
Day and date are changed.





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

#51090 [NEW]: setTime on a DateTime object reapplying DateTime::sub()

[aj at dl10design dot co dot uk]

From: aj at dl10design dot co dot uk
Operating system: Centos 5
PHP version:  5.3.1
PHP Bug Type: Date/time related
Bug description:  setTime on a DateTime object reapplying DateTime::sub()

Description:

When using set time after modifying the date by using sub, the sub is 
re-applied as well.

Reproduce code:
---
date_default_timezone_set('Europe/London');

$datetime = new DateTime('2010-02-19 14:52:10');

$datetime->sub(new DateInterval("P2D"));
// Date should now be 2010-02-17
echo $datetime->format("Y-m-d H:i:s") . "";

$datetime->setTime(15,0,0);
// Date and time should now be 2010-02-17 15:00:00
// BUT it is 2010-02-15 15:00:00
echo $datetime->format("Y-m-d H:i:s");

Expected result:

Only the time should have be changed

Actual result:
--
Day and date are changed.

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

#51073 [Bgs]: crc32() function result differs on 64-bit Linux platforms and others

[jian at theorchard dot com]

 ID:   51073
 User updated by:  jian at theorchard dot com
 Reported By:  jian at theorchard dot com
 Status:   Bogus
 Bug Type: Feature/Change Request
 Operating System: Linux RHEL 5
 PHP Version:  5.3.1
 New Comment:

As I had previously said, forget it because it's platform related 
issue not PHP's fault.  I was trying to say it would be nice if the 
end user didn't need to do this kind of re-formatting.  It would 
nice the function acts as a black box.  That's all.  Thank you all 
for replying to my post.  And I feel very sorry to have wasted all 
of you time on this stupidity.  At least my boss was very 
understanding what I had to deal with.  Please close this ticket.  
I'm not going to post anything more here.  Thank you.


Previous Comments:


[2010-02-19 13:39:56] ras...@php.net

But, like I said there is nothing to do here.  We have to return the 
exact bits.  Anything we do other than that will cause all sorts of 
chaos and confusion.  So I don't understand what you are asking for,  A

new datatype in PHP for this?  That's not going to happen obviously.



[2010-02-19 13:36:39] paj...@php.net

Not too hard to understand that PHP has no unsigned integer type.



[2010-02-19 13:33:47] jian at theorchard dot com

Did you not read my previous post?  That's the same exactly function I
have already posted.  Yes, it is very stupid to have to do that on the
user's end.



[2010-02-19 05:15:56] ras...@php.net

Why can't you always use a signed checksum if that is what you want?  
crc32 simply returns 32 bits.  You always get the same 32 bits 
regardless of the platform.  If you want to always represent that as a

signed 32-bit integer, then do so.  The fact that some platforms have 
the ability to show those 32 bits without messing up the sign is 
irrelevant.  Just emulate it with something stupidly simple like:

$max32 = 2147483648;
$crc = crc32("884385799717_1_1");
if($crc>$max32-1) {
  $crc = $crc-2*$max32;
}
echo $crc;



[2010-02-19 04:20:00] jian at theorchard dot com

All I was saying is to point out that crc32 function is unable to
return the same result represented in the same way under any different
platforms.

The documentation does say to use sprintf function to format the result
to be an unsigned integer in order to the get same expected result from
all platforms.

In the real world, we actually do need to use signed checksum in some
cases.  So with this shortcoming in mind, crc32 function cannot achieve
a truly signed checksum purpose.



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

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

#51073 [Bgs]: crc32() function result differs on 64-bit Linux platforms and others

[rasmus]

 ID:   51073
 Updated by:   ras...@php.net
 Reported By:  jian at theorchard dot com
 Status:   Bogus
 Bug Type: Feature/Change Request
 Operating System: Linux RHEL 5
 PHP Version:  5.3.1
 New Comment:

But, like I said there is nothing to do here.  We have to return the 
exact bits.  Anything we do other than that will cause all sorts of 
chaos and confusion.  So I don't understand what you are asking for,  A

new datatype in PHP for this?  That's not going to happen obviously.


Previous Comments:


[2010-02-19 13:36:39] paj...@php.net

Not too hard to understand that PHP has no unsigned integer type.



[2010-02-19 13:33:47] jian at theorchard dot com

Did you not read my previous post?  That's the same exactly function I
have already posted.  Yes, it is very stupid to have to do that on the
user's end.



[2010-02-19 05:15:56] ras...@php.net

Why can't you always use a signed checksum if that is what you want?  
crc32 simply returns 32 bits.  You always get the same 32 bits 
regardless of the platform.  If you want to always represent that as a

signed 32-bit integer, then do so.  The fact that some platforms have 
the ability to show those 32 bits without messing up the sign is 
irrelevant.  Just emulate it with something stupidly simple like:

$max32 = 2147483648;
$crc = crc32("884385799717_1_1");
if($crc>$max32-1) {
  $crc = $crc-2*$max32;
}
echo $crc;



[2010-02-19 04:20:00] jian at theorchard dot com

All I was saying is to point out that crc32 function is unable to
return the same result represented in the same way under any different
platforms.

The documentation does say to use sprintf function to format the result
to be an unsigned integer in order to the get same expected result from
all platforms.

In the real world, we actually do need to use signed checksum in some
cases.  So with this shortcoming in mind, crc32 function cannot achieve
a truly signed checksum purpose.



[2010-02-18 08:34:59] ras...@php.net

It does return the correct set of bits.  Anything we do to change what

is currently being returned will seriously confuse everyone and the 
documentation is quite clear on this.



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

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

#51073 [Bgs]: crc32() function result differs on 64-bit Linux platforms and others

[pajoye]

 ID:   51073
 Updated by:   paj...@php.net
 Reported By:  jian at theorchard dot com
 Status:   Bogus
 Bug Type: Feature/Change Request
 Operating System: Linux RHEL 5
 PHP Version:  5.3.1
 New Comment:

Not too hard to understand that PHP has no unsigned integer type.


Previous Comments:


[2010-02-19 13:33:47] jian at theorchard dot com

Did you not read my previous post?  That's the same exactly function I
have already posted.  Yes, it is very stupid to have to do that on the
user's end.



[2010-02-19 05:15:56] ras...@php.net

Why can't you always use a signed checksum if that is what you want?  
crc32 simply returns 32 bits.  You always get the same 32 bits 
regardless of the platform.  If you want to always represent that as a

signed 32-bit integer, then do so.  The fact that some platforms have 
the ability to show those 32 bits without messing up the sign is 
irrelevant.  Just emulate it with something stupidly simple like:

$max32 = 2147483648;
$crc = crc32("884385799717_1_1");
if($crc>$max32-1) {
  $crc = $crc-2*$max32;
}
echo $crc;



[2010-02-19 04:20:00] jian at theorchard dot com

All I was saying is to point out that crc32 function is unable to
return the same result represented in the same way under any different
platforms.

The documentation does say to use sprintf function to format the result
to be an unsigned integer in order to the get same expected result from
all platforms.

In the real world, we actually do need to use signed checksum in some
cases.  So with this shortcoming in mind, crc32 function cannot achieve
a truly signed checksum purpose.



[2010-02-18 08:34:59] ras...@php.net

It does return the correct set of bits.  Anything we do to change what

is currently being returned will seriously confuse everyone and the 
documentation is quite clear on this.



[2010-02-18 08:26:44] jian at theorchard dot com

On a second thought, however, this still poses an issue.  As a
programmer, I shouldn't be worreid about all these reformatting and
work-arounds.  If my function returns me a chicken under development
environment, it shouldn't return me an egg once it's released to the
production environment.  

Even though it's the same value, they should also be represented in the
same way regardless which platform this function is used.

This issue should still be classified as a valid bug in my opinion.



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

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

#51073 [Bgs]: crc32() function result differs on 64-bit Linux platforms and others

[jian at theorchard dot com]

 ID:   51073
 User updated by:  jian at theorchard dot com
 Reported By:  jian at theorchard dot com
 Status:   Bogus
 Bug Type: Feature/Change Request
 Operating System: Linux RHEL 5
 PHP Version:  5.3.1
 New Comment:

Did you not read my previous post?  That's the same exactly function I
have already posted.  Yes, it is very stupid to have to do that on the
user's end.


Previous Comments:


[2010-02-19 05:15:56] ras...@php.net

Why can't you always use a signed checksum if that is what you want?  
crc32 simply returns 32 bits.  You always get the same 32 bits 
regardless of the platform.  If you want to always represent that as a

signed 32-bit integer, then do so.  The fact that some platforms have 
the ability to show those 32 bits without messing up the sign is 
irrelevant.  Just emulate it with something stupidly simple like:

$max32 = 2147483648;
$crc = crc32("884385799717_1_1");
if($crc>$max32-1) {
  $crc = $crc-2*$max32;
}
echo $crc;



[2010-02-19 04:20:00] jian at theorchard dot com

All I was saying is to point out that crc32 function is unable to
return the same result represented in the same way under any different
platforms.

The documentation does say to use sprintf function to format the result
to be an unsigned integer in order to the get same expected result from
all platforms.

In the real world, we actually do need to use signed checksum in some
cases.  So with this shortcoming in mind, crc32 function cannot achieve
a truly signed checksum purpose.



[2010-02-18 08:34:59] ras...@php.net

It does return the correct set of bits.  Anything we do to change what

is currently being returned will seriously confuse everyone and the 
documentation is quite clear on this.



[2010-02-18 08:26:44] jian at theorchard dot com

On a second thought, however, this still poses an issue.  As a
programmer, I shouldn't be worreid about all these reformatting and
work-arounds.  If my function returns me a chicken under development
environment, it shouldn't return me an egg once it's released to the
production environment.  

Even though it's the same value, they should also be represented in the
same way regardless which platform this function is used.

This issue should still be classified as a valid bug in my opinion.



[2010-02-17 22:38:09] jian at theorchard dot com

Thanks Derick.  That was much more helpful.  Unfortunately, I cannot
use unsigned integer as our checksum.  It has to be signed.  I do in
fact have a work around function built to solve this issue.  I was just
wondering whether this will get fixed in the future or not.  Since it's
a platform dependent issue, it most likely won't get fixed I think.

Below is the function I have posted against the crc32 function as a
note.  I hope this can help others out.  Thanks again.

function get_signed_int($in) {
$int_max = pow(2, 31)-1;
if ($in > $int_max){
$out = $in - $int_max * 2 - 2;
}
else {
$out = $in;
}
return $out;
}



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

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

#51079 [Bgs->Fbk]: fsockopen will not work on 'localhost'

[pajoye]

 ID:   51079
 Updated by:   paj...@php.net
 Reported By:  tony at marston-home dot demon dot co dot uk
-Status:   Bogus
+Status:   Feedback
 Bug Type: Sockets related
 Operating System: Windows XP
 PHP Version:  5.2.12
 New Comment:

Have you tried with 5.2.13RC2 and 5.3.2RC2?


Previous Comments:


[2010-02-19 10:58:02] tony at marston-home dot demon dot co dot uk

Rasmus, before you post a comment like that I suggest you first make
yourself aware of the facts.
(1) I am not the only one who has reported it, see
http://bugs.php.net/bug.php?id=47437 where the suggested "fix" was to
disable IPv6 support in Windows.
(2) Nobody has ever said that they cannot reproduce the problem.

This problem exists in Windows XP with IPv6 support enabled, and with
PHP 5.2.12 also with IPv6 support enabled.

None of my web browsers (IE, Firefox, Opera, Safari) has a problem with
resolving 'localhost' to 127.0.0.1

gethostbyname('localhost') returns '127.0.0.1' without any problem.

The CURL extension can send requests to 'localhost' without a problem.

I have another Windows XP PC with IPv6 support enabled, running PHP
5.3.0 with IPv6 support disabled, and fsockopen() will accept
'localhost' without falling over.

So why can't fsockopen() in 5.2.12 deal with 'localhost', only
'127.0.0.1'?

Do NOT tell me that this is a Windows XP issue and that I should
disable IPv6 support. IPv4 and IPv6 are designed to run alongside each
other and are NOT mutually exclusive. The only function on my PC that
has a problem with that is fsockopen(), so stop procrastinating and FIX
IT!



[2010-02-18 17:44:10] ras...@php.net

You are going to have to debug it yourself.  Nobody has been able to 
reproduce your problem and you are the only one who has reported it.  
We can't fix something we can't see.



[2010-02-18 11:20:44] tony at marston-home dot demon dot co dot uk

The previous bugs reports have been closed WITHOUT a satisfactory
explanation. It is not good enough to say "disable IPv6 support in your
operating system" as the problem CLEARLY lies within the code for
fsockopen.

If IPv6 support is enabled in the operating system it does NOT mean
that only IPv6 addresses are allowed, it means that both IPv5 and IPv6
addresses are supported.

All of my web browsers (IE, Firefox, Opera, Safari) have no problem in
translating 'localhost' to '127.0.0.1'.

The PHP gethostbyname() function has no problem in translating
'localhost' to '127.0.0.1'.

The PHP cURL extension has no problem in translating 'localhost' to
'127.0.0.1'.

fsockopen() when running in PHP 5.3.0 has no problem in translating
'localhost' to '127.0.0.1'.

So why does fsockopen() in php 5.2.12 have a problem?



[2010-02-18 11:04:43] j...@php.net

-Status: Open
+Status: Bogus

Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same. 

Thank you for your interest in PHP.



[2010-02-18 10:31:19] tony at marston-home dot demon dot co dot uk

Description:

When are you going to provide a satisfactory answer to bugs
http://bugs.php.net/bug.php?id=50953 and
http://bugs.php.net/bug.php?id=50965? Your only suggestion has been to
disable IPv^ support in the operating system, but this is a total red
herring.

If IPv6 support is enabled in the operating system it does NOT mean
that only IPv6 addresses are allowed, it means that both IPv5 and IPv6
addresses are supported.

All of my web browsers (IE, Firefox, Opera, Safari) have no problem in
translating 'localhost' to '127.0.0.1'.

The PHP gethostbyname() function has no problem in translating
'localhost' to '127.0.0.1'.

The PHP cURL extension has no problem in translating 'localhost' to
'127.0.0.1'.

fsockopen() when running in PHP 5.3.0 has no problem in translating
'localhost' to '127.0.0.1'.

So why does fsockopen() in php 5.2.12 have a problem?




Reproduce code:
---
function connect($host) {
$faultcode   = null;
$faultstring = null;
$conn = fsockopen($host, 80, $faultcode, $faultstring, 20);
if (!$conn) {
echo 'faultcode=' .$faultcode .', faultstring=' .$faultstring
."\n";
} else {
echo "Connected to $host OK\n";
} // if
return $conn;
} // function

$result = connect('localhost');
$result = connect('127.0.0.1');
$result = connect('desktop');
$result = connect('www.tonymarston.net');


Expected result:

I expect to see the message "Connected to  OK" for all values of
host.


Actual result:
--

#51089 [Opn->Fbk]: Serialisationof large numbers in arrays fails

[pajoye]

 ID:   51089
 Updated by:   paj...@php.net
 Reported By:  phpnet4b7e640208df0 at mon-mail dot org
-Status:   Open
+Status:   Feedback
 Bug Type: Math related
 Operating System: Windows Server 2003 R2 Standard
 PHP Version:  5.3.1
 New Comment:

I can't reproduce it (with 5.3.1 or 5.3.2RC2). Can you try again with
5.3.2RC2? (http://windows.php.net/qa/)


Previous Comments:


[2010-02-19 10:26:13] phpnet4b7e640208df0 at mon-mail dot org

Description:

Unserialisation of serialised arrays containing large numbers fails and
unserialize returns FALSE. 
The issue appears to be in serialized() since unserialising an array
serialised by an older version of PHP works as expected (as shown in
reproduce code).
No error is reported (as expected with unserialize()) and no crash.

Reproduce code:
---


Expected result:

Serialised:
a:2:{s:7:"anumber";d:212133254400;s:13:"anothernumber";d:212164790400;}
Unserialised:Array
(
[anumber] => 212133254400
[anothernumber] => 212164790400
)
Error: no
Old style: Array
(
[anumber] => 212133254400
[anothernumber] => 212164790400
)



Actual result:
--
Serialised:
a:2:{s:7:"anumber";d:2121332543:0;s:13:"anothernumber";d:2121647903:0;}
Unserialised: 
Error: yes
Old style: Array
(
[anumber] => 212133254400
[anothernumber] => 212164790400
)







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

#51074 [Com]: Cannot access the extension base

[anusha dot srs at gmail dot com]

 ID:   51074
 Comment by:   anusha dot srs at gmail dot com
 Reported By:  anusha dot srs at gmail dot com
 Status:   Open
 Bug Type: SOAP related
 Operating System: Windows
 PHP Version:  5.2.12
 New Comment:

IS java client the only option since php seems not capable of acheiving
the requirement?


Previous Comments:


[2010-02-17 19:42:49] anusha dot srs at gmail dot com

Description:

I am unable to call the wsdl function from the php. The wsdl has the
interface concept pasting the snippets. Please help.
my wsdl snippet:


















.
.
.
.
   
Log into the Web Services
  

  

  


.
.
.
.







-

What i understood with this wsdl is that the login operation takes an
in parameter of credential object, how can i acheive the same in php.,..
any suggestions? 


Reproduce code:
---
I am unable to call the wsdl function from the php. The wsdl has the
interface concept pasting the snippets. Please help.
my wsdl snippet:


















.
   
Log into the Web Services
  

  

  


.













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

#51079 [Bgs]: fsockopen will not work on 'localhost'

[tony at marston-home dot demon dot co dot uk]

 ID:   51079
 User updated by:  tony at marston-home dot demon dot co dot uk
 Reported By:  tony at marston-home dot demon dot co dot uk
 Status:   Bogus
 Bug Type: Sockets related
 Operating System: Windows XP
 PHP Version:  5.2.12
 New Comment:

Rasmus, before you post a comment like that I suggest you first make
yourself aware of the facts.
(1) I am not the only one who has reported it, see
http://bugs.php.net/bug.php?id=47437 where the suggested "fix" was to
disable IPv6 support in Windows.
(2) Nobody has ever said that they cannot reproduce the problem.

This problem exists in Windows XP with IPv6 support enabled, and with
PHP 5.2.12 also with IPv6 support enabled.

None of my web browsers (IE, Firefox, Opera, Safari) has a problem with
resolving 'localhost' to 127.0.0.1

gethostbyname('localhost') returns '127.0.0.1' without any problem.

The CURL extension can send requests to 'localhost' without a problem.

I have another Windows XP PC with IPv6 support enabled, running PHP
5.3.0 with IPv6 support disabled, and fsockopen() will accept
'localhost' without falling over.

So why can't fsockopen() in 5.2.12 deal with 'localhost', only
'127.0.0.1'?

Do NOT tell me that this is a Windows XP issue and that I should
disable IPv6 support. IPv4 and IPv6 are designed to run alongside each
other and are NOT mutually exclusive. The only function on my PC that
has a problem with that is fsockopen(), so stop procrastinating and FIX
IT!


Previous Comments:


[2010-02-18 17:44:10] ras...@php.net

You are going to have to debug it yourself.  Nobody has been able to 
reproduce your problem and you are the only one who has reported it.  
We can't fix something we can't see.



[2010-02-18 11:20:44] tony at marston-home dot demon dot co dot uk

The previous bugs reports have been closed WITHOUT a satisfactory
explanation. It is not good enough to say "disable IPv6 support in your
operating system" as the problem CLEARLY lies within the code for
fsockopen.

If IPv6 support is enabled in the operating system it does NOT mean
that only IPv6 addresses are allowed, it means that both IPv5 and IPv6
addresses are supported.

All of my web browsers (IE, Firefox, Opera, Safari) have no problem in
translating 'localhost' to '127.0.0.1'.

The PHP gethostbyname() function has no problem in translating
'localhost' to '127.0.0.1'.

The PHP cURL extension has no problem in translating 'localhost' to
'127.0.0.1'.

fsockopen() when running in PHP 5.3.0 has no problem in translating
'localhost' to '127.0.0.1'.

So why does fsockopen() in php 5.2.12 have a problem?



[2010-02-18 11:04:43] j...@php.net

-Status: Open
+Status: Bogus

Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same. 

Thank you for your interest in PHP.



[2010-02-18 10:31:19] tony at marston-home dot demon dot co dot uk

Description:

When are you going to provide a satisfactory answer to bugs
http://bugs.php.net/bug.php?id=50953 and
http://bugs.php.net/bug.php?id=50965? Your only suggestion has been to
disable IPv^ support in the operating system, but this is a total red
herring.

If IPv6 support is enabled in the operating system it does NOT mean
that only IPv6 addresses are allowed, it means that both IPv5 and IPv6
addresses are supported.

All of my web browsers (IE, Firefox, Opera, Safari) have no problem in
translating 'localhost' to '127.0.0.1'.

The PHP gethostbyname() function has no problem in translating
'localhost' to '127.0.0.1'.

The PHP cURL extension has no problem in translating 'localhost' to
'127.0.0.1'.

fsockopen() when running in PHP 5.3.0 has no problem in translating
'localhost' to '127.0.0.1'.

So why does fsockopen() in php 5.2.12 have a problem?




Reproduce code:
---
function connect($host) {
$faultcode   = null;
$faultstring = null;
$conn = fsockopen($host, 80, $faultcode, $faultstring, 20);
if (!$conn) {
echo 'faultcode=' .$faultcode .', faultstring=' .$faultstring
."\n";
} else {
echo "Connected to $host OK\n";
} // if
return $conn;
} // function

$result = connect('localhost');
$result = connect('127.0.0.1');
$result = connect('desktop');
$result = connect('www.tonymarston.net');


Expected result:

I expect to see the message "Connected to  OK" for all values of
host.


Actual result:
--
Warning:  fsockopen(): unable to connect to localhost:80
faultcode=10060, faultstring=A connection attempt failed because the
connected party did not properly respond after a period of 

#51089 [NEW]: Serialisationof large numbers in arrays fails

[phpnet4b7e640208df0 at mon-mail dot org]

From: phpnet4b7e640208df0 at mon-mail dot org
Operating system: Windows Server 2003 R2 Standard
PHP version:  5.3.1
PHP Bug Type: Math related
Bug description:  Serialisationof large numbers in arrays fails

Description:

Unserialisation of serialised arrays containing large numbers fails and
unserialize returns FALSE. 
The issue appears to be in serialized() since unserialising an array
serialised by an older version of PHP works as expected (as shown in
reproduce code).
No error is reported (as expected with unserialize()) and no crash.

Reproduce code:
---


Expected result:

Serialised:
a:2:{s:7:"anumber";d:212133254400;s:13:"anothernumber";d:212164790400;}
Unserialised:Array
(
[anumber] => 212133254400
[anothernumber] => 212164790400
)
Error: no
Old style: Array
(
[anumber] => 212133254400
[anothernumber] => 212164790400
)



Actual result:
--
Serialised:
a:2:{s:7:"anumber";d:2121332543:0;s:13:"anothernumber";d:2121647903:0;}
Unserialised: 
Error: yes
Old style: Array
(
[anumber] => 212133254400
[anothernumber] => 212164790400
)



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

#51072 [Com]: filter_var with FILTER_VALIDATE_EMAIL accepts incorrect emails

[schicker03 at gmail dot com]

 ID:   51072
 Comment by:   schicker03 at gmail dot com
 Reported By:  schicker03 at gmail dot com
 Status:   Feedback
 Bug Type: Unknown/Other Function
 Operating System: Linux
 PHP Version:  5.2.12
 New Comment:

Ahh Ok,

we do have an etch debian with PHP 5.2.0 on our testsystem.
I checked the live system with lenny2 and PHP 5.2.6.

The result with 5.2.6 is as I expected it.
Boolean false is returned.

Thanks
schicker03


Previous Comments:


[2010-02-17 17:33:49] der...@php.net

Please try using this snapshot:

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

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



[2010-02-17 17:32:38] schicker03 at gmail dot com

Description:

An incorrect email is returned as correct from filter_var with the
FILTER_VALIDATE_EMAIL option.

The php version is 
"PHP Version 5.2.0-8+etch10"

that has not been in the dropdown above so i added it here.





Reproduce code:
---
---
>From manual page: function.filter-var
---




Expected result:

The variable $abc should be the boolean value false.


Actual result:
--
The variable $abc contains the email from $email
"doesnotmat...@-online.de".





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

#51086 [Opn]: will not work with libdb4.8

[seanius at debian dot org]

 ID:   51086
 User updated by:  seanius at debian dot org
-Summary:  will not build/work with libdb4.8
 Reported By:  seanius at debian dot org
 Status:   Open
 Bug Type: DBM/DBA related
-Operating System: Debian (and others)
+Operating System: *
-PHP Version:  5.3.1
+PHP Version:  5.3, 6 (2010-02-19
 New Comment:

heh, seems we're stepping on each other's toes now.  i'll set the stuff
back that i just clobbered, and promise to be quiet for a few hours :)

actually it won't build correctly against db4.8.  i had to modify the
snapshot to link against db4.8, as otherwise you see
http://bugs.php.net/bug.php?id=51062 , though apparently that's a bogus
issue, hrm... :)


Previous Comments:


[2010-02-19 09:00:54] seanius at debian dot org

-Summary: will not work with libdb4.8
+Summary: will not build/work with libdb4.8
-Operating System: *
+Operating System: Debian (and others)
-PHP Version: 5.3, 6 (2010-02-19)
+PHP Version: 5.3.1

sorry for all the noise, when trying the latest snapshot it apparently
unpacked on top of a previous snapshot in which i had been investigating
the issue.  the tests fail in the new snapshot with more than just the
NOTICE error (i had been playing with the open flags as mentioned
previously).  the actual failure  diff looks like:

TEST 1/25 [ext/dba/tests/bug36436.phpt]
DIFF
001+ Notice: dba_popen(): fop_read_meta:
/home/sean/Download/php5.3-201002190730/ext/dba/tests/test0.dbm:
unexpected file type or format in
/home/sean/Download/php5.3-201002190730/ext/dba/tests/bug36436.php on
line 6
002+ 
003+ Notice: dba_popen():
/home/sean/Download/php5.3-201002190730/ext/dba/tests/test0.dbm: Invalid
type 5 specified in
/home/sean/Download/php5.3-201002190730/ext/dba/tests/bug36436.php on
line 6
004+ 
005+ Warning:
dba_popen(/home/sean/Download/php5.3-201002190730/ext/dba/tests/test0.dbm,c):
Driver initialization failed for handler: db4: Invalid argument in
/home/sean/Download/php5.3-201002190730/ext/dba/tests/bug36436.php on
line 6
001- resource(%d) of type (dba persistent)
002- string(3) "XYZ"
003- string(1) "X"
004- string(1) "Y"
005- ===DONE===



[2010-02-19 08:45:00] j...@php.net

-Summary: will not build/work with libdb4.8
+Summary: will not work with libdb4.8
-Operating System: Debian (and others)
+Operating System: *
-PHP Version: 5.3.1
+PHP Version: 5.3, 6 (2010-02-19)

At least it builds now. :)



[2010-02-19 08:43:12] seanius at debian dot org

oops, looks like there was a little race there.  yes i can see the
behavior in the snapshot too:

rangda[/home/sean/Download/php5.3-201002160730] ./run-tests.php -p
./sapi/cli/php --show-diff ext/dba/tests/bug36436.phpt

=
PHP : ./sapi/cli/php 
PHP_SAPI: cli
PHP_VERSION : 5.3.3-dev
ZEND_VERSION: 2.3.0
PHP_OS  : Linux - Linux rangda 2.6.32-trunk-amd64 #1 SMP Sun Jan 10
22:40:40 UTC 2010 x86_64
INI actual  : /home/sean/Download/php5.3-201002160730
More .INIs  :  
CWD : /home/sean/Download/php5.3-201002160730
Extra dirs  : 
VALGRIND: Not used
=
Running selected tests.
TEST 1/1 [ext/dba/tests/bug36436.phpt]
DIFF
001+ Notice: dba_popen(): fop_read_meta:
/home/sean/Download/php5.3-201002160730/ext/dba/tests/test0.dbm:
unexpected file type or format in
/home/sean/Download/php5.3-201002160730/ext/dba/tests/bug36436.php on
line 6
DONE
FAIL Bug #36436 (DBA problem with Berkeley DB4)
[ext/dba/tests/bug36436.phpt] 
=
Number of tests :1 1
Tests skipped   :0 (  0.0%) 
Tests warned:0 (  0.0%) (  0.0%)
Tests failed:1 (100.0%) (100.0%)
Expected fail   :0 (  0.0%) (  0.0%)
Tests passed:0 (  0.0%) (  0.0%)
-
Time taken  :0 seconds
=

=
FAILED TEST SUMMARY
-
Bug #36436 (DBA problem with Berkeley DB4)
[ext/dba/tests/bug36436.phpt]
=



[2010-02-19 08:36:51] seanius at debian dot org

-Status: Feedback
+Status: Open

and i've now asked in the bdb forums what they think:

http://forums.oracle.com/forums/thread.jspa?threadID=1031805&stqc=true



[2010-02-19 08:32:31] j...@php.net

-Status

#51086 [Opn]: will not build/work with libdb4.8

[seanius at debian dot org]

 ID:   51086
 User updated by:  seanius at debian dot org
-Summary:  will not work with libdb4.8
 Reported By:  seanius at debian dot org
 Status:   Open
 Bug Type: DBM/DBA related
-Operating System: *
+Operating System: Debian (and others)
-PHP Version:  5.3, 6 (2010-02-19)
+PHP Version:  5.3.1
 New Comment:

sorry for all the noise, when trying the latest snapshot it apparently
unpacked on top of a previous snapshot in which i had been investigating
the issue.  the tests fail in the new snapshot with more than just the
NOTICE error (i had been playing with the open flags as mentioned
previously).  the actual failure  diff looks like:

TEST 1/25 [ext/dba/tests/bug36436.phpt]
DIFF
001+ Notice: dba_popen(): fop_read_meta:
/home/sean/Download/php5.3-201002190730/ext/dba/tests/test0.dbm:
unexpected file type or format in
/home/sean/Download/php5.3-201002190730/ext/dba/tests/bug36436.php on
line 6
002+ 
003+ Notice: dba_popen():
/home/sean/Download/php5.3-201002190730/ext/dba/tests/test0.dbm: Invalid
type 5 specified in
/home/sean/Download/php5.3-201002190730/ext/dba/tests/bug36436.php on
line 6
004+ 
005+ Warning:
dba_popen(/home/sean/Download/php5.3-201002190730/ext/dba/tests/test0.dbm,c):
Driver initialization failed for handler: db4: Invalid argument in
/home/sean/Download/php5.3-201002190730/ext/dba/tests/bug36436.php on
line 6
001- resource(%d) of type (dba persistent)
002- string(3) "XYZ"
003- string(1) "X"
004- string(1) "Y"
005- ===DONE===


Previous Comments:


[2010-02-19 08:45:00] j...@php.net

-Summary: will not build/work with libdb4.8
+Summary: will not work with libdb4.8
-Operating System: Debian (and others)
+Operating System: *
-PHP Version: 5.3.1
+PHP Version: 5.3, 6 (2010-02-19)

At least it builds now. :)



[2010-02-19 08:43:12] seanius at debian dot org

oops, looks like there was a little race there.  yes i can see the
behavior in the snapshot too:

rangda[/home/sean/Download/php5.3-201002160730] ./run-tests.php -p
./sapi/cli/php --show-diff ext/dba/tests/bug36436.phpt

=
PHP : ./sapi/cli/php 
PHP_SAPI: cli
PHP_VERSION : 5.3.3-dev
ZEND_VERSION: 2.3.0
PHP_OS  : Linux - Linux rangda 2.6.32-trunk-amd64 #1 SMP Sun Jan 10
22:40:40 UTC 2010 x86_64
INI actual  : /home/sean/Download/php5.3-201002160730
More .INIs  :  
CWD : /home/sean/Download/php5.3-201002160730
Extra dirs  : 
VALGRIND: Not used
=
Running selected tests.
TEST 1/1 [ext/dba/tests/bug36436.phpt]
DIFF
001+ Notice: dba_popen(): fop_read_meta:
/home/sean/Download/php5.3-201002160730/ext/dba/tests/test0.dbm:
unexpected file type or format in
/home/sean/Download/php5.3-201002160730/ext/dba/tests/bug36436.php on
line 6
DONE
FAIL Bug #36436 (DBA problem with Berkeley DB4)
[ext/dba/tests/bug36436.phpt] 
=
Number of tests :1 1
Tests skipped   :0 (  0.0%) 
Tests warned:0 (  0.0%) (  0.0%)
Tests failed:1 (100.0%) (100.0%)
Expected fail   :0 (  0.0%) (  0.0%)
Tests passed:0 (  0.0%) (  0.0%)
-
Time taken  :0 seconds
=

=
FAILED TEST SUMMARY
-
Bug #36436 (DBA problem with Berkeley DB4)
[ext/dba/tests/bug36436.phpt]
=



[2010-02-19 08:36:51] seanius at debian dot org

-Status: Feedback
+Status: Open

and i've now asked in the bdb forums what they think:

http://forums.oracle.com/forums/thread.jspa?threadID=1031805&stqc=true



[2010-02-19 08:32:31] j...@php.net

-Status: Open
+Status: Feedback

Please try using this snapshot:

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

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



[2010-02-18 23:46:46] seanius at debian dot org

a little more info:  afaict the file is being created with zero size
via some stream functions in dba.c.  when db->open() is called with
DB_CREATE|DB_TRUNCATE libdb4.8 tries to read some metadata from the
existing file and fails horribly.  i tried playing around with the flags
(passing only DB_TRUNCATE does not work, passing only DB_CREATE seems to
work but still produces the error message).

---

#51062 [Bgs]: test failures in ext/dba

[seanius at debian dot org]

 ID:   51062
 User updated by:  seanius at debian dot org
 Reported By:  seanius at debian dot org
 Status:   Bogus
 Bug Type: DBM/DBA related
 Operating System: Debian
 PHP Version:  5.3.1
 New Comment:

actually it's fairly common (at least on debian-derived systems,
couldn't speak for others) to have multiple versions of libdb installed.
 The problem is that the code that does the testing of headers will
match against a generic "db.h" and then will happily link against any
other version of libdb that it finds (and it doesn't seem to be
searching includes/libs in the same order).  i'd argue that the
configure detection ought to be a bit more thorough in this regard but
won't press the point.


Previous Comments:


[2010-02-19 08:46:22] j...@php.net

-Status: Open
+Status: Bogus

No need for several reports on basically same issue, and regarding the
header issues: That's nothing we can or will do about. If you mess your
system with multiple libs and headers, that's your problem.



[2010-02-17 22:40:04] seanius at debian dot org

some more investigation reveals that the problem was caused by having
db4.8 headers alongside db4.6 and db4.8 runtime libraries (i.e. having
installed libdb4.6, libdb4.8, and libdv-dev (which is 4.8 in latest
debian/ubuntu)).  the build scripts find the the headers from the db4.8
package, and the 4.6 libraries since there is no code for testing for
versions > 4.6.  strangely enough it's able to build/link.

having the libdb4.6 headers installed instead of the 4.8 headers
removes the problem and the tests pass, but i would argue that this is
still a bug.  namely:

 * php doesn't support building against db4.8 (i could report a
seperate bug about this if it's better)
 * php wrongly builds against headers for one version of libdb and
links against another.



[2010-02-16 21:52:06] seanius at debian dot org

Description:

Tested against the debian 5.3.1 packages as well as a recent 5.3
snapshot.  fails on a variety of BE/LE and 32/64bit archs.  note that
the failure is different from the snapshot (Segfaults in some cases) and
from 5.3.1 (various warnings about invalid parameters).  i don't want to
flood the description so i'll only include the 5.3 snapshot output
here.

=
PHP : ./sapi/cli/php 
PHP_SAPI: cli
PHP_VERSION : 5.3.3-dev
ZEND_VERSION: 2.3.0
PHP_OS  : Linux - Linux rangda 2.6.32-trunk-amd64 #1 SMP Sun Jan 10
22:40:40 UTC 2010 x86_64
INI actual  : /home/sean/Download/php5.3-201002160730
More .INIs  :  
CWD : /home/sean/Download/php5.3-201002160730
Extra dirs  : 
VALGRIND: Not used
=
Running selected tests.
TEST 1/25 [ext/dba/tests/bug36436.phpt]
DIFF
001+ DB->sync: method not permitted before handle's open method
002+ Segmentation fault
001- resource(%d) of type (dba persistent)
002- string(3) "XYZ"
003- string(1) "X"
004- string(1) "Y"
005- ===DONE===
DONE
FAIL Bug #36436 (DBA problem with Berkeley DB4)
[ext/dba/tests/bug36436.phpt] 
TEST 2/25 [ext/dba/tests/bug48240.phpt]
DIFF
001+ DB->sync: method not permitted before handle's open method
002- ===DONE===
003+ Segmentation fault
DONE
FAIL Bug #48240 (DBA Segmentation fault dba_nextkey)
[ext/dba/tests/bug48240.phpt] 
TEST 3/25 [ext/dba/tests/bug49125.phpt]
DIFF
001+ DB->sync: method not permitted before handle's open method
001- bool(true)
002+ Segmentation fault
DONE
FAIL Bug #49125 (Error in dba_exists C code)
[ext/dba/tests/bug49125.phpt] 
PASS DBA File Creation Test [ext/dba/tests/dba001.phpt] 
PASS DBA Insert/Fetch Test [ext/dba/tests/dba002.phpt] 
PASS DBA Insert/Replace/Fetch Test [ext/dba/tests/dba003.phpt] 
PASS DBA Multiple Insert/Fetch Test [ext/dba/tests/dba004.phpt] 
PASS DBA FirstKey/NextKey Loop Test With 5 Items
[ext/dba/tests/dba005.phpt] 
PASS DBA FirstKey/NextKey with 2 deletes [ext/dba/tests/dba006.phpt] 
PASS DBA Multiple File Creation Test [ext/dba/tests/dba007.phpt] 
PASS DBA magic_quotes_runtime Test [ext/dba/tests/dba008.phpt] 
PASS DBA dba_popen Test [ext/dba/tests/dba009.phpt] 
PASS DBA CDB handler test [ext/dba/tests/dba_cdb.phpt] 
PASS DBA CDB_MAKE handler test [ext/dba/tests/dba_cdb_make.phpt] 
PASS DBA CDB handler test (read only) [ext/dba/tests/dba_cdb_read.phpt]

SKIP DBA DB1 handler test [ext/dba/tests/dba_db1.phpt] reason: DB1
handler not available
SKIP DBA DB2 handler test [ext/dba/tests/dba_db2.phpt] reason: DB2
handler not available
SKIP DBA DB3 handler test [ext/dba/tests/dba_db3.phpt] reason: DB3
handler not available
TEST 19/25 [ext/dba/tests/dba_db4.phpt]
DIFF==

#51062 [Opn->Bgs]: test failures in ext/dba

[jani]

 ID:   51062
 Updated by:   j...@php.net
 Reported By:  seanius at debian dot org
-Status:   Open
+Status:   Bogus
 Bug Type: DBM/DBA related
 Operating System: Debian
 PHP Version:  5.3.1
 New Comment:

No need for several reports on basically same issue, and regarding the
header issues: That's nothing we can or will do about. If you mess your
system with multiple libs and headers, that's your problem.


Previous Comments:


[2010-02-17 22:40:04] seanius at debian dot org

some more investigation reveals that the problem was caused by having
db4.8 headers alongside db4.6 and db4.8 runtime libraries (i.e. having
installed libdb4.6, libdb4.8, and libdv-dev (which is 4.8 in latest
debian/ubuntu)).  the build scripts find the the headers from the db4.8
package, and the 4.6 libraries since there is no code for testing for
versions > 4.6.  strangely enough it's able to build/link.

having the libdb4.6 headers installed instead of the 4.8 headers
removes the problem and the tests pass, but i would argue that this is
still a bug.  namely:

 * php doesn't support building against db4.8 (i could report a
seperate bug about this if it's better)
 * php wrongly builds against headers for one version of libdb and
links against another.



[2010-02-16 21:52:06] seanius at debian dot org

Description:

Tested against the debian 5.3.1 packages as well as a recent 5.3
snapshot.  fails on a variety of BE/LE and 32/64bit archs.  note that
the failure is different from the snapshot (Segfaults in some cases) and
from 5.3.1 (various warnings about invalid parameters).  i don't want to
flood the description so i'll only include the 5.3 snapshot output
here.

=
PHP : ./sapi/cli/php 
PHP_SAPI: cli
PHP_VERSION : 5.3.3-dev
ZEND_VERSION: 2.3.0
PHP_OS  : Linux - Linux rangda 2.6.32-trunk-amd64 #1 SMP Sun Jan 10
22:40:40 UTC 2010 x86_64
INI actual  : /home/sean/Download/php5.3-201002160730
More .INIs  :  
CWD : /home/sean/Download/php5.3-201002160730
Extra dirs  : 
VALGRIND: Not used
=
Running selected tests.
TEST 1/25 [ext/dba/tests/bug36436.phpt]
DIFF
001+ DB->sync: method not permitted before handle's open method
002+ Segmentation fault
001- resource(%d) of type (dba persistent)
002- string(3) "XYZ"
003- string(1) "X"
004- string(1) "Y"
005- ===DONE===
DONE
FAIL Bug #36436 (DBA problem with Berkeley DB4)
[ext/dba/tests/bug36436.phpt] 
TEST 2/25 [ext/dba/tests/bug48240.phpt]
DIFF
001+ DB->sync: method not permitted before handle's open method
002- ===DONE===
003+ Segmentation fault
DONE
FAIL Bug #48240 (DBA Segmentation fault dba_nextkey)
[ext/dba/tests/bug48240.phpt] 
TEST 3/25 [ext/dba/tests/bug49125.phpt]
DIFF
001+ DB->sync: method not permitted before handle's open method
001- bool(true)
002+ Segmentation fault
DONE
FAIL Bug #49125 (Error in dba_exists C code)
[ext/dba/tests/bug49125.phpt] 
PASS DBA File Creation Test [ext/dba/tests/dba001.phpt] 
PASS DBA Insert/Fetch Test [ext/dba/tests/dba002.phpt] 
PASS DBA Insert/Replace/Fetch Test [ext/dba/tests/dba003.phpt] 
PASS DBA Multiple Insert/Fetch Test [ext/dba/tests/dba004.phpt] 
PASS DBA FirstKey/NextKey Loop Test With 5 Items
[ext/dba/tests/dba005.phpt] 
PASS DBA FirstKey/NextKey with 2 deletes [ext/dba/tests/dba006.phpt] 
PASS DBA Multiple File Creation Test [ext/dba/tests/dba007.phpt] 
PASS DBA magic_quotes_runtime Test [ext/dba/tests/dba008.phpt] 
PASS DBA dba_popen Test [ext/dba/tests/dba009.phpt] 
PASS DBA CDB handler test [ext/dba/tests/dba_cdb.phpt] 
PASS DBA CDB_MAKE handler test [ext/dba/tests/dba_cdb_make.phpt] 
PASS DBA CDB handler test (read only) [ext/dba/tests/dba_cdb_read.phpt]

SKIP DBA DB1 handler test [ext/dba/tests/dba_db1.phpt] reason: DB1
handler not available
SKIP DBA DB2 handler test [ext/dba/tests/dba_db2.phpt] reason: DB2
handler not available
SKIP DBA DB3 handler test [ext/dba/tests/dba_db3.phpt] reason: DB3
handler not available
TEST 19/25 [ext/dba/tests/dba_db4.phpt]
DIFF
002+ DB->sync: method not permitted before handle's open method
003+ DB->get: method not permitted before handle's open method
004+ DB->get: method not permitted before handle's open method
005+ DB->fd: method not permitted before handle's open method
006+ 0Segmentation fault
002- 3NYNYY
003- Content String 2
004- Content 2 replaced
005- Read during write: not allowed
006- Content 2 replaced 2nd time
007- The 6th value
008- array(3) {
009-   ["key number 6"]=>
010-   string(13) "The 6th value"
011-   ["key2"]=>
012-   string(27) "Content 2 replaced 2nd time"
013-   ["key5"]=>
014-   string(23) "The last content st

#51086 [Opn]: will not work with libdb4.8

[jani]

 ID:   51086
 Updated by:   j...@php.net
-Summary:  will not build/work with libdb4.8
 Reported By:  seanius at debian dot org
 Status:   Open
 Bug Type: DBM/DBA related
-Operating System: Debian (and others)
+Operating System: *
-PHP Version:  5.3.1
+PHP Version:  5.3, 6 (2010-02-19)
 New Comment:

At least it builds now. :)


Previous Comments:


[2010-02-19 08:43:12] seanius at debian dot org

oops, looks like there was a little race there.  yes i can see the
behavior in the snapshot too:

rangda[/home/sean/Download/php5.3-201002160730] ./run-tests.php -p
./sapi/cli/php --show-diff ext/dba/tests/bug36436.phpt

=
PHP : ./sapi/cli/php 
PHP_SAPI: cli
PHP_VERSION : 5.3.3-dev
ZEND_VERSION: 2.3.0
PHP_OS  : Linux - Linux rangda 2.6.32-trunk-amd64 #1 SMP Sun Jan 10
22:40:40 UTC 2010 x86_64
INI actual  : /home/sean/Download/php5.3-201002160730
More .INIs  :  
CWD : /home/sean/Download/php5.3-201002160730
Extra dirs  : 
VALGRIND: Not used
=
Running selected tests.
TEST 1/1 [ext/dba/tests/bug36436.phpt]
DIFF
001+ Notice: dba_popen(): fop_read_meta:
/home/sean/Download/php5.3-201002160730/ext/dba/tests/test0.dbm:
unexpected file type or format in
/home/sean/Download/php5.3-201002160730/ext/dba/tests/bug36436.php on
line 6
DONE
FAIL Bug #36436 (DBA problem with Berkeley DB4)
[ext/dba/tests/bug36436.phpt] 
=
Number of tests :1 1
Tests skipped   :0 (  0.0%) 
Tests warned:0 (  0.0%) (  0.0%)
Tests failed:1 (100.0%) (100.0%)
Expected fail   :0 (  0.0%) (  0.0%)
Tests passed:0 (  0.0%) (  0.0%)
-
Time taken  :0 seconds
=

=
FAILED TEST SUMMARY
-
Bug #36436 (DBA problem with Berkeley DB4)
[ext/dba/tests/bug36436.phpt]
=



[2010-02-19 08:36:51] seanius at debian dot org

-Status: Feedback
+Status: Open

and i've now asked in the bdb forums what they think:

http://forums.oracle.com/forums/thread.jspa?threadID=1031805&stqc=true



[2010-02-19 08:32:31] j...@php.net

-Status: Open
+Status: Feedback

Please try using this snapshot:

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

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



[2010-02-18 23:46:46] seanius at debian dot org

a little more info:  afaict the file is being created with zero size
via some stream functions in dba.c.  when db->open() is called with
DB_CREATE|DB_TRUNCATE libdb4.8 tries to read some metadata from the
existing file and fails horribly.  i tried playing around with the flags
(passing only DB_TRUNCATE does not work, passing only DB_CREATE seems to
work but still produces the error message).



[2010-02-18 23:41:52] seanius at debian dot org

Description:

while the configure changes needed to get php to build against libdb4.8
are pretty trivial, there's unfortunately a significant behavior change
in how libdb's db->open() reacts when called with DB_CREATE|DB_TRUNCATE
on an existing zero-sized file.  this also breaks other apps, such as
sendmail or nvi, which use similar "locking hacks" (i'm guessing that's
what's going on here) on db files.

it's possible that this might be fixed in a later release of libdb4.8
in which case it might be good to refuse building against earlier
versions of 4.8 when the fix does come out.  in the meantime i'm
wondering about the options for someone who can't back out to 4.7 :/

for reference:

similar bug in sendmail:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=565242

similar bug in nvi (gentoo dev "I'm not sure if this is a bug or a
feature"): http://bugs.gentoo.org/286352

Reproduce code:
---
run ext/dba/tests/bug36436.phpt, for example, or probably any other db4
related code after building against 4.8.



Expected result:

PASS

Actual result:
--
FAIL, with error messages like:

PHP Notice:  dba_popen(): fop_read_meta:
/home/sean/debian/php/ext/dba/tests/test0.dbm: unexpected file type or
format in /home/sean/debian/php/ext/dba/tests/bug36436.php on line 6



---

#51086 [Opn]: will not build/work with libdb4.8

[seanius at debian dot org]

 ID:   51086
 User updated by:  seanius at debian dot org
 Reported By:  seanius at debian dot org
 Status:   Open
 Bug Type: DBM/DBA related
 Operating System: Debian (and others)
 PHP Version:  5.3.1
 New Comment:

oops, looks like there was a little race there.  yes i can see the
behavior in the snapshot too:

rangda[/home/sean/Download/php5.3-201002160730] ./run-tests.php -p
./sapi/cli/php --show-diff ext/dba/tests/bug36436.phpt

=
PHP : ./sapi/cli/php 
PHP_SAPI: cli
PHP_VERSION : 5.3.3-dev
ZEND_VERSION: 2.3.0
PHP_OS  : Linux - Linux rangda 2.6.32-trunk-amd64 #1 SMP Sun Jan 10
22:40:40 UTC 2010 x86_64
INI actual  : /home/sean/Download/php5.3-201002160730
More .INIs  :  
CWD : /home/sean/Download/php5.3-201002160730
Extra dirs  : 
VALGRIND: Not used
=
Running selected tests.
TEST 1/1 [ext/dba/tests/bug36436.phpt]
DIFF
001+ Notice: dba_popen(): fop_read_meta:
/home/sean/Download/php5.3-201002160730/ext/dba/tests/test0.dbm:
unexpected file type or format in
/home/sean/Download/php5.3-201002160730/ext/dba/tests/bug36436.php on
line 6
DONE
FAIL Bug #36436 (DBA problem with Berkeley DB4)
[ext/dba/tests/bug36436.phpt] 
=
Number of tests :1 1
Tests skipped   :0 (  0.0%) 
Tests warned:0 (  0.0%) (  0.0%)
Tests failed:1 (100.0%) (100.0%)
Expected fail   :0 (  0.0%) (  0.0%)
Tests passed:0 (  0.0%) (  0.0%)
-
Time taken  :0 seconds
=

=
FAILED TEST SUMMARY
-
Bug #36436 (DBA problem with Berkeley DB4)
[ext/dba/tests/bug36436.phpt]
=


Previous Comments:


[2010-02-19 08:36:51] seanius at debian dot org

-Status: Feedback
+Status: Open

and i've now asked in the bdb forums what they think:

http://forums.oracle.com/forums/thread.jspa?threadID=1031805&stqc=true



[2010-02-19 08:32:31] j...@php.net

-Status: Open
+Status: Feedback

Please try using this snapshot:

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

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



[2010-02-18 23:46:46] seanius at debian dot org

a little more info:  afaict the file is being created with zero size
via some stream functions in dba.c.  when db->open() is called with
DB_CREATE|DB_TRUNCATE libdb4.8 tries to read some metadata from the
existing file and fails horribly.  i tried playing around with the flags
(passing only DB_TRUNCATE does not work, passing only DB_CREATE seems to
work but still produces the error message).



[2010-02-18 23:41:52] seanius at debian dot org

Description:

while the configure changes needed to get php to build against libdb4.8
are pretty trivial, there's unfortunately a significant behavior change
in how libdb's db->open() reacts when called with DB_CREATE|DB_TRUNCATE
on an existing zero-sized file.  this also breaks other apps, such as
sendmail or nvi, which use similar "locking hacks" (i'm guessing that's
what's going on here) on db files.

it's possible that this might be fixed in a later release of libdb4.8
in which case it might be good to refuse building against earlier
versions of 4.8 when the fix does come out.  in the meantime i'm
wondering about the options for someone who can't back out to 4.7 :/

for reference:

similar bug in sendmail:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=565242

similar bug in nvi (gentoo dev "I'm not sure if this is a bug or a
feature"): http://bugs.gentoo.org/286352

Reproduce code:
---
run ext/dba/tests/bug36436.phpt, for example, or probably any other db4
related code after building against 4.8.



Expected result:

PASS

Actual result:
--
FAIL, with error messages like:

PHP Notice:  dba_popen(): fop_read_meta:
/home/sean/debian/php/ext/dba/tests/test0.dbm: unexpected file type or
format in /home/sean/debian/php/ext/dba/tests/bug36436.php on line 6






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

#51086 [Fbk->Opn]: will not build/work with libdb4.8

[seanius at debian dot org]

 ID:   51086
 User updated by:  seanius at debian dot org
 Reported By:  seanius at debian dot org
-Status:   Feedback
+Status:   Open
 Bug Type: DBM/DBA related
 Operating System: Debian (and others)
 PHP Version:  5.3.1
 New Comment:

and i've now asked in the bdb forums what they think:

http://forums.oracle.com/forums/thread.jspa?threadID=1031805&stqc=true


Previous Comments:


[2010-02-19 08:32:31] j...@php.net

-Status: Open
+Status: Feedback

Please try using this snapshot:

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

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



[2010-02-18 23:46:46] seanius at debian dot org

a little more info:  afaict the file is being created with zero size
via some stream functions in dba.c.  when db->open() is called with
DB_CREATE|DB_TRUNCATE libdb4.8 tries to read some metadata from the
existing file and fails horribly.  i tried playing around with the flags
(passing only DB_TRUNCATE does not work, passing only DB_CREATE seems to
work but still produces the error message).



[2010-02-18 23:41:52] seanius at debian dot org

Description:

while the configure changes needed to get php to build against libdb4.8
are pretty trivial, there's unfortunately a significant behavior change
in how libdb's db->open() reacts when called with DB_CREATE|DB_TRUNCATE
on an existing zero-sized file.  this also breaks other apps, such as
sendmail or nvi, which use similar "locking hacks" (i'm guessing that's
what's going on here) on db files.

it's possible that this might be fixed in a later release of libdb4.8
in which case it might be good to refuse building against earlier
versions of 4.8 when the fix does come out.  in the meantime i'm
wondering about the options for someone who can't back out to 4.7 :/

for reference:

similar bug in sendmail:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=565242

similar bug in nvi (gentoo dev "I'm not sure if this is a bug or a
feature"): http://bugs.gentoo.org/286352

Reproduce code:
---
run ext/dba/tests/bug36436.phpt, for example, or probably any other db4
related code after building against 4.8.



Expected result:

PASS

Actual result:
--
FAIL, with error messages like:

PHP Notice:  dba_popen(): fop_read_meta:
/home/sean/debian/php/ext/dba/tests/test0.dbm: unexpected file type or
format in /home/sean/debian/php/ext/dba/tests/bug36436.php on line 6






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

#50896 [Opn->Bgs]: Bus error on execution on a MIPS system

[jani]

 ID:   50896
 Updated by:   j...@php.net
 Reported By:  angel at wututu dot com
-Status:   Open
+Status:   Bogus
 Bug Type: Reproducible crash
 Operating System: GNU/Linux
 PHP Version:  5.2snapshot-201002171530
 New Comment:

Oh, you're cross-compiling this. We do not support that out-of-box,
you're totally on your own with it.


Previous Comments:


[2010-02-18 08:38:03] angel at wututu dot com

-Status: Feedback
+Status: Open
-PHP Version: 5.3SVN-2010-02-10
+PHP Version: 5.2snapshot-201002171530

The backtrace in this case is more or less the same as before:

(gdb) run
Starting program: /build/php5.2-201002171530/sapi/cli/php 
warning: no loadable sections found in added symbol-file
/usr/lib/libiconv.so.2

Program received signal SIGBUS, Bus error.
0x0071e704 in _zend_mm_alloc_int (heap=0x91f300, size=13)
at /build/php5.2-201002171530/Zend/zend_alloc.c:1897
1897ZEND_MM_CHECK_BLOCK_LINKAGE(best_fit);
(gdb) backtrace 
#0  0x0071e704 in _zend_mm_alloc_int (heap=0x91f300, size=13)
at /build/php5.2-201002171530/Zend/zend_alloc.c:1897
#1  0x0074a5b4 in zend_register_functions (scope=0x0,
functions=0x911ad0, 
function_table=, type=)
at /build/php5.2-201002171530/Zend/zend_operators.h:287
#2  0x0074358c in zend_startup (utility_functions=, 
extensions=, start_builtin_functions=1)
at /build/php5.2-201002171530/Zend/zend.c:676
#3  0x006ead00 in php_module_startup (sf=, 
additional_modules=0x0, num_additional_modules=0)
at /build/php5.2-201002171530/main/main.c:1710
#4  0x007ef254 in php_cli_startup (sapi_module=0x0)
at /build/php5.2-201002171530/sapi/cli/php_cli.c:389
#5  0x007efdd8 in main (argc=1, argv=0x7f948dc4)
at /build/php5.2-201002171530/sapi/cli/php_cli.c:748



[2010-02-17 15:59:17] j...@php.net

Is the gdb backtrace same for it? Does it happen with latest PHP-5.2
snapshot? (found at http://snaps.php.net/ ) ?



[2010-02-01 17:25:29] angel at wututu dot com

Still the same error with the snapshot:

Generating phar.php
/bin/sh: line 1: 29472 Bus error   ` if test -x
"/build/php5.3-201002010930/sapi/cli/php"; then
/build/php5.3-201002010930/build/shtool echo -n --
"/build/php5.3-201002010930/sapi/cli/php -n"; if test "x" != "x"; then
/build/php5.3-201002010930/build/shtool echo -n -- " -d
extension_dir=/build/php5.3-201002010930/modules"; for i in bz2 zlib
phar; do if test -f "/build/php5.3-201002010930/modules/$i.la"; then .
/build/php5.3-201002010930/modules/$i.la;
/build/php5.3-201002010930/build/shtool echo -n -- " -d
extension=$dlname"; fi; done; fi; else
/build/php5.3-201002010930/build/shtool echo -n --
"/build/php5.3-201002010930/sapi/cli/php"; fi;` -d 'open_basedir=' -d
'output_buffering=0' -d 'memory_limit=-1' -d phar.readonly=0 -d
'safe_mode=0' /build/php5.3-201002010930/ext/phar/build_precommand.php >
ext/phar/phar.php
make: *** [ext/phar/phar.php] Error 138

And when being run:

root@(none):/build/php5.3-201002010930# ./sapi/cli/php
Bus error

Let's see if someone can fix it or at least point me how to fix it.



[2010-02-01 10:07:09] angel at wututu dot com

Description:

I've been trying to cros-compile PHP for an embedded MIPS device with
no luck, so I decided to build a developing environment inside a virtual
machine with QEMU for developing PHP inside first.

I have been trying different options for configure and all I get is a
Bus Error 138 when I run the executable. I've seen there is another
thread about this same error and I applied the patches but the error
was still present.

I've tried to debug a little the code to find where the error is. I'm
explaining it right now:

I ran it first under gdb:

--
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 "mipsel-unknown-linux-gnu"...
(gdb) run
Starting program: /build/php-5.3.1/sapi/cli/php
warning: no loadable sections found in added symbol-file
/usr/lib/libiconv.so.2
starting php right now at main...

Program received signal SIGBUS, Bus error.
0x00a51634 in _zend_mm_alloc_int (heap=0xef92f0, size=14)
   at /build/php-5.3.1/Zend/zend_alloc.c:1892
1892ZEND_MM_CHECK_BLOCK_LINKAGE(best_fit);
(gdb) backtrace
#0  0x00a51634 in _zend_mm_alloc_int (heap=0xef92f0, size=14)
   at /build/php-5.3.1/Zend/zend_alloc.c:1892
#1  0x00a53018 in _emalloc (size=14) at
/build/php-5.3.1/Zend/zend_alloc.c:2295
#2  0x00a8be90 in 

#51086 [Opn->Fbk]: will not build/work with libdb4.8

[jani]

 ID:   51086
 Updated by:   j...@php.net
 Reported By:  seanius at debian dot org
-Status:   Open
+Status:   Feedback
 Bug Type: DBM/DBA related
 Operating System: Debian (and others)
 PHP Version:  5.3.1
 New Comment:

Please try using this snapshot:

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

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




Previous Comments:


[2010-02-18 23:46:46] seanius at debian dot org

a little more info:  afaict the file is being created with zero size
via some stream functions in dba.c.  when db->open() is called with
DB_CREATE|DB_TRUNCATE libdb4.8 tries to read some metadata from the
existing file and fails horribly.  i tried playing around with the flags
(passing only DB_TRUNCATE does not work, passing only DB_CREATE seems to
work but still produces the error message).



[2010-02-18 23:41:52] seanius at debian dot org

Description:

while the configure changes needed to get php to build against libdb4.8
are pretty trivial, there's unfortunately a significant behavior change
in how libdb's db->open() reacts when called with DB_CREATE|DB_TRUNCATE
on an existing zero-sized file.  this also breaks other apps, such as
sendmail or nvi, which use similar "locking hacks" (i'm guessing that's
what's going on here) on db files.

it's possible that this might be fixed in a later release of libdb4.8
in which case it might be good to refuse building against earlier
versions of 4.8 when the fix does come out.  in the meantime i'm
wondering about the options for someone who can't back out to 4.7 :/

for reference:

similar bug in sendmail:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=565242

similar bug in nvi (gentoo dev "I'm not sure if this is a bug or a
feature"): http://bugs.gentoo.org/286352

Reproduce code:
---
run ext/dba/tests/bug36436.phpt, for example, or probably any other db4
related code after building against 4.8.



Expected result:

PASS

Actual result:
--
FAIL, with error messages like:

PHP Notice:  dba_popen(): fop_read_meta:
/home/sean/debian/php/ext/dba/tests/test0.dbm: unexpected file type or
format in /home/sean/debian/php/ext/dba/tests/bug36436.php on line 6






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

#50731 [Opn]: Inconsistent namespaces sent to functions registered with spl_autoload_register

[jani]

 ID:   50731
 Updated by:   j...@php.net
 Reported By:  court at epixa dot com
 Status:   Open
 Bug Type: SPL related
-Operating System: MAC OS X 10.6.2
+Operating System: *
-PHP Version:  5.3.1
+PHP Version:  5.3, 6
 New Comment:

See also bug #51087


Previous Comments:


[2010-01-12 22:52:03] court at epixa dot com

I don't know how I didn't notice this earlier, but it seems the issue
isn't simply with a leading slash but with evaluating namespaces
entirely for autoloading.  Consider the following code coupled with my
original autoloader function:

namespace Fully\Qualified;
new ClassName();
// expects: Fully\Qualified\ClassName
// outputs: Fully\Qualified\ClassName

$myClass = 'ClassName';
new $myClass();
// expects: Fully\Qualified\ClassName
// outputs: ClassName

It is my understanding that the loader functions are executed in the
global namespace and thus should only be dealing with fully qualified
namespaces.  It appears as if the fully qualified namespace is evaluated
and passed to registered autoloaders if the class name is specified
explicitly, but the same cannot be said for class names that are created
dynamically.



[2010-01-12 18:09:45] court at epixa dot com

Description:

When you instantiate a namespaced class, the expected behavior is for
the fully qualified namespace with leading slash absent to be passed to
your registered function.  However, if you instantiate a namespaced
class with a class name stored in a variable, the fully qualified
namespace is not evaluated and the leading slash (if specified) is
included.

You'll have to run the reproduce code twice to see what I mean.

Reproduce code:
---
function loadClass($class) {
die($class . PHP_EOL);
}

spl_autoload_register('loadClass');

$myClass = '\Fully\Qualified\ClassName';

// run this first:
new \Fully\Qualified\ClassName();

// run this second:
//new $myClass();

Expected result:

First run:
Fully\Qualified\ClassName

Second run:
Fully\Qualified\ClassName

Actual result:
--
First run:
Fully\Qualified\ClassName

Second run:
\Fully\Qualified\ClassName





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

#51087 [Opn->Bgs]: spl_autoload doesn't handle classes starting with T_NS_SEPARATOR properly

[jani]

 ID:   51087
 Updated by:   j...@php.net
 Reported By:  andrey at ning dot com
-Status:   Open
+Status:   Bogus
 Bug Type: SPL related
 Operating System: any
 PHP Version:  5.3.2RC2
 New Comment:

Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same. 

Thank you for your interest in PHP.

See bug #50731


Previous Comments:


[2010-02-19 01:17:35] andrey at ning dot com

Description:

When several autoload handlers are registered with
spl_autoload_register, and the class starting with T_NS_SEPARATOR (\)
AND created using the variable class name is autoloaded, spl_autoload
does not stop at the first successful item and goes thru the whole
stack.


Reproduce code:
---
// Source files:
// foo-bar1.php
namespace foo; class bar1 {}

// foo-bar2.php
namespace foo; class bar2 {}

// foo-baz1.php
namespace foo; class baz1 {}

// foo-baz2.php
namespace foo; class baz2 {}

// test.php
function autoload1($class) {
echo "autoload1($class) is called!\n";
$path = array_filter(explode('\\', $class), 'strlen');
require join('-', $path) . ".php";
}
function autoload2($class) {
echo "autoload2($class) is called!\n";
$path = array_filter(explode('\\', $class), 'strlen');
require join('-', $path) . ".php";
}
spl_autoload_register('autoload1');
spl_autoload_register('autoload2');

$f = new foo\bar1;
$f = new \foo\baz1;
$class = "foo\\bar2"; $f = new $class;
$class = "\\foo\\baz2"; $f = new $class;


Expected result:

autoload1(foo\bar1) is called!
autoload1(foo\baz1) is called!
autoload1(foo\bar2) is called!
autoload1(\foo\baz2) is called!


Actual result:
--
autoload1(foo\bar1) is called!
autoload1(foo\baz1) is called!
autoload1(foo\bar2) is called!
autoload1(\foo\baz2) is called!
autoload2(\foo\baz2) is called!
PHP Fatal error:  Cannot redeclare class foo\baz2






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

#50990 [Com]: gmp extension doesn't compile with gmp 5.0.1

[susan dot smith dot dev at gmail dot com]

 ID:   50990
 Comment by:   susan dot smith dot dev at gmail dot com
 Reported By:  php-bugs-2010 at ryandesign dot com
 Status:   Open
 Bug Type: GNU MP related
 Operating System: Mac OS X 10.6.2
 PHP Version:  5.3.2RC1
 New Comment:

@ pajoye at php dot net

I should probably ignore your comment, simply...

Was I not polite? Why?
Did I say that someone choice are "madness"? Or I simply said that
different libraries give different support to different systems? Users
should be free to make their own choice, shouldn't they?

Some PHP users asked for a very small compatibility issue, and someone
here suggested them to change the library they are using... This is not
respect for users choices, is it?

I suggested a very simple change. With it, PHP will be compatible with
old GMP versions, with the last GMP version, with old MPIR versions and
with the last MPIR version. You may say that suggesting such a small
change is not polite, maybe... but it solved the problems to the users.
Is there someone that is using this ticket for propaganda? Instead of
using it for bug-tracking? Read the entire thread and guess who :-)

I suggest to close this discussion this way: verify if the suggested
change breaks anything, apply it, and close the ticket. Sorry if you
feel this last suggestion as not polite.

I'll not answer any more, the bug was solved.


Previous Comments:


[2010-02-18 22:52:46] paj...@php.net

@susan dot smith dot dev at gmail dot com 

Please stay pollite. 

MPIR has more maintainers, more open and active. Yes, GMP is still
under development, but that's about it. Now about lgpl v3, we are
certainly not on the same line.



[2010-02-18 18:11:43] vikingjs at mac dot com

Thanks, Susan - that substitution (in gmp.c on line 1362 for those 
following at home) got me over this hurdle as well.



[2010-02-17 15:52:57] susan dot smith dot dev at gmail dot com

Don't be silly! MPIR gives better support for Windows, not for "modern
architecture", on POSIX systems GMP (http://gmplib.org/) is usually
better... and LGPL v3 is as compatible with the licence of PHP as LGPL
v2 is.

I solved replacing the outdated __GMP_BITS_PER_MP_LIMB defined constant
with GMP_LIMB_BITS. The latter is present in all previous versions, and
MPIR define it too.



[2010-02-10 10:56:33] paj...@php.net

ZF depends on the gmp php extension, which can be built against MPIR
instead of gmplib. See http://www.mpir.org/. It is a rock solid gmp
compatible library with much better support for modern architecture and
optimizations, without the (l)gpl v3 license madness.



[2010-02-10 10:23:47] juri dot saltbacka at gmail dot com

It is important because ZendFramework depends on GMP. At least on Mac
OS 
X



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

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

#48559 [Com]: Object comparison using unserialized DateTime object causes segfault

[thomas dot corbiere at free dot fr]

 ID:   48559
 Comment by:   thomas dot corbiere at free dot fr
 Reported By:  fel...@php.net
 Status:   Assigned
 Bug Type: Date/time related
 Operating System: Linux
 PHP Version:  5.2CVS-2009-06-15 (CVS)
 Assigned To:  derick
 New Comment:

Same problem with PHP 5.2.12 on Windows Server 2003 R2


Previous Comments:


[2009-06-23 20:24:59] sjoerd-php at linuxonly dot nl

Could reproduce on PHP 5.2.10 (cli), not on PHP 5.3.0RC4 (cli).



[2009-06-15 13:51:45] fel...@php.net

Description:

This issue just occurs on 5.2.

See the code below.

Reproduce code:
---
time->sse_uptodate) {
(gdb) bt
#0  0x080bed7a in date_object_compare_date (d1=0xa7a5308, d2=0xa7a5288,
tsrm_ls=0xa5802a8) at /home/felipe/dev/php5_2/ext/date/php_date.c:1581
#1  0x084e3773 in compare_function (result=0xbfc93f10, op1=0xa7a5308,
op2=0xa7a5288, tsrm_ls=0xa5802a8) at
/home/felipe/dev/php5_2/Zend/zend_operators.c:1416
#2  0x084e404c in is_equal_function (result=0xbfc93f10, op1=0xa7a5308,
op2=0xa7a5288, tsrm_ls=0xa5802a8) at
/home/felipe/dev/php5_2/Zend/zend_operators.c:1547
#3  0x0853b9f1 in ZEND_IS_EQUAL_SPEC_VAR_VAR_HANDLER
(execute_data=0xbfc93f44, tsrm_ls=0xa5802a8) at
/home/felipe/dev/php5_2/Zend/zend_vm_execute.h:11516
#4  0x085126e4 in execute (op_array=0xa7a5a10, tsrm_ls=0xa5802a8) at
/home/felipe/dev/php5_2/Zend/zend_vm_execute.h:92
#5  0x084da6aa in zend_eval_string (str=0xbfc957dc
"unserialize(serialize(new datetime())) == new datetime;",
retval_ptr=0x0, 
string_name=0x87fb6dc "Command line code", tsrm_ls=0xa5802a8) at
/home/felipe/dev/php5_2/Zend/zend_execute_API.c:1214
#6  0x084da8e2 in zend_eval_string_ex (str=0xbfc957dc
"unserialize(serialize(new datetime())) == new datetime;",
retval_ptr=0x0, 
string_name=0x87fb6dc "Command line code", handle_exceptions=1,
tsrm_ls=0xa5802a8) at
/home/felipe/dev/php5_2/Zend/zend_execute_API.c:1248
#7  0x08573484 in main (argc=3, argv=0xbfc94314) at
/home/felipe/dev/php5_2/sapi/cli/php_cli.c:1201






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