Bug #60309 [Opn->Fbk]: fread(STDIN, 1024) returns instantly.

[laruence]

Edit report at https://bugs.php.net/bug.php?id=60309&edit=1

 ID: 60309
 Updated by: larue...@php.net
 Reported by:Dygear at gmail dot com
 Summary:fread(STDIN, 1024) returns instantly.
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:Streams related
 Operating System:   Windows 7 - CLI
 PHP Version:5.4.0RC1
 Block user comment: N
 Private report: N

 New Comment:

Please try using this snapshot:

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

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

I can't reproduce this in my environ. 
but I do fine that 
stream_set_blocking(STDIN, FALSE);  Has no effect on windows


Previous Comments:

[2011-11-15 19:56:45] Dygear at gmail dot com

Description:

I am using the windows version of PHP 5.4 (5.4.0RC1) from 2011-Nov-10 19:52:12, 
VC9 x86 Non Thread Safe. In 5.3.x the code worked to where I could query a 
client 
for an input from the command line using fread and STDIN. In the version 
stated, 
5.4.0RC1, the function returns right away, and does not give the user anytime 
to 
input a string.

Test script:
---


Expected result:

I would expect for there be an opportunity for the user to input a string.

Actual result:
--
The script has no result, and the client is never queried for a string.






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

Bug #60290 [Bgs]: Apc.php – Wrong use of var_export

[rasmus]

Edit report at https://bugs.php.net/bug.php?id=60290&edit=1

 ID: 60290
 Updated by: ras...@php.net
 Reported by:klaus-martin dot hansche at kvberlin dot de
 Summary:Apc.php – Wrong use of var_export
 Status: Bogus
 Type:   Bug
 Package:APC
 Operating System:   Irrelevant
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

What are you saying? That someone pretended to be you when they submitted this 
bug report?


Previous Comments:

[2011-11-16 06:04:33] klaus-martin dot hansche at kvberlin dot de

Please, remove this "report" and my mail-address immediately. And think about 
not publishing unconfirmed addresses anymore.


[2011-11-15 20:46:36] ras...@php.net

var_export($var, true) is quite valid and tells var_export to return the 
exported 
string instead of outputting it. See http://php.net/var_export


[2011-11-14 06:57:45] klaus-martin dot hansche at kvberlin dot de

Description:

Apc.php line 1000 should be
$output = var_export(apc_fetch($entry[$fieldkey]));
instead of
$output = var_export(apc_fetch($entry[$fieldkey]),true);
The last parameter of var_export is a reference to a boolean var.







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

Bug #60290 [Bgs]: Apc.php – Wrong use of var_export

[klaus-martin dot hansche at kvberlin dot de]

Edit report at https://bugs.php.net/bug.php?id=60290&edit=1

 ID: 60290
 User updated by:klaus-martin dot hansche at kvberlin dot de
 Reported by:klaus-martin dot hansche at kvberlin dot de
 Summary:Apc.php – Wrong use of var_export
 Status: Bogus
 Type:   Bug
 Package:APC
 Operating System:   Irrelevant
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

Please, remove this "report" and my mail-address immediately. And think about 
not publishing unconfirmed addresses anymore.


Previous Comments:

[2011-11-15 20:46:36] ras...@php.net

var_export($var, true) is quite valid and tells var_export to return the 
exported 
string instead of outputting it. See http://php.net/var_export


[2011-11-14 06:57:45] klaus-martin dot hansche at kvberlin dot de

Description:

Apc.php line 1000 should be
$output = var_export(apc_fetch($entry[$fieldkey]));
instead of
$output = var_export(apc_fetch($entry[$fieldkey]),true);
The last parameter of var_export is a reference to a boolean var.







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

Bug #60310 [Opn->Fbk]: UTF-8 to ISO-8859-1 conversion of a string segfaults

[rasmus]

Edit report at https://bugs.php.net/bug.php?id=60310&edit=1

 ID: 60310
 Updated by: ras...@php.net
 Reported by:dkelsey at bstage dot ca
 Summary:UTF-8 to ISO-8859-1 conversion of a string segfaults
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:ICONV related
 Operating System:   Solaris 10
 PHP Version:5.3.8
 Block user comment: N
 Private report: N

 New Comment:

The first thing I am noticing in this report is that you mentioned downloading 
and installing gnu iconv into /opt/local however your backtrace shows no sign 
of 
this being used:

#1  0xfe5068ab in iconv () from /lib/libc.so.1
No symbol table info available.

This looks like it is because you didn't tell PHP to use it. Try using:

--with-iconv=/opt/local

And see if that makes a difference.


Previous Comments:

[2011-11-15 22:22:02] dkelsey at bstage dot ca

Whether I use $text = utf8_encode("Dave Kelsey"); or not makes no difference


[2011-11-15 21:48:07] dkelsey at bstage dot ca

Description:

using iconv() within a php script segfaults when converting a UTF-8 string to 
ISO-8859-1

I downloaded and compiled gnu libiconv-1.14 into /opt/local

My php configure 

./configure  '--prefix=/opt/bstage/php5.3.8' \
'--with-apxs2=/opt/bstage/apache2.2.21-php/bin/apxs' \
'--enable-bcmath' \
'--enable-mbstring' \
'--with-zlib' \
'--with-config-file-path=/opt/bstage/php5.3.8/lib' \
'--with-xsl' \
'--with-xmlrpc' \
'--with-regex=system' \
'--without-sqlite' \
'--disable-posix' \
'--enable-dom' \
'--disable-pdo' \
'--enable-xml' \
'--with-libxml-dir=/opt/local' \
'--enable-ipv6' \
'--host=i386-sun-solaris2' \
'--mandir=/opt/local/man' \
'--with-gd' \
'--with-mysql=/opt/mysql-5.5.8-solaris10-i386' \
'--with-mysqli=/opt/mysql-5.5.8-solaris10-i386/bin/mysql_config' \
'--with-curl=/opt/local' \
'--enable-debug'


ldd php
libexslt.so.0 => /usr/lib/libexslt.so.0
libresolv.so.2 =>/lib/libresolv.so.2
libmysqlclient.so.16 =>  
/opt/mysql-5.5.8-solaris10-i386/lib/libmysqlclient.so.16
libiconv.so.2 => /opt/local/lib/libiconv.so.2
libpng12.so.0 => /usr/lib/libpng12.so.0
libz.so.1 => /usr/lib/libz.so.1
librt.so.1 =>/lib/librt.so.1
libm.so.2 => /lib/libm.so.2
libnsl.so.1 =>   /lib/libnsl.so.1
libsocket.so.1 =>/lib/libsocket.so.1
libxml2.so.2 =>  /usr/lib/libxml2.so.2
libcurl.so.4 =>  /opt/local/lib/libcurl.so.4
libssl.so.0.9.7 =>   /usr/sfw/lib/libssl.so.0.9.7
libcrypto.so.0.9.7 =>/usr/sfw/lib/libcrypto.so.0.9.7
libldap.so.5 =>  /usr/lib/libldap.so.5
libdl.so.1 =>/lib/libdl.so.1
libthread.so.1 =>/lib/libthread.so.1
libxslt.so.1 =>  /usr/lib/libxslt.so.1
libc.so.1 => /lib/libc.so.1
libpthread.so.1 =>   /lib/libpthread.so.1
libgcc_s.so.1 => /usr/sfw/lib/libgcc_s.so.1
libaio.so.1 =>   /lib/libaio.so.1
libmd.so.1 =>/lib/libmd.so.1
libmp.so.2 =>/lib/libmp.so.2
libscf.so.1 =>   /lib/libscf.so.1
libsasl.so.1 =>  /usr/lib/libsasl.so.1
libnspr4.so =>   /usr/lib/mps/libnspr4.so
libplc4.so =>/usr/lib/mps/libplc4.so
libnss3.so =>/usr/lib/mps/libnss3.so
libssl3.so =>/usr/lib/mps/libssl3.so
libdoor.so.1 =>  /lib/libdoor.so.1
libuutil.so.1 => /lib/libuutil.so.1
libgen.so.1 =>   /lib/libgen.so.1
libsoftokn3.so =>/usr/lib/mps/libsoftokn3.so
libplds4.so =>   /usr/lib/mps/libplds4.so
libbsm.so.1 =>   /lib/libbsm.so.1
libsecdb.so.1 => /lib/libsecdb.so.1
libtsol.so.2 =>  /lib/libtsol.so.2
libcmd.so.1 =>   /lib/libcmd.so.1
libssl_extra.so.0.9.7 => /usr/sfw/lib/libssl_extra.so.0.9.7
libcrypto_extra.so.0.9.7 =>  /usr/sfw/lib/libcrypto_extra.so.0.9.7

I've used truss and gdb and get a segfault.

Test script:
---




Expected result:

Original : Dave Kelsey
Plain: Dave Kelsey

Actual result:
--
./php -ef iconv.php
Original : Dave Kelsey
Plain: Segmentation Fault (core dumped)

Note: the parsing of the string takes about 3-4 seconds?

gdb ./php -c core
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"

Bug #59493 [Com]: APC fails to include files with relative paths and apc.stat=0

[webmaster_apc at colnect dot com]

Edit report at https://bugs.php.net/bug.php?id=59493&edit=1

 ID: 59493
 Comment by: webmaster_apc at colnect dot com
 Reported by:pierre at archlinux dot de
 Summary:APC fails to include files with relative paths and
 apc.stat=0
 Status: Wont fix
 Type:   Bug
 Package:APC
 Operating System:   Arch Linux
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

This is stuck on wontfix but seems that I can now do stat="0" again. Currently 
with v3.1.7 of APC and all seems to be responding well.


Previous Comments:

[2011-02-28 19:01:22] passby at gmail dot com

After upgraded PHP to 5.2, I have the same relative path issue of APC.

Then I ran across another thread about this and people mentioning to set 
apc.canonicalize=1. From what I observed the speed did increase a lot and the 
issue seems to be resolved.


[2011-01-21 11:59:17] aaron dot cicali at gmail dot com

I use a 3rd party PHP framework and using stat=0 breaks all 
over.  I would also like to add my request for a third state 
of this parameter for backwards compatibility.  Thanks.


[2011-01-16 04:33:08] webmaster_apc2 at colnect dot com

While I can easily adjust my code, it becomes much harder to do that for third 
party code such as the aforementioned phpBB. Not being backward compatible is 
something that always has to be considered seriously. In this case, there's no 
need not to be backward compatible as you can add the "fix" in a way that 
doesn't damage existing code. PLEASE fix it.


[2010-12-26 13:18:54] gop...@php.net

Actually, that's exactly what it does right now.

apc.stat=0 is not intended to work for all cases, it's designed to be fast for 
the people who do write code for it.


[2010-12-26 11:18:41] john at feurix dot com

Please reconsider the previous suggestion to keep supporting a lazy stat (even 
if this was not initially intended and is considered a bug today):

If apc.stat=2 (or call it apc.lazy_stat), then skip stat for absolute paths, 
and _try_ to skip stat for relative paths. If the latter fails, fall back to 
stat.

Educating the world to use absolute paths all the time is kind of ignorant. It 
isn't going to happen. Thank you!




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

https://bugs.php.net/bug.php?id=59493


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

Bug #30671 [Com]: "Unable to fork..."-error appears periodically

[jtm dot moon dot forum dot user at gmail dot com]

Edit report at https://bugs.php.net/bug.php?id=30671&edit=1

 ID: 30671
 Comment by: jtm dot moon dot forum dot user at gmail dot com
 Reported by:henning dot mohren at gmx dot de
 Summary:"Unable to fork..."-error appears periodically
 Status: Wont fix
 Type:   Bug
 Package:Filesystem function related
 Operating System:   Solaris 9
 PHP Version:5.0.2
 Block user comment: N
 Private report: N

 New Comment:

My previous comment about the plimit workround does not seem to be working 
consistently.  It worked for about 10 minutes and then I ran into problems 
again.  The process forks are only happening once or twice a minute.  So it's 
not that the new range for FD was used up within 10 minutes.

The only thing that seems to work is waiting a few minutes.


Previous Comments:

[2011-10-28 21:59:49] jtm dot moon dot forum dot user at gmail dot com

This works for me.  php running within Apache (process name "httpd").
sudo plimit -n 65536,1048575 $(pgrep 'httpd')
This increases the integer values allowed for new file descriptors.


[2004-11-17 09:22:19] tony2...@php.net

Tune your Solaris instead. 
Values of rlim_fd_max and rlim_fd_cur can be changed with appropriate settings 
in /etc/system.
I doubt that PHP can implement any workaround for OS limit.


[2004-11-03 13:36:39] henning dot mohren at gmx dot de

Description:

Solaris restricts the use of popen() to 255 files, which is a low limit in case 
of servers. When using PHP's system() commands, PHP calls Solaris popen(). This 
fails, when too system-commands have been invoked.
See here (http://www.sitepoint.com/forums/showthread.php?p=1245879#post1245879) 
for more details.

Expected result:

PHP should implement a workaround or call another Solaris function for invoking 
system commands.







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

Bug #60165 [Opn->Asn]: Overriding unexisting trait should throw/trigger the exception/error

[felipe]

Edit report at https://bugs.php.net/bug.php?id=60165&edit=1

 ID: 60165
 Updated by: fel...@php.net
 Reported by:fruit dot dev at gmail dot com
 Summary:Overriding unexisting trait should throw/trigger the
 exception/error
-Status: Open
+Status: Assigned
 Type:   Bug
-Package:Class/Object related
+Package:Scripting Engine problem
 Operating System:   Fedora 14
 PHP Version:5.4.0beta2
-Assigned To:
+Assigned To:gron
 Block user comment: N
 Private report: N



Previous Comments:

[2011-10-28 21:23:56] fruit dot dev at gmail dot com

Description:

In case, when user overrides invalid traits method, PHP should check whether 
specified method belongs to given trait.

The code given below is valid for preprocessing. Meanwhile trait "A" does not 
have method "getTitle", as well as trait "B" does contains "getSlug" method.

I guess, PHP should trigger error telling about the user is entangled among the 
three pines.

Test script:
---
  trait A
  {
public function getSlug ()
{
  return $this->slug;
}
  }

  trait B
  {
public function getTitle ()
{
  return $this->title;
}
  }

  class Foo
  {
protected $slug, $title;

use A, B
{
  A::getTitle as title;
  B::getSlug as slug;
}
  }

  $object = new Foo();

Expected result:

Error/exception should be triggered/thrown

Actual result:
--
silence (no errors was shown)






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

Bug #60138 [Opn->Asn]: GC crash with referenced array in RecursiveArrayIterator

[felipe]

Edit report at https://bugs.php.net/bug.php?id=60138&edit=1

 ID: 60138
 Updated by: fel...@php.net
 Reported by:jinmoku at hotmail dot com
 Summary:GC crash with referenced array in
 RecursiveArrayIterator
-Status: Open
+Status: Assigned
 Type:   Bug
 Package:SPL related
 Operating System:   Windows 7
 PHP Version:5.3.8
-Assigned To:
+Assigned To:dmitry
 Block user comment: N
 Private report: N



Previous Comments:

[2011-10-26 09:44:22] jinmoku at hotmail dot com

Description:

GC crash with referenced array in RecursiveArrayIterator,(no problem with 
gc_disable)

Test script:
---
$tree = array();
$branch = &$tree;

$courses = array(
'f1' => '/d1',
'f6' => '/d2',
'f7' => '/d3',
'f8' => '/d3/d4',
'f9' => '/d3/d4',
);

foreach($courses as $id => $course) {
$path = explode('/', substr($course, 1));
$branch = &$tree;
foreach($path as $category) {
if (!isset($branch[$category])) {
$branch[$category] = array();
}
$branch = &$branch[$category];
}
$branch[] = $id;
}

$iterator = new RecursiveIteratorIterator(
new RecursiveArrayIterator($tree),
RecursiveIteratorIterator::SELF_FIRST
);

foreach($iterator as $file);

Actual result:
--
PHP5TS!GC_REMOVE_ZVAL_FROM_BUFFER+2C4In 
php__PID__1756__Date__10_26_2011__Time_11_24_34AM__612__Second_Chance_Exception_C005.dmp
 the assembly instruction at php5ts!gc_remove_zval_from_buffer+2c4 in 
C:\Program Files (x86)\PHP\php5ts.dll from The PHP Group has caused an access 
violation exception (0xC005) when trying to read from memory location 
0x000c on thread 0



php5ts!gc_remove_zval_from_buffer+2c4 0127fbd0 00291a70 00291a70
php5ts!gc_remove_zval_from_buffer+476 00291a70 00bef62c 73fc3b4e
php5ts!gc_collect_cycles+6a   00291a70 00291a70 6592cc2e
php5ts!zend_deactivate+12600291a70 00291a70 00291a04
php5ts!php_request_shutdown+31f    013c742c 0001
php!main+122b 0002 00291a00 00291fd0
php!memcpy+1607efde000 00befb68 77439ed2
kernel32!BaseThreadInitThunk+e7efde000 77d7d20f 
ntdll!__RtlUserThreadStart+70 013c3002 7efde000 
ntdll!_RtlUserThreadStart+1b  013c3002 7efde000 







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

Bug #60123 [Opn->Bgs]: Metaphone returns string longer than limit

[felipe]

Edit report at https://bugs.php.net/bug.php?id=60123&edit=1

 ID: 60123
 Updated by: fel...@php.net
 Reported by:gravisoft at gmail dot com
 Summary:Metaphone returns string longer than limit
-Status: Open
+Status: Bogus
 Type:   Bug
 Package:Unknown/Other Function
 Operating System:   Windows XP SP3
 PHP Version:5.3.8
 Block user comment: N
 Private report: N

 New Comment:

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

It isn't an 'string length limit', but the max number of phonemes. X -> KS


Previous Comments:

[2011-10-24 15:43:19] gravisoft at gmail dot com

Description:

The metaphone function accepts two parameters: an input string, and a string 
length limit.  With certain input, it is possible to cause metaphone to return 
a string longer than the specified limit.
The issue seems to arise when the string is nearing it's length limit and the 
following input character is an X, which can translate to a KS, pushing the 
string over its limit.

Test script:
---


Expected result:

string(10) "ATMNSTRTRK"
string(5) "ASTRK"

Actual result:
--
string(11) "ATMNSTRTRKS"
string(6) "ASTRKS"






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

Bug #60062 [Opn->Bgs]: Negative memory (allocated -1119879168)

[felipe]

Edit report at https://bugs.php.net/bug.php?id=60062&edit=1

 ID: 60062
 Updated by: fel...@php.net
 Reported by:septerrianin at mail dot ru
 Summary:Negative memory (allocated -1119879168)
-Status: Open
+Status: Bogus
 Type:   Bug
 Package:*General Issues
 Operating System:   Debian GNU/Linux
 PHP Version:5.3.8
 Block user comment: N
 Private report: N

 New Comment:

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

Currently it's a long type.


Previous Comments:

[2011-10-14 12:02:08] septerrianin at mail dot ru

Description:

Sample error on system with 4+ Gbyte memory:

Fatal error: Out of memory (allocated -1119879168) (tried to allocate 1048581 
bytes) in /usr/local/sbin/1/!testing0.php on line 13

Why displayed memory is negative? Int is using?

Test script:
---









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

Bug #51311 [Opn->Asn]: odbc_columns() fetching binary garbage with unixODBC on 64-bit platform

[felipe]

Edit report at https://bugs.php.net/bug.php?id=51311&edit=1

 ID: 51311
 Updated by: fel...@php.net
 Reported by:gregor at hostgis dot com
 Summary:odbc_columns() fetching binary garbage with unixODBC
 on 64-bit platform
-Status: Open
+Status: Assigned
 Type:   Bug
 Package:ODBC related
 Operating System:   Linux, Slamd64 11.0
 PHP Version:5.2.13
-Assigned To:
+Assigned To:felipe
 Block user comment: N
 Private report: N



Previous Comments:

[2010-03-17 01:13:18] gregor at hostgis dot com

Description:

Platform and versions:
PHP 5.2.13, built from source
unixODBC 2.2.14, built from source
ODBC support compiled-in

Configure line:

./configure  --prefix=/usr --with-libdir=lib64 
--with-config-file-path=/etc/apache --sysconfdir=/etc 
--enable-force-cgi-redirect --with-regex=system --with-freetype-dir=/usr 
--with-openssl --with-zlib --with-curl --enable-ftp --with-pgsql 
--with-mysql=/usr --with-mysqli=/usr/bin/mysql_config --enable-dbase 
--enable-soap --with-gettext --enable-mbstring=all --enable-mbregex --with-gd 
--with-jpeg-dir=/usr --with-png-dir=/usr --with-ming 
--with-unixODBC=/usr/local/unixODBC

Database servers: MySQL 5.0

Issue:

Using odbc_columns() or odbc_columnprivileges() returns binary garbage in its 
fields.

My guess, based on previous unixODBC-related bugs in other software (GDAL/OGR), 
is a integer range issue in unixODBC on 64-bit platforms. In the case of 
GDAL/OGR the developer noted that unixODCB was returning garbage as the first 4 
bytes of a 8-byte integer; his fix was truncating and casting the values.

Test script:
---
\n";
}

// do it again and print a table of the columns' info, and again see 4 rows
// but note how theyre all identical binary garbage
odbc_free_result($columninfo);
$columninfo = odbc_columns($odbc, '', '', 'grid', '%');
odbc_result_all($columninfo);
?>


Expected result:

It should report information about the 4 columns in the table, as described in 
odbc_columns() documentation. It should do this in 2 ways: a series of 
print_r() outputs and a HTML table.

Actual result:
--
For the first part, the series of print_r() statements, the appropriate number 
of rows (one per column) is printed, but they are all blank.

For the second, the HTML table, the appropriate number of rows (one per column) 
is printed, but all information is binary garbage.






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

Bug #60052 [Opn->Asn]: Integer returned as a 64bit integer on X64_86

[felipe]

Edit report at https://bugs.php.net/bug.php?id=60052&edit=1

 ID: 60052
 Updated by: fel...@php.net
 Reported by:m dot vanduren at jonker dot nl
 Summary:Integer returned as a 64bit integer on X64_86
-Status: Open
+Status: Assigned
 Type:   Bug
 Package:InterBase related
 Operating System:   All (linux tested)
 PHP Version:5.3.8
-Assigned To:
+Assigned To:felipe
 Block user comment: N
 Private report: N



Previous Comments:

[2011-10-13 13:01:36] m dot vanduren at jonker dot nl

Description:

Integer on firebird is treated as a 32 bit int and int64 is used as a 64 bit 
integer.
In the pdo_firebird driver INT64 is not implemented and LONG (int32) is treated 
as a long integer. On an x86_64 machine this means that a SQL_LONG doesn't 
honor the bit-sign in a value and INT64 doesn't return anything.

This patch should fix this value for x86_64 systems while leaving x86 systems 
unchanged.

Test script:
---
any firebirdSQL database with a integer field containing a negative value.
retrieve the value with the pdo_firebird driver on a 64 bit machine and echo it 
to the screen.

Expected result:

negative values with integer and should be returned as a negative number.

Actual result:
--
negative values are returned as their unsigned counterpart.






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

Bug #56127 [Opn->Csd]: Segmentation Fault when using tidy_repair_string with Curl

[felipe]

Edit report at https://bugs.php.net/bug.php?id=56127&edit=1

 ID: 56127
 Updated by: fel...@php.net
 Reported by:m...@php.net
 Summary:Segmentation Fault when using tidy_repair_string
 with Curl
-Status: Open
+Status: Closed
 Type:   Bug
-Package:tidy
+Package:*General Issues
 Operating System:   Linux
 PHP Version:5CVS-2004-07-11 (dev)
-Assigned To:
+Assigned To:felipe
 Block user comment: N
 Private report: N

 New Comment:

Looks as this old problem is already fixed. :)


Previous Comments:

[2004-07-11 07:50:23] m...@php.net

Description:

Passing the return value of curl_exec() to tidy_repair_string() causes a 
segmentation fault. I'm using Curl 7.12.0 and the latest tidylib version from 
tidy.sf.net.

See below for the code and a backtrace.

Reproduce code:
---
http://php.net/";);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
$str = curl_exec($ch);
curl_close($ch);

echo tidy_repair_string($str);

Actual result:
--
#0  0x0820c3f0 in php_tidy_quick_repair (ht=1, return_value=0x83f3bec, 
this_ptr=0x0, return_value_used=1, is_file=0 '\0') at 
/home/martin/cvs/php-src/ext/tidy/tidy.c:432
#1  0x0820ef5d in zif_tidy_repair_string (ht=1, return_value=0x83f3bec, 
this_ptr=0x0, return_value_used=1) at 
/home/martin/cvs/php-src/ext/tidy/tidy.c:1126
#2  0x082a167c in zend_do_fcall_common_helper (execute_data=0xbfffd6bc, 
opline=0x8404d88, op_array=0x840052c) at 
/home/martin/cvs/php-src/Zend/zend_execute.c:2699
#3  0x082a1e49 in zend_do_fcall_handler (execute_data=0xbfffd6bc, 
opline=0x8404d88, op_array=0x840052c) at 
/home/martin/cvs/php-src/Zend/zend_execute.c:2828
#4  0x0829d5bb in execute (op_array=0x840052c) at 
/home/martin/cvs/php-src/Zend/zend_execute.c:1391
#5  0x08276cb4 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at 
/home/martin/cvs/php-src/Zend/zend.c:1061
#6  0x0822aebf in php_execute_script (primary_file=0xba60) at 
/home/martin/cvs/php-src/main/main.c:1627
#7  0x082ac20f in main (argc=3, argv=0xbae4) at 
/home/martin/cvs/php-src/sapi/cli/php_cli.c:943







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

Bug #53537 [Asn->Fbk]: Phar not working on PHP-FPM

[fat]

Edit report at https://bugs.php.net/bug.php?id=53537&edit=1

 ID: 53537
 Updated by: f...@php.net
 Reported by:alexander dot over at koeln dot de
 Summary:Phar not working on PHP-FPM
-Status: Assigned
+Status: Feedback
 Type:   Bug
 Package:PHAR related
 Operating System:   Debian
 PHP Version:5.3.4
 Assigned To:fat
 Block user comment: N
 Private report: N

 New Comment:

Please try using this snapshot:

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

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

I made a test on the 5.3 branch and it works great.

The only thing it that .phar extensions were not authorized as default 
acception 
extension by FPM.

I fixed it. See http://svn.php.net/viewvc?view=revision&revision=319287

Can you please test on a snapshot ?


Previous Comments:

[2011-11-15 23:35:43] fel...@php.net

Jérôme, can you check it?


[2010-12-13 14:04:17] alexander dot over at koeln dot de

Description:

When try to run a .phar on PHP running as FPM, i got an endless redirect loop.

Test script:
---
setStub($p->createDefaultStub('stub.php', 'index.php'));
$p->addFromString('index.php', 'https://bugs.php.net/bug.php?id=53537&edit=1

Bug #54206 [Opn->Fbk]: Crash with empty user_ini.filename inside a [PATH] section

[felipe]

Edit report at https://bugs.php.net/bug.php?id=54206&edit=1

 ID: 54206
 Updated by: fel...@php.net
 Reported by:carsten_sttgt at gmx dot de
 Summary:Crash with empty user_ini.filename inside a [PATH]
 section
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:CGI/CLI related
 Operating System:   Windows
 PHP Version:5.3.5
 Block user comment: N
 Private report: N

 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:

[2011-03-09 16:24:25] carsten_sttgt at gmx dot de

Description:

The crash happens with PHP CGI if you are setting user_ini.filename inside a 
PATH section to none. The PATH section is for the current script.

This only happens with Windows. With *nix it's working as expected.

In addition, this only happens with PHP5.3.5, but not with PHP5.3.6RC2 (see Bug 
#54204).


Test script:
---
adding this to "php.ini":
[PATH=C:/Users/Public/Documents/htdocs/]
user_ini.filename =
upload_max_filesize = 5M

And then accessing a phpinfo.php through CGI.




Expected result:

user_ini.filename   no value.user.ini
upload_max_filesize 5M  2M

Actual result:
--
php-cgi is crashing.







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

Bug #54057 [Opn->Bgs]: INI_SCANNER_RAW and parse_ini_file still doesnt return proper values

[felipe]

Edit report at https://bugs.php.net/bug.php?id=54057&edit=1

 ID: 54057
 Updated by: fel...@php.net
 Reported by:electroteque at gmail dot com
 Summary:INI_SCANNER_RAW and parse_ini_file still doesnt
 return proper values
-Status: Open
+Status: Bogus
 Type:   Bug
 Package:Filesystem function related
 Operating System:   OSX 10.6
 PHP Version:5.3.5
 Block user comment: N
 Private report: N

 New Comment:

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

To reach what you want, you need to use:

package[prop1] = true
package[prop2] = 100


Previous Comments:

[2011-02-21 02:55:28] electroteque at gmail dot com

Description:

An ini config with values like

package.prop1 = true
package.prop2 = 100

Are supposed to be returned as boolean and numbers but are not. 

This is a bit of an oversight perhaps ? 

Your bug system is also buggy, I clicked submit it tried to bring up a list of 
bug 
reports, and it removes the package affected selection and the captcha has to 
be 
put back in. 

Test script:
---
$iniArray = parse_ini_file($filename, true, INI_SCANNER_RAW);

Expected result:

array(1) {
  ["package"]=>
  array(2) {
["prop1"]=>
bool(true)
["prop2"]=>
int(100)
  }
}

Actual result:
--
array(2) {
  ["prop1"]=>
  string(4) "true"
  ["prop2"]=>
  string(3) "100"
}






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

Bug #53537 [Opn->Asn]: Phar not working on PHP-FPM

[felipe]

Edit report at https://bugs.php.net/bug.php?id=53537&edit=1

 ID: 53537
 Updated by: fel...@php.net
 Reported by:alexander dot over at koeln dot de
 Summary:Phar not working on PHP-FPM
-Status: Open
+Status: Assigned
 Type:   Bug
 Package:PHAR related
 Operating System:   Debian
 PHP Version:5.3.4
-Assigned To:
+Assigned To:fat
 Block user comment: N
 Private report: N

 New Comment:

Jérôme, can you check it?


Previous Comments:

[2010-12-13 14:04:17] alexander dot over at koeln dot de

Description:

When try to run a .phar on PHP running as FPM, i got an endless redirect loop.

Test script:
---
setStub($p->createDefaultStub('stub.php', 'index.php'));
$p->addFromString('index.php', 'https://bugs.php.net/bug.php?id=53537&edit=1

Bug #47154 [Opn->Bgs]: Object properties unset after setting.

[felipe]

Edit report at https://bugs.php.net/bug.php?id=47154&edit=1

 ID: 47154
 Updated by: fel...@php.net
 Reported by:onerax at gmail dot com
 Summary:Object properties unset after setting.
-Status: Open
+Status: Bogus
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Windows
-PHP Version:6CVS-2009-01-19 (snap)
+PHP Version:5.3
 Block user comment: N
 Private report: N

 New Comment:

Thank you for taking the time to report a problem with PHP.
Unfortunately you are not using a current version of PHP -- 
the problem might already be fixed. Please download a new
PHP version from http://www.php.net/downloads.php

If you are able to reproduce the bug with one of the latest
versions of PHP, please change the PHP version on this bug report
to the version you tested and change the status back to "Open".
Again, thank you for your continued support of PHP.




Previous Comments:

[2009-01-21 22:21:16] onerax at gmail dot com

I've found a workaround for this problem.

Using extract($Data) I was able to assign $User->Password to the 
resulting $Password variable and get the correct value in place.


[2009-01-20 23:12:05] onerax at gmail dot com

It also seems that if I set the values in the object manually - in 
the above example, $User->Password = 'notest', then the property is 
set. If I do the same to the array $Data, $Data['Password'] = 
'notest', It does not set the existing Password index, rather it 
creates a second Password index, which is shown in print_r below.

Array ( [EntityId] => USER_4974b612242741.58553835 [Password] => test 
[LastLogin] => [LastIp] => [Name] => test [Description] => [Updated] 
=> [Created] => 2009-01-19 17:19:14 [Parent] => [Owner] => [UserId] 
=> USER_4974b612242741.58553835 [FirstName] => [MiddleName] => 
[LastName] => [Avatar] => [Alias] => [Gender] => [Signature] => 
[Password] => notest ) 111Page Generation Time:: 0.09224 seconds

A single array with two "Password" entries...strange, yes? =)


[2009-01-20 16:51:28] onerax at gmail dot com

Here's a section of the actual code piece, and the output of all 
involved variables after the routine.

CODE::
Password = $Data['Password'];
$User->LastLogin= $Data['LastLogin'];
$User->LastIp   = $Data['LastIp'];

require_once('./Core/Entities/Profile.class.php');
$User->Profile  = new 
\xBB\Entities\Profile();
$User->Profile->UserId  = $Data['EntityId'];

$this->Database->Profiles->Fill($User->Profile, 
$Data);
if(sizeof($Data)>1){
die(print_r($User).print_r($User-
>Profile).print_r($Data));
}
}
...


OUTPUT::
xBB\Entities\User Object ( [Password] => [LastLogin] => [Profile] => 
xBB\Entities\Profile Object ( [UserId] => [FirstName] => [MiddleName] 
=> [LastName] => [Avatar] => [Alias] => [Gender] => [Signature] => ) 
[LastIp] => [EntityId] => [Name] => [Description] => [Updated] => 
[Created] => [Parent] => [Owner] => ) xBB\Entities\Profile Object ( 
[UserId] => [FirstName] => [MiddleName] => [LastName] => [Avatar] => 
[Alias] => [Gender] => [Signature] => ) Array ( [EntityId] => 
USER_4974b612242741.58553835 [Password] => test [LastLogin] => 
[LastIp] => [Name] => test [Description] => [Updated] => [Created] => 
2009-01-19 17:19:14 [Parent] => [Owner] => [UserId] => 
USER_4974b612242741.58553835 [FirstName] => [MiddleName] => 
[LastName] => [Avatar] => [Alias] => [Gender] => [Signature] => ) 
111Page Generation Time:: 0.093775 seconds


[2009-01-19 21:16:35] onerax at gmail dot com

Description:

After setting object properties on one line, object is still empty on 
the next. Inheritance, multiple namespaces, and passing arrays by 
reference are involved.





Reproduce code:
---
http://helios-emu.org/arraytest.txt

keep in mind this is not the actual code, and does not reproduce the problem by 
itself. To reproduce the problem you have to separate each class into a 
separate file and separate them out into two separate namespaces. I have the 
original code that I uncovered this in and can e-mail it upon a developer's 
request, but I will not make it public.

Expected result:

The object in which the properties are set contain data.

Actual result:
--
The object in which the properties are set do not contain data.






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

Req #60199 [Fbk->Csd]: enhance FPM error log when the primary script can't be open

[fat]

Edit report at https://bugs.php.net/bug.php?id=60199&edit=1

 ID: 60199
 Updated by: f...@php.net
 Reported by:julien at palard dot fr
-Summary:php-fpm does not log an error for "too many open
 files"
+Summary:enhance FPM error log when the primary script can't
 be open
-Status: Feedback
+Status: Closed
 Type:   Feature/Change Request
 Package:FPM related
 Operating System:   All
 PHP Version:Irrelevant
 Assigned To:fat
 Block user comment: N
 Private report: N

 New Comment:

This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.

 For Windows:

http://windows.php.net/snapshots/
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:

[2011-11-15 22:29:50] f...@php.net

Automatic comment from SVN on behalf of fat
Revision: http://svn.php.net/viewvc/?view=revision&revision=319281
Log: - FR #60199 (enhance FPM error log when the primary script can't be open)


[2011-11-02 13:40:13] f...@php.net

Can you please test the attached patch and confirm it fixes your problem.

Then reopen the bug.

++ Jerome


[2011-11-02 13:39:04] f...@php.net

The following patch has been added/updated:

Patch Name: fpm-bug60199.patch
Revision:   1320241144
URL:
https://bugs.php.net/patch-display.php?bug=60199&patch=fpm-bug60199.patch&revision=1320241144


[2011-11-02 08:56:18] julien at palard dot fr

Description:

When php-fpm hits a "too many open files", it returns a 404 and don't log 
anything, so typically for people using nginx they got a "No input file 
specified." that is hard to debug.

I dropped an strace here :
http://pastebin.com/PVCqF9cD

I think that php-fpm should log something to let people diagnose why they open 
so much file and/or modify their rlimit.








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

Bug #60310 [Opn]: UTF-8 to ISO-8859-1 conversion of a string segfaults

[dkelsey at bstage dot ca]

Edit report at https://bugs.php.net/bug.php?id=60310&edit=1

 ID: 60310
 User updated by:dkelsey at bstage dot ca
 Reported by:dkelsey at bstage dot ca
 Summary:UTF-8 to ISO-8859-1 conversion of a string segfaults
 Status: Open
 Type:   Bug
 Package:ICONV related
 Operating System:   Solaris 10
 PHP Version:5.3.8
 Block user comment: N
 Private report: N

 New Comment:

Whether I use $text = utf8_encode("Dave Kelsey"); or not makes no difference


Previous Comments:

[2011-11-15 21:48:07] dkelsey at bstage dot ca

Description:

using iconv() within a php script segfaults when converting a UTF-8 string to 
ISO-8859-1

I downloaded and compiled gnu libiconv-1.14 into /opt/local

My php configure 

./configure  '--prefix=/opt/bstage/php5.3.8' \
'--with-apxs2=/opt/bstage/apache2.2.21-php/bin/apxs' \
'--enable-bcmath' \
'--enable-mbstring' \
'--with-zlib' \
'--with-config-file-path=/opt/bstage/php5.3.8/lib' \
'--with-xsl' \
'--with-xmlrpc' \
'--with-regex=system' \
'--without-sqlite' \
'--disable-posix' \
'--enable-dom' \
'--disable-pdo' \
'--enable-xml' \
'--with-libxml-dir=/opt/local' \
'--enable-ipv6' \
'--host=i386-sun-solaris2' \
'--mandir=/opt/local/man' \
'--with-gd' \
'--with-mysql=/opt/mysql-5.5.8-solaris10-i386' \
'--with-mysqli=/opt/mysql-5.5.8-solaris10-i386/bin/mysql_config' \
'--with-curl=/opt/local' \
'--enable-debug'


ldd php
libexslt.so.0 => /usr/lib/libexslt.so.0
libresolv.so.2 =>/lib/libresolv.so.2
libmysqlclient.so.16 =>  
/opt/mysql-5.5.8-solaris10-i386/lib/libmysqlclient.so.16
libiconv.so.2 => /opt/local/lib/libiconv.so.2
libpng12.so.0 => /usr/lib/libpng12.so.0
libz.so.1 => /usr/lib/libz.so.1
librt.so.1 =>/lib/librt.so.1
libm.so.2 => /lib/libm.so.2
libnsl.so.1 =>   /lib/libnsl.so.1
libsocket.so.1 =>/lib/libsocket.so.1
libxml2.so.2 =>  /usr/lib/libxml2.so.2
libcurl.so.4 =>  /opt/local/lib/libcurl.so.4
libssl.so.0.9.7 =>   /usr/sfw/lib/libssl.so.0.9.7
libcrypto.so.0.9.7 =>/usr/sfw/lib/libcrypto.so.0.9.7
libldap.so.5 =>  /usr/lib/libldap.so.5
libdl.so.1 =>/lib/libdl.so.1
libthread.so.1 =>/lib/libthread.so.1
libxslt.so.1 =>  /usr/lib/libxslt.so.1
libc.so.1 => /lib/libc.so.1
libpthread.so.1 =>   /lib/libpthread.so.1
libgcc_s.so.1 => /usr/sfw/lib/libgcc_s.so.1
libaio.so.1 =>   /lib/libaio.so.1
libmd.so.1 =>/lib/libmd.so.1
libmp.so.2 =>/lib/libmp.so.2
libscf.so.1 =>   /lib/libscf.so.1
libsasl.so.1 =>  /usr/lib/libsasl.so.1
libnspr4.so =>   /usr/lib/mps/libnspr4.so
libplc4.so =>/usr/lib/mps/libplc4.so
libnss3.so =>/usr/lib/mps/libnss3.so
libssl3.so =>/usr/lib/mps/libssl3.so
libdoor.so.1 =>  /lib/libdoor.so.1
libuutil.so.1 => /lib/libuutil.so.1
libgen.so.1 =>   /lib/libgen.so.1
libsoftokn3.so =>/usr/lib/mps/libsoftokn3.so
libplds4.so =>   /usr/lib/mps/libplds4.so
libbsm.so.1 =>   /lib/libbsm.so.1
libsecdb.so.1 => /lib/libsecdb.so.1
libtsol.so.2 =>  /lib/libtsol.so.2
libcmd.so.1 =>   /lib/libcmd.so.1
libssl_extra.so.0.9.7 => /usr/sfw/lib/libssl_extra.so.0.9.7
libcrypto_extra.so.0.9.7 =>  /usr/sfw/lib/libcrypto_extra.so.0.9.7

I've used truss and gdb and get a segfault.

Test script:
---




Expected result:

Original : Dave Kelsey
Plain: Dave Kelsey

Actual result:
--
./php -ef iconv.php
Original : Dave Kelsey
Plain: Segmentation Fault (core dumped)

Note: the parsing of the string takes about 3-4 seconds?

gdb ./php -c core
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 "i386-pc-solaris2.9"...
Reading symbols from /opt/local/lib/libexslt.so.0...done.
Loaded symbols for /opt/local/lib/libexslt.so.0
Reading symbols from /opt/local/lib/libgcrypt.so.11...done.
Loaded symbols for /opt/local/lib/libgcrypt.so.11
Reading symbols from /opt/local/lib/libgpg-error.so.0...done.
Loaded symbols for /opt/local/lib/libgpg-error.so.0
Reading symbols from /lib/libsocket.so.1...done.
Loaded symbols for /lib/libsocket.so.1
Reading symbols from /lib/libnsl.so.1...done.
Loaded s

[PHP-BUG] Bug #60310 [NEW]: UTF-8 to ISO-8859-1 conversion of a string segfaults

[dkelsey at bstage dot ca]

From: 
Operating system: Solaris 10
PHP version:  5.3.8
Package:  ICONV related
Bug Type: Bug
Bug description:UTF-8 to ISO-8859-1 conversion of a string segfaults

Description:

using iconv() within a php script segfaults when converting a UTF-8 string
to ISO-8859-1

I downloaded and compiled gnu libiconv-1.14 into /opt/local

My php configure 

./configure  '--prefix=/opt/bstage/php5.3.8' \
'--with-apxs2=/opt/bstage/apache2.2.21-php/bin/apxs' \
'--enable-bcmath' \
'--enable-mbstring' \
'--with-zlib' \
'--with-config-file-path=/opt/bstage/php5.3.8/lib' \
'--with-xsl' \
'--with-xmlrpc' \
'--with-regex=system' \
'--without-sqlite' \
'--disable-posix' \
'--enable-dom' \
'--disable-pdo' \
'--enable-xml' \
'--with-libxml-dir=/opt/local' \
'--enable-ipv6' \
'--host=i386-sun-solaris2' \
'--mandir=/opt/local/man' \
'--with-gd' \
'--with-mysql=/opt/mysql-5.5.8-solaris10-i386' \
'--with-mysqli=/opt/mysql-5.5.8-solaris10-i386/bin/mysql_config' \
'--with-curl=/opt/local' \
'--enable-debug'


ldd php
libexslt.so.0 => /usr/lib/libexslt.so.0
libresolv.so.2 =>/lib/libresolv.so.2
libmysqlclient.so.16 => 
/opt/mysql-5.5.8-solaris10-i386/lib/libmysqlclient.so.16
libiconv.so.2 => /opt/local/lib/libiconv.so.2
libpng12.so.0 => /usr/lib/libpng12.so.0
libz.so.1 => /usr/lib/libz.so.1
librt.so.1 =>/lib/librt.so.1
libm.so.2 => /lib/libm.so.2
libnsl.so.1 =>   /lib/libnsl.so.1
libsocket.so.1 =>/lib/libsocket.so.1
libxml2.so.2 =>  /usr/lib/libxml2.so.2
libcurl.so.4 =>  /opt/local/lib/libcurl.so.4
libssl.so.0.9.7 =>   /usr/sfw/lib/libssl.so.0.9.7
libcrypto.so.0.9.7 =>/usr/sfw/lib/libcrypto.so.0.9.7
libldap.so.5 =>  /usr/lib/libldap.so.5
libdl.so.1 =>/lib/libdl.so.1
libthread.so.1 =>/lib/libthread.so.1
libxslt.so.1 =>  /usr/lib/libxslt.so.1
libc.so.1 => /lib/libc.so.1
libpthread.so.1 =>   /lib/libpthread.so.1
libgcc_s.so.1 => /usr/sfw/lib/libgcc_s.so.1
libaio.so.1 =>   /lib/libaio.so.1
libmd.so.1 =>/lib/libmd.so.1
libmp.so.2 =>/lib/libmp.so.2
libscf.so.1 =>   /lib/libscf.so.1
libsasl.so.1 =>  /usr/lib/libsasl.so.1
libnspr4.so =>   /usr/lib/mps/libnspr4.so
libplc4.so =>/usr/lib/mps/libplc4.so
libnss3.so =>/usr/lib/mps/libnss3.so
libssl3.so =>/usr/lib/mps/libssl3.so
libdoor.so.1 =>  /lib/libdoor.so.1
libuutil.so.1 => /lib/libuutil.so.1
libgen.so.1 =>   /lib/libgen.so.1
libsoftokn3.so =>/usr/lib/mps/libsoftokn3.so
libplds4.so =>   /usr/lib/mps/libplds4.so
libbsm.so.1 =>   /lib/libbsm.so.1
libsecdb.so.1 => /lib/libsecdb.so.1
libtsol.so.2 =>  /lib/libtsol.so.2
libcmd.so.1 =>   /lib/libcmd.so.1
libssl_extra.so.0.9.7 =>
/usr/sfw/lib/libssl_extra.so.0.9.7
libcrypto_extra.so.0.9.7 => 
/usr/sfw/lib/libcrypto_extra.so.0.9.7

I've used truss and gdb and get a segfault.

Test script:
---




Expected result:

Original : Dave Kelsey
Plain: Dave Kelsey

Actual result:
--
./php -ef iconv.php
Original : Dave Kelsey
Plain: Segmentation Fault (core dumped)

Note: the parsing of the string takes about 3-4 seconds?

gdb ./php -c core
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 "i386-pc-solaris2.9"...
Reading symbols from /opt/local/lib/libexslt.so.0...done.
Loaded symbols for /opt/local/lib/libexslt.so.0
Reading symbols from /opt/local/lib/libgcrypt.so.11...done.
Loaded symbols for /opt/local/lib/libgcrypt.so.11
Reading symbols from /opt/local/lib/libgpg-error.so.0...done.
Loaded symbols for /opt/local/lib/libgpg-error.so.0
Reading symbols from /lib/libsocket.so.1...done.
Loaded symbols for /lib/libsocket.so.1
Reading symbols from /lib/libnsl.so.1...done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/libm.so.2...done.
Loaded symbols for /lib/libm.so.2
Reading symbols from /lib/libresolv.so.2...done.
Loaded symbols for /lib/libresolv.so.2
Reading symbols from
/opt/mysql/mysql-5.5.16/lib/libmysqlclient.so.18...done.
Loaded symbols for /opt/mysql/mysql-5.5.16//lib/libmysqlclient.so.18
Reading symbols from /opt/local/lib/libfreetype.so.6...done.
Loaded symbols for /opt/local/lib/libfreetype.so.6
Reading symbols from /opt/local/u

Bug #60278 [Opn->Bgs]: BC Break + warning in array_diff with nested arrays

[rasmus]

Edit report at https://bugs.php.net/bug.php?id=60278&edit=1

 ID: 60278
 Updated by: ras...@php.net
 Reported by:kontakt at beberlei dot de
 Summary:BC Break + warning in array_diff with nested arrays
-Status: Open
+Status: Bogus
 Type:   Bug
 Package:Arrays related
 PHP Version:5.4.0RC1
 Block user comment: N
 Private report: N

 New Comment:

This isn't a BC break. This is a NOTICE telling you that your code isn't doing 
what you think it is. As per the array_diff() docs:

"This function only checks one dimension of a n-dimensional array."

Change your example to this:

$a = [0 => ["foo"]];
$b = [0 => ["bar"]];
$d = array_diff($a, $b);

This comes back and tells you that the arrays are identical. But they obviously 
aren't. Or even worse:

$a = [0 => "Array"];
$b = [0 => ["bar"]];
$d = array_diff($a, $b);

This also comes back with no difference between $a and $b exactly because the 
function only checks one level deep and you are passing it multi-dimensional 
arrays. Notices like this are there to tell you when you are doing something 
that might not produce the results you are expecting, and this is a very 
obvious 
example of that.


Previous Comments:

[2011-11-15 00:55:51] fel...@php.net

The difference is only the E_NOTICE message, the code behaves in the sameway.


[2011-11-12 09:55:34] kontakt at beberlei dot de

Description:

A warning occurs when you call array_diff with one nested and one flat array. 
This code worked on 5.3.

Test script:
---
 "id");
$b = array(0 => array("foo" => "bar"));

$d = array_diff($a, $b);

var_dump($d);

Expected result:

array(1) {
  [0]=>
  string(2) "id"
}


Actual result:
--
Notice: Array to string conversion in /home/benny/code/php/tests/array_diff.php 
on line 6
array(1) {
  [0]=>
  string(2) "id"
}







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

Bug #43676 [Opn->Bgs]: SQL error SQL0644N

[felipe]

Edit report at https://bugs.php.net/bug.php?id=43676&edit=1

 ID: 43676
 Updated by: fel...@php.net
 Reported by:antkozh at gmail dot com
 Summary:SQL error SQL0644N
-Status: Open
+Status: Bogus
 Type:   Bug
 Package:ODBC related
 Operating System:   SLES 9
 PHP Version:5.2.5
 Block user comment: N
 Private report: N

 New Comment:

Thank you for taking the time to report a problem with PHP.
Unfortunately you are not using a current version of PHP -- 
the problem might already be fixed. Please download a new
PHP version from http://www.php.net/downloads.php

If you are able to reproduce the bug with one of the latest
versions of PHP, please change the PHP version on this bug report
to the version you tested and change the status back to "Open".
Again, thank you for your continued support of PHP.




Previous Comments:

[2007-12-26 01:25:35] antkozh at gmail dot com

Description:

Sorry for my poor english. I have SLES9 and installed Apache2.2.0 + php5.2.5 
(cli)+ unixODBC 2.2.11 + IBM DB2 V8.1 Developer Client.
odbc_connection() - function normally. But when i'm trying to eecute query I 
have an error:

Warning: odbc_exec() [function.odbc-exec]: SQL error: [unixODBC][IBM][CLI 
Driver][DB2/NT] SQL0644N Invalid value specified for keyword "CONCURRENCY" in 
statement "". SQLSTATE=42615 , SQL state 42615 in 
SQLExecDirect in /srv/www/htdocs/dc.php on line 3

Line 3 in dc.php is

$cur=odbc_exec($conn,"select DEPO from VUSKPL");

What does it mean?







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

Bug #60287 [Opn->Dup]: Dollar sign missing variable in memcache.php

[rasmus]

Edit report at https://bugs.php.net/bug.php?id=60287&edit=1

 ID: 60287
 Updated by: ras...@php.net
 Reported by:admin at yqed dot com
 Summary:Dollar sign missing variable in memcache.php
-Status: Open
+Status: Duplicate
 Type:   Bug
 Package:memcache
 Operating System:   CentOS 5.7
 PHP Version:5.3.8
 Block user comment: N
 Private report: N

 New Comment:

It appears this was fixed in SVN over 7 months ago:

http://svn.php.net/viewvc/pecl/memcache/trunk/memcache.php?view=log


Previous Comments:

[2011-11-14 00:33:40] admin at yqed dot com

Description:

Latest 3.0.6 beta:

function get_host_port_from_server($server){
$values = explode(':', $server);
if (($values[0] == 'unix') && (!is_numeric( $values[1]))) {
return array($server, 0);
}
else {
return values;
}
}

The dollar sign is missing on returned values, it should be $values.








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

Bug #53595 [Opn->Fbk]: soap client can't handle 'any' element in wsdl schema

[felipe]

Edit report at https://bugs.php.net/bug.php?id=53595&edit=1

 ID: 53595
 Updated by: fel...@php.net
 Reported by:alex at liokumovich dot com
 Summary:soap client can't handle 'any' element in wsdl
 schema
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:SOAP related
 Operating System:   Linux
 PHP Version:5.2.16
 Block user comment: N
 Private report: N

 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-12-22 22:53:22] alex at liokumovich dot com

Description:

if WSDL schema contain 'any' element soap client failed


part of wsdl schema:
wsdl:definitions targetNamespace="url">
The Webservice for Saving Orders


















Test script:
---
$url = 'url?wsdl';
$params = array(
'xmlOrder'  => 
 array(
'OrderInfo' => array( 
'OrderId'=> ,
)
 )
  )

$client = new SoapClient($url, array('soap_version'   => SOAP_1_2));
//changing soap version doesn't reflect result
$client->__getFunctions();
$result = $client->SaveOrder($params);

Expected result:

result from web service call

Actual result:
--
Fatal error: Uncaught SoapFault exception: [Sender] SOAP-ERROR: Encoding: 
object 
hasn't 'any' property in /xxx/script.php:78 Stack trace: #0 
/xxx/script.php(78): 
SoapClient->__call('SaveOrder', Array) #1 /xxx/script.php(78): SoapClient-
>SaveOrder(Array) #2 {main} thrown in /xxx/script.php on line 78






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

Bug #60292 [Opn->Fbk]: System checks for available hashes

[rasmus]

Edit report at https://bugs.php.net/bug.php?id=60292&edit=1

 ID: 60292
 Updated by: ras...@php.net
 Reported by:pgajdos at suse dot cz
 Summary:System checks for available hashes
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:hash related
 Operating System:   Linux
 PHP Version:5.3.8
 Block user comment: N
 Private report: N

 New Comment:

That's a really ugly patch with lots of lines that don't appear to actually 
change anything. Please ignore whitespace changes when you generate your 
patches.


Previous Comments:

[2011-11-14 09:26:35] pgajdos at suse dot cz

Description:

Hi,

while trying to build php that uses system's crypt(), I had to change 
ext/standard/config.m4 a little bit, see patch I enclosed.

Expected result:

php using system's crypt() when it provides all algorithms as php's 
implementation (as http://php.net/manual/en/function.crypt.php says).







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

Bug #60290 [Opn->Bgs]: Apc.php – Wrong use of var_export

[rasmus]

Edit report at https://bugs.php.net/bug.php?id=60290&edit=1

 ID: 60290
 Updated by: ras...@php.net
 Reported by:klaus-martin dot hansche at kvberlin dot de
 Summary:Apc.php – Wrong use of var_export
-Status: Open
+Status: Bogus
 Type:   Bug
 Package:APC
 Operating System:   Irrelevant
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

var_export($var, true) is quite valid and tells var_export to return the 
exported 
string instead of outputting it. See http://php.net/var_export


Previous Comments:

[2011-11-14 06:57:45] klaus-martin dot hansche at kvberlin dot de

Description:

Apc.php line 1000 should be
$output = var_export(apc_fetch($entry[$fieldkey]));
instead of
$output = var_export(apc_fetch($entry[$fieldkey]),true);
The last parameter of var_export is a reference to a boolean var.







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

Bug #60308 [Opn->Csd]: Buld fails against PHP-5.4.0RC2-dev

[rasmus]

Edit report at https://bugs.php.net/bug.php?id=60308&edit=1

 ID: 60308
 Updated by: ras...@php.net
 Reported by:fedora at famillecollet dot com
 Summary:Buld fails against PHP-5.4.0RC2-dev
-Status: Open
+Status: Closed
 Type:   Bug
 Package:gmagick
 Operating System:   GNU/Linux (Fedora 15)
 PHP Version:5.4.0RC1
-Assigned To:
+Assigned To:rasmus
 Block user comment: N
 Private report: N

 New Comment:

This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.

 For Windows:

http://windows.php.net/snapshots/
 
Thank you for the report, and for helping us make PHP better.

This should have been reported in the pecl bug tracker, but I have applied your 
patch and added the tests to the package.xml file so the next release will 
include the tests.


Previous Comments:

[2011-11-15 20:42:01] ras...@php.net

Automatic comment from SVN on behalf of rasmus
Revision: http://svn.php.net/viewvc/?view=revision&revision=319272
Log: Include the tests directory as well. Closes bug #60308


[2011-11-15 17:31:19] fedora at famillecollet dot com

Can't you please also provides the "tests" folder in the released tarball (for 
the next version) ?


[2011-11-15 17:29:44] fedora at famillecollet dot com

Description:

gmagick 1.0.9b1 don't build against latest PHP 5.4.0 snapshot.

Attached patch solves the various issues

All tests run fine
(except gmagick-006-annotateimage because of not available font)







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

Bug #55874 [Opn->Csd]: GCC does not provide __sync_fetch_and_add on some archs

[felipe]

Edit report at https://bugs.php.net/bug.php?id=55874&edit=1

 ID: 55874
 Updated by: fel...@php.net
 Reported by:klightspeed at netspace dot net dot au
 Summary:GCC does not provide __sync_fetch_and_add on some
 archs
-Status: Open
+Status: Closed
 Type:   Bug
 Package:Compile Failure
 Operating System:   Linux
 PHP Version:trunk-SVN-2011-10-08 (SVN)
-Assigned To:
+Assigned To:felipe
 Block user comment: N
 Private report: N

 New Comment:

This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.

 For Windows:

http://windows.php.net/snapshots/
 
Thank you for the report, and for helping us make PHP better.

Thanks for the patch!


Previous Comments:

[2011-11-15 20:33:17] fel...@php.net

Automatic comment from SVN on behalf of felipe
Revision: http://svn.php.net/viewvc/?view=revision&revision=319271
Log: - Fixed bug #55874 (GCC does not provide __sync_fetch_and_add on some 
archs)
  patch by: klightspeed at netspace dot net dot au


[2011-10-08 15:48:25] klightspeed at netspace dot net dot au

Description:

Compilation currently fails on architectures without support for interlocked 
add, compare and swap, or a kernel cmpxchg helper, which includes:
  * PA-RISC with anything other than Linux
  * SPARCv7 and lower
  * ARM with GCC < 4.3
  * ARMv5 and lower with anything other than Linux
  * MIPS1

ext/standard/php_crypt_r.c currently tries to use __sync_fetch_and_add when the 
compiler is at least GCC 4.1.2 and the OS is neither HP-UX nor HP-PA.

Realistically, it should check that __sync_fetch_and_add is actually provided 
by the compiler.








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

Bug #55349 [Opn->Csd]: Corrupted referenced strings inside Closure

[felipe]

Edit report at https://bugs.php.net/bug.php?id=55349&edit=1

 ID: 55349
 Updated by: fel...@php.net
 Reported by:roeitell at gmail dot com
 Summary:Corrupted referenced strings inside Closure
-Status: Open
+Status: Closed
 Type:   Bug
-Package:Variables related
+Package:Scripting Engine problem
 Operating System:   Linux
 PHP Version:5.3.6
-Assigned To:
+Assigned To:felipe
 Block user comment: N
 Private report: N

 New Comment:

This bugs already has been fixed. Thanks.


Previous Comments:

[2011-08-02 16:09:49] roeitell at gmail dot com

Description:

This is a bug in 5.3.6, which did not occur in 5.3.5. When executing a Closure, 
and using a variable which references a string property of the context class, 
the 
original string property becomes corrupted. Its first characters become 
corrupted, 
resulting in an unexpected new string.
(Tested on several CentOS machines; 5.3.6 results in the bug, 5.3.5 does not)

Step-by-step recreation: (code sample attached)
1. Define a string property in a class.
2. Define a Closure which accepts a parameter.
3. Execute that Closure, passing a parameter which is a reference to the 
original 
string property.
4. The original string property becomes corrupted. If you var_dump() it, you 
receive a corrupted string instead of your original string.

Test script:
---
class Foo
{
public function __construct()
{
$this->a = 'foo';
}
public function bug()
{
$a = &$this->a;
$b = function()use($a){
return strlen($a);
};
$b();
}
}
 
$foo = new Foo();
$foo->bug();
var_dump($foo->a);

Expected result:

String(3) "foo"  (this happens in 5.3.5)


Actual result:
--
String(...) "{some_rubbish}oo"  (this happens in 5.3.6)






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

[PHP-BUG] Bug #60309 [NEW]: fread(STDIN, 1024) returns instantly.

[Dygear at gmail dot com]

From: 
Operating system: Windows 7 - CLI
PHP version:  5.4.0RC1
Package:  Streams related
Bug Type: Bug
Bug description:fread(STDIN, 1024) returns instantly.

Description:

I am using the windows version of PHP 5.4 (5.4.0RC1) from 2011-Nov-10
19:52:12, 
VC9 x86 Non Thread Safe. In 5.3.x the code worked to where I could query a
client 
for an input from the command line using fread and STDIN. In the version
stated, 
5.4.0RC1, the function returns right away, and does not give the user
anytime to 
input a string.

Test script:
---


Expected result:

I would expect for there be an opportunity for the user to input a string.

Actual result:
--
The script has no result, and the client is never queried for a string.

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

Bug #53734 [Opn->Fbk]: Crash with stacktrace

[felipe]

Edit report at https://bugs.php.net/bug.php?id=53734&edit=1

 ID: 53734
 Updated by: fel...@php.net
 Reported by:james dot green at mjog dot com
 Summary:Crash with stacktrace
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:ODBC related
 Operating System:   Windows XP SP3
 PHP Version:5.2.17
 Block user comment: N
 Private report: N

 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:

[2011-01-13 12:34:49] james dot green at mjog dot com

Description:

We have not yet identified what triggers this but one or more of our periodic 
jobs seems to crash when using sqlite as the data store.


Expected result:

If there's a problem an error should be handled.

Actual result:
--
Type of Analysis Performed   Crash Analysis 
Machine Name
Operating System   Windows XP Service Pack 3 
Number Of Processors
Process ID   1472 
Process Image   C:\Program Files\LightTPD\php\php-cgi.exe 
System Up-Time   3 day(s) 04:51:50 
Process Up-Time   00:00:08 


Thread 0 - System ID 2152
Entry point   php_cgi!mainCRTStartup 
Create time   13/01/2011 10:53:34 
Time spent in user mode   0 Days 0:0:0.171 
Time spent in kernel mode   0 Days 0:0:0.78 






Function Arg 1 Arg 2 Arg 3   Source 
msvcrt!strlen+20 fffd 00d33d18 008d
sqlite3odbc!SQLExecDirectW+7c 014fa8e0 00d33d18 fffd
odbc32!SQLSetStmtAttrW+47c 00d33d18 fffd 0001
odbc32!SQLExecDirectA+77 7435 00fc6eb8 fffd
php5ts!zif_odbc_exec+29b 00f1297c 00fbf3c8    
ext\odbc\php_odbc.c @ 1355 
php5ts!zend_do_fcall_common_helper_SPEC+7ab 00c0d928 003a3b00 
00f3d920   Zend\zend_vm_execute.h @ 200 + 3d 
php5ts!ZEND_DO_FCALL_SPEC_CONST_HANDLER+e5  003a3b08 
00f4388c   Zend\zend_vm_execute.h @ 1740 + e 
php5ts!execute+1c5 00f38a58 003a3b08 003a3b08   
Zend\zend_vm_execute.h @ 92 + c 
php5ts!zend_do_fcall_common_helper_SPEC+8ca 00c0d9d0 003a3b01 
1001c6f5   Zend\zend_vm_execute.h @ 235 
php5ts!ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER+15 00c0d9d0 003a3b08 
00f1edac   Zend\zend_vm_execute.h @ 322 + 11 
php5ts!execute+1c5 00f21b78 003a3b08 003a3b08   
Zend\zend_vm_execute.h @ 92 + c 
php5ts!zend_do_fcall_common_helper_SPEC+8ca 00c0da78 003a3b01 
1001c6f5   Zend\zend_vm_execute.h @ 235 
php5ts!ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER+15 00c0da78 003a3b08 
00c0db90   Zend\zend_vm_execute.h @ 322 + 11 
php5ts!execute+1c5 014ca9c8 003a3b08 00c0db34   
Zend\zend_vm_execute.h @ 92 + c 
php5ts!zend_do_fcall_common_helper_SPEC+8ca 00c0db34 003a3b01 
00f120b7   Zend\zend_vm_execute.h @ 235 
php5ts!ZEND_DO_FCALL_SPEC_CONST_HANDLER+e5  003a3b08 
003a3b08   Zend\zend_vm_execute.h @ 1740 + e 
php5ts!execute+1c5 00f1bb18 003a3b08    
Zend\zend_vm_execute.h @ 92 + c 
php5ts!zend_execute_scripts+107 0008 003a3b08    
Zend\zend.c @ 1135 
php5ts!php_execute_script+21d 00c0fedc 003a3b08 0010   
main\main.c @ 2036 + 12 
php_cgi!main+dcd 0002 003a3998 003a28a8   sapi\cgi\cgi_main.c @ 
1999 + b 
php_cgi!mainCRTStartup+e3 0010  7ffde000
kernel32!RegisterWaitForInputIdle+49 00406326  




MSVCRT!STRLEN+20WARNING - DebugDiag was not able to locate debug symbols for 
msvcrt.dll, so the information below may be incomplete.



In 
php-cgi__PID__1472__Date__01_13_2011__Time_10_53_42AM__124__Second_Chance_Exception_C005.dmp
 the assembly instruction at msvcrt!strlen+20 in C:\WINDOWS\system32\msvcrt.dll 
from Microsoft Corporation has caused an access violation exception 
(0xC005) when trying to read from memory location 0x01559000 on thread 0

Module Information 
Image Name: C:\WINDOWS\system32\msvcrt.dll   Symbol Type:  Export 
Base address: 0x77c1   Time Stamp:  Mon Apr 14 01:12:56 2008  
Checksum: 0x00057341   Comments:   
COM DLL: False   Company Name:  Microsoft Corporation 
ISAPIExtension: False   File Description:  Windows NT CRT DLL 
ISAPIFilter: False   File Version:  7.0.2600.5512 (xpsp.080413-2111) 
Managed DLL: False   Internal Name:  msvcrt.dll 
VB DLL: False   Legal Copyright:  © Microsoft Corporation. All rights 
reserved. 
Loaded Image Name:  msvcrt.dll   Legal Trademarks:   
Mapped Image Name: Original filename:  msvcrt.dll 
Module name:  msvcrt   Private Build:   
Single Threaded:  False   Product Name:  Microsoft® Windows® Operating System 
Module Size:  352.00 KBytes   Product Version:  7.0.2600.5512 
Symbol File Name:  msvcrt.dll   Special Build:  & 



--

Req #60305 [Com]: myClass::unset() keyword conflict

[francois dot dambrine at isen-lille dot fr]

Edit report at https://bugs.php.net/bug.php?id=60305&edit=1

 ID: 60305
 Comment by: francois dot dambrine at isen-lille dot fr
 Reported by:matty023 at gmail dot com
 Summary:myClass::unset() keyword conflict
 Status: Open
 Type:   Feature/Change Request
 Package:Scripting Engine problem
 PHP Version:5.4.0RC1
 Block user comment: N
 Private report: N

 New Comment:

This bug also happen in php 5.3.6 (ubuntu 11.10 default version).


Previous Comments:

[2011-11-15 02:19:37] matty023 at gmail dot com

Description:

While "keywords" and "language constructs" cannot be used as function names, I 
find myself with the need to have a function in my class named "unset", I also 
see that list is a very common and useful term.

After the introduction of classes and namespaces it's time to look at enabling 
usage of these common terms in classes and namespaces.



Test script:
---
https://bugs.php.net/bug.php?id=60305&edit=1

Bug #53275 [Opn->Bgs]: dynamic loading bug related with CVE-2010-3847

[felipe]

Edit report at https://bugs.php.net/bug.php?id=53275&edit=1

 ID: 53275
 Updated by: fel...@php.net
 Reported by:dr dot cyberowl at gmail dot com
 Summary:dynamic loading bug related with CVE-2010-3847
-Status: Open
+Status: Bogus
 Type:   Bug
 Package:Dynamic loading
 Operating System:   Linux
 PHP Version:5.3.3
 Block user comment: N
 Private report: N

 New Comment:

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.




Previous Comments:

[2010-11-09 10:46:42] dr dot cyberowl at gmail dot com

Description:

I'm running apache with setuid as root.
When I convert string from euc-kr to utf-8 through iconv, I met next message.
iconv(): Wrong charset, conversion from 'EUC-KR' to 'UTF-8' is now allowed

after some google. I found solution.
This problem caused by security patch on glibc ld.so dynamic linker.
http://www.securityfocus.com/bid/44154

glibc-2.11 and over has patched. so you can produce same results.

Test code

Here are some strace results.
1. with plain php cli binary
 CLIP -
futex(0xb73aca8c, FUTEX_WAKE_PRIVATE, 2147483647) = 0
open("/usr/lib/gconv/EUC-KR.so", O_RDONLY) = 3
read(3, 
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220\4\0\0004\0\0\0"..., 512) = 
512
fstat64(3, {st_mode=S_IFREG|0644, st_size=13624, ...}) = 0
mmap2(NULL, 12316, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0xb722f000
mmap2(0xb7231000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2) = 0xb7231000
close(3)= 0
open("/usr/lib/gconv/tls/i686/sse2/cmov/libKSC.so", O_RDONLY) = -1 ENOENT (No 
such file or directory)
stat64("/usr/lib/gconv/tls/i686/sse2/cmov", 0xbf9d912c) = -1 ENOENT (No such 
file or directory)
open("/usr/lib/gconv/tls/i686/sse2/libKSC.so", O_RDONLY) = -1 ENOENT (No such 
file or directory)
stat64("/usr/lib/gconv/tls/i686/sse2", 0xbf9d912c) = -1 ENOENT (No such file or 
directory)
open("/usr/lib/gconv/tls/i686/cmov/libKSC.so", O_RDONLY) = -1 ENOENT (No such 
file or directory)
stat64("/usr/lib/gconv/tls/i686/cmov", 0xbf9d912c) = -1 ENOENT (No such file or 
directory)
open("/usr/lib/gconv/tls/i686/libKSC.so", O_RDONLY) = -1 ENOENT (No such file 
or directory)
stat64("/usr/lib/gconv/tls/i686", 0xbf9d912c) = -1 ENOENT (No such file or 
directory)
open("/usr/lib/gconv/tls/sse2/cmov/libKSC.so", O_RDONLY) = -1 ENOENT (No such 
file or directory)
stat64("/usr/lib/gconv/tls/sse2/cmov", 0xbf9d912c) = -1 ENOENT (No such file or 
directory)
open("/usr/lib/gconv/tls/sse2/libKSC.so", O_RDONLY) = -1 ENOENT (No such file 
or directory)
stat64("/usr/lib/gconv/tls/sse2", 0xbf9d912c) = -1 ENOENT (No such file or 
directory)
open("/usr/lib/gconv/tls/cmov/libKSC.so", O_RDONLY) = -1 ENOENT (No such file 
or directory)
stat64("/usr/lib/gconv/tls/cmov", 0xbf9d912c) = -1 ENOENT (No such file or 
directory)
open("/usr/lib/gconv/tls/libKSC.so", O_RDONLY) = -1 ENOENT (No such file or 
directory)
stat64("/usr/lib/gconv/tls", 0xbf9d912c) = -1 ENOENT (No such file or directory)
open("/usr/lib/gconv/i686/sse2/cmov/libKSC.so", O_RDONLY) = -1 ENOENT (No such 
file or directory)
stat64("/usr/lib/gconv/i686/sse2/cmov", 0xbf9d912c) = -1 ENOENT (No such file 
or directory)
open("/usr/lib/gconv/i686/sse2/libKSC.so", O_RDONLY) = -1 ENOENT (No such file 
or directory)
stat64("/usr/lib/gconv/i686/sse2", 0xbf9d912c) = -1 ENOENT (No such file or 
directory)
open("/usr/lib/gconv/i686/cmov/libKSC.so", O_RDONLY) = -1 ENOENT (No such file 
or directory)
stat64("/usr/lib/gconv/i686/cmov", 0xbf9d912c) = -1 ENOENT (No such file or 
directory)
open("/usr/lib/gconv/i686/libKSC.so", O_RDONLY) = -1 ENOENT (No such file or 
directory)
stat64("/usr/lib/gconv/i686", 0xbf9d912c) = -1 ENOENT (No such file or 
directory)
open("/usr/lib/gconv/sse2/cmov/libKSC.so", O_RDONLY) = -1 ENOENT (No such file 
or directory)
stat64("/usr/lib/gconv/sse2/cmov", 0xbf9d912c) = -1 ENOENT (No such file or 
directory)
open("/usr/lib/gconv/sse2/libKSC.so", O_RDONLY) = -1 ENOENT (No such file or 
directory)
stat64("/usr/lib/gconv/sse2", 0xbf9d912c) = -1 ENOENT (No such file or 
directory)
open("/usr/lib/gconv/cmov/libKSC.so", O_RDONLY) = -1 ENOENT (No such file or 
directory)
stat64("/usr/lib/gconv/cmov", 0xbf9d912c) = -1 ENOENT (No such file or 
directory)
open("/usr/lib/gconv/libKSC.so", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0 \4\0\0004\0\0\0"..., 
512) = 512
fstat64(3, {st_mode=S_

Bug #53167 [Opn->Fbk]: phpinfo() Segmentation fault php as module in Apache2

[felipe]

Edit report at https://bugs.php.net/bug.php?id=53167&edit=1

 ID: 53167
 Updated by: fel...@php.net
 Reported by:schumacher dot cyrill at gmail dot com
 Summary:phpinfo() Segmentation fault php as module in
 Apache2
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:Apache2 related
 Operating System:   FreeBSD 8.1
 PHP Version:trunk-SVN-2010-10-26 (snap)
 Block user comment: N
 Private report: N

 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-10-26 15:49:20] schumacher dot cyrill at gmail dot com

CLI or CGI version is not affected!


[2010-10-26 15:36:44] schumacher dot cyrill at gmail dot com

Description:

A call of a simple  file will result in a segmentation fault 
with this PHP Version:
http://snaps.php.net/php-trunk-201010261230.tar.gz

A earlier php trunk version (~ one month ago) works properly ...

Test script:
---


Expected result:

A phpinfo site in the browser.

Actual result:
--
./configure --prefix=/usr/local/php6 --with-apxs2=/usr/local/httpd/bin/apxs 
--disable-cli --disable-cgi --with-config-file-path=/etc/php6 --disable-ipv6 
--disable-short-tags --with-openssl=/usr --with-pcre-regex --with-zlib 
--enable-bcmath --with-bz2 --enable-calendar --with-curl --with-libxml-dir 
--enable-exif --enable-filter --enable-ftp --with-openssl-dir=/usr --with-gd 
--with-png-dir=/usr --with-jpeg-dir=/usr --with-freetype-dir=/usr/local 
--enable-gd-native-ttf --with-gettext --with-mhash --enable-intl --with-mcrypt 
--with-mssql=/usr/local --with-mysql=/usr/bin/mysql_config --with-zlib-dir=/usr 
--with-mysqli=mysqlnd --with-pdo-dblib --with-pdo-mysql=mysqlnd --with-mm 
--enable-shmop --with-libxml-dir=/usr --enable-soap --with-libxml-dir=/usr 
--enable-sqlite-utf8 --enable-sysvmsg --enable-sysvsem --enable-sysvshm 
--enable-wddx --with-xsl=/usr/local --enable-zip --with-pear --enable-static 
--with-iconv --enable-dbase --enable-pcntl --with-pdo_sqlite --with-pspell 
--enable-sockets --with-icu-dir=/usr/local && make


schumach@fb1/home/sources# gdb /usr/local/httpd/bin/httpd
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...
(gdb) run -X
Starting program: /usr/local/httpd/bin/httpd -X
[New LWP 100085]
[New Thread 8016041c0 (LWP 100085)]
[Tue Oct 26 15:25:13 2010] [warn] (2)No such file or directory: Failed to 
enable the 'httpready' Accept Filter
[Tue Oct 26 15:25:13 2010] [warn] (2)No such file or directory: Failed to 
enable the 'dataready' Accept Filter

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 8016041c0 (LWP 100085)]
php_print_gpcse_array (name=0x802378394 "_SERVER", name_length=Variable 
"name_length" is not available.
) at /home/sources/php-trunk-201010261230/ext/standard/info.c:242
242 /home/sources/php-trunk-201010261230/ext/standard/info.c: No such file 
or directory.
in /home/sources/php-trunk-201010261230/ext/standard/info.c
(gdb) bt
#0  php_print_gpcse_array (name=0x802378394 "_SERVER", name_length=Variable 
"name_length" is not available.
) at /home/sources/php-trunk-201010261230/ext/standard/info.c:242
#1  0x0008021c698e in php_print_info (flag=-1) at 
/home/sources/php-trunk-201010261230/ext/standard/info.c:888
#2  0x0008021c71b8 in zif_phpinfo (ht=Variable "ht" is not available.
) at /home/sources/php-trunk-201010261230/ext/standard/info.c:1144
#3  0x0008022c1ce5 in zend_do_fcall_common_helper_SPEC 
(execute_data=0x801785050) at zend_vm_execute.h:638
#4  0x0008022c7d92 in execute (op_array=0x8017b78d0) at 
zend_vm_execute.h:410
#5  0x0008022912c1 in zend_execute_scripts (type=8, retval=0x0, 
file_count=3) at /home/sources/php-trunk-201010261230/Zend/zend.c:1195
#6  0x000802236287 in php_execute_script (primary_file=0x7fffe5a0) at 
/home/sources/php-trunk-201010261230/main/main.c:2331
#7  0x00080232f72e in php_handler (r=0x8061460a0) at 
/home/sources/php-trunk-201010261230/sapi/apache2handler/sapi_apache2.c:667
#8  0x0043d24a in ap_run_handler (r=0x8061460a0) at config.c:157
#9  0x00440472 in ap_invoke_handler (r=0x8061460a0) at config.c:376
#10 0x00462e1e in ap_process_request (r=0x8061460a0) at 
http_request.c:282
#11 0x00460218 in ap_process_http_connection (c=0x80613c290) at 
http_core.c:190
#12 0x

Bug #53072 [Opn->Fbk]: Pspell does not work with RoundCube

[felipe]

Edit report at https://bugs.php.net/bug.php?id=53072&edit=1

 ID: 53072
 Updated by: fel...@php.net
 Reported by:jeffshead at gmail dot com
 Summary:Pspell does not work with RoundCube
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:Pspell related
 Operating System:   Windows Server 2003
 PHP Version:5.2.14
 Block user comment: N
 Private report: N

 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-10-15 04:05:11] jeffshead at gmail dot com

Description:

Pspell does not work with PHP 5.2.14. I have tried swapping the DLL from 
5.2.13-5.2.10 but I get the same results. No errors. It just does nothing.

Tried with Apache 2.2.14-2.2.16

Works with PHP 5.2.6.







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

Bug #60244 [Opn->Csd]: pg_fetch_* functions behave strangely with row = -1

[iliaa]

Edit report at https://bugs.php.net/bug.php?id=60244&edit=1

 ID: 60244
 Updated by: il...@php.net
 Reported by:bandy dot chris at gmail dot com
 Summary:pg_fetch_* functions behave strangely with row = -1
-Status: Open
+Status: Closed
 Type:   Bug
 Package:PostgreSQL related
 Operating System:   Gentoo Linux
 PHP Version:5.3.8
-Assigned To:
+Assigned To:iliaa
 Block user comment: N
 Private report: N

 New Comment:

This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.

 For Windows:

http://windows.php.net/snapshots/
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:

[2011-11-15 18:02:48] il...@php.net

Automatic comment from SVN on behalf of iliaa
Revision: http://svn.php.net/viewvc/?view=revision&revision=319259
Log: Fixed bug #60244 (pg_fetch_* functions do not validate that row param is 
>0).


[2011-11-09 03:41:30] bandy dot chris at gmail dot com

I've attached a patch against PHP_5_3_8.


[2011-11-08 16:55:07] bandy dot chris at gmail dot com

Description:

pg_fetch_array(), pg_fetch_assoc(), pg_fetch_object() and pg_fetch_row() 
neglect to raise a warning when requesting $row = -1. In some cases, -1 is 
interpreted as though $row = NULL.

pg_fetch_result() is not affected.

Test script:
---

  string(1) "a"
}
PHP Warning:  pg_fetch_row(): Unable to jump to row -1 on PostgreSQL result 
index 7 in pgsql_bug.php on line 16

Warning: pg_fetch_row(): Unable to jump to row -1 on PostgreSQL result index 7 
in pgsql_bug.php on line 16
bool(false)
PHP Warning:  pg_fetch_row(): Unable to jump to row -1 on PostgreSQL result 
index 7 in pgsql_bug.php on line 17

Warning: pg_fetch_row(): Unable to jump to row -1 on PostgreSQL result index 7 
in pgsql_bug.php on line 17
bool(false)

Actual result:
--
array(1) {
  [0]=>
  string(1) "a"
}
array(1) {
  [0]=>
  string(1) "b"
}
PHP Warning:  pg_fetch_row(): Unable to jump to row -2 on PostgreSQL result 
index 6 in pgsql_bug.php on line 10

Warning: pg_fetch_row(): Unable to jump to row -2 on PostgreSQL result index 6 
in pgsql_bug.php on line 10
bool(false)
bool(false)
bool(false)
array(1) {
  [0]=>
  string(1) "a"
}
array(1) {
  [0]=>
  string(1) "a"
}
array(1) {
  [0]=>
  string(1) "b"
}






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

Bug #53123 [Opn->Csd]: fcgi_write buffer overflow when safe_write fail

[felipe]

Edit report at https://bugs.php.net/bug.php?id=53123&edit=1

 ID: 53123
 Updated by: fel...@php.net
 Reported by:NahumBao at gmail dot com
 Summary:fcgi_write buffer overflow when safe_write fail
-Status: Open
+Status: Closed
 Type:   Bug
 Package:CGI/CLI related
 Operating System:   Linux
 PHP Version:5.2.14
-Assigned To:
+Assigned To:felipe
 Block user comment: N
 Private report: N

 New Comment:

It seems already fixed.


Previous Comments:

[2010-10-21 07:29:20] NahumBao at gmail dot com

Description:

in fastcgi.c

1094 int fcgi_write(fcgi_request *req, fcgi_request_type type, const char *str, 
int len)
...

1165 int pos = 0;
1166 int pad;
1167 
1168 close_packet(req);
1169 while ((len - pos) > 0x) {
1170 open_packet(req, type);
1171 fcgi_make_header(req->out_hdr, type, req->id, 0xfff8);
1172 req->out_hdr = NULL;
1173 if (!fcgi_flush(req, 0)) {
   ~ fail and return;
1174 return -1;
1175 }
1176 if (safe_write(req, str + pos, 0xfff8) != 0xfff8) {
1177 req->keep = 0;
1178 return -1;
1179 }
1180 pos += 0xfff8;
1181 }
1182 
1183 pad = (((len - pos) + 7) & ~7) - (len - pos);
1184 rest = pad ? 8 - pad : 0;
1185 

1173 line fcgi_flush after call fail return -1, but before fcgi_flush 
open_packet(req, type) can add req->out_pos. if we call fcgi_write repeated, 
the req->out_pos will be greater req.

1047 static inline fcgi_header* open_packet(fcgi_request *req, 
fcgi_request_type type)
1048 {
1049 req->out_hdr = (fcgi_header*) req->out_pos;
1050 req->out_hdr->type = type;
1051 req->out_pos += sizeof(fcgi_header);
   ~~ add out_pos
1052 return req->out_hdr;
1053 }


fcgi_request define is:

94 typedef struct _fcgi_request {
 95 intlisten_socket;
 96 #ifdef _WIN32
 97 inttcp;
 98 #endif
 99 intfd;
100 intid;
101 intkeep;
102 
103 intin_len;
104 intin_pad;
105 
106 fcgi_header   *out_hdr;
107 unsigned char *out_pos;
108 unsigned char  out_buf[1024*8];
109 unsigned char  reserved[sizeof(fcgi_end_request_rec)];
110 
111 HashTable  env;
112 } fcgi_request;

the "env" will be write and result in coredump when use the "env" .


my program write much more logs. it will be call "sapi_cgi_log_message" in 
cgi_main.c

static void sapi_cgi_log_message(char *message)
 670 {
 671 #if PHP_FASTCGI
 672 TSRMLS_FETCH();
 673 
 674 if (fcgi_is_fastcgi() && CGIG(fcgi_logging)) {
 675 fcgi_request *request;
 676 
 677 request = (fcgi_request*) SG(server_context);
 678 if (request) {
 679 int len = strlen(message);
 680 char *buf = malloc(len+2);
 681 
 682 memcpy(buf, message, len);
 683 memcpy(buf + len, "\n", sizeof("\n"));
 684 fcgi_write(request, FCGI_STDERR, buf, len+1);
   ~ here will be 
call 
 685 free(buf);
 686 } else {
 687 fprintf(stderr, "%s\n", message);
 688 }
 689 /* ignore return code */
 690 } else
 691 #endif /* PHP_FASTCGI */
 692 fprintf(stderr, "%s\n", message);
 693 }

I think you  can reset req->out_pos after write fail.

thank you








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

Bug #53087 [Opn->Bgs]: getRealPath() returns the parent directory.

[felipe]

Edit report at https://bugs.php.net/bug.php?id=53087&edit=1

 ID: 53087
 Updated by: fel...@php.net
 Reported by:thepixeldeveloper at googlemail dot com
 Summary:getRealPath() returns the parent directory.
-Status: Open
+Status: Bogus
 Type:   Bug
 Package:SPL related
 Operating System:   Ubuntu Maverick Meerkat
 PHP Version:5.3.3
 Block user comment: N
 Private report: N

 New Comment:

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

Not a bug, your directory is probably empty, so it's getting the realpath for 
"..".

Check it using the getFileName() method. :)


Previous Comments:

[2010-10-17 04:35:15] thepixeldeveloper at googlemail dot com

Some additional information

./configure  --prefix=/opt/php-5.3.3 --with-openssl --with-mcrypt --with-
mysqli 
--with-mysql=mysqlnd --with-mysql-sock --with-gd --with-jpeg-dir=/usr --with-
png-dir=/usr --with-zlib-dir=/usr --with-freetype-dir=/usr --with-tidy --with-
curl --enable-fpm --enable-gd-native-ttf --enable-gd-jis-conv --enable-mbstring 
--disable-xmlreader --disable-xmlwriter --disable-phar --without-sqlite --
without-sqlite3 --disable-pdo --disable-posix --with-pear=/usr/share/pear

diff -u /home/mathew/Sources/php-5.3.3/php.ini-development php.ini

http://pastie.org/private/kjaxcwwyx210jfpkfe0ipw


[2010-10-17 03:40:33] thepixeldeveloper at googlemail dot com

Description:

Using getRealPath() on RecursiveDirectoryIterator returns the parent directory.

Test script:
---
getRealPath();

Expected result:

/var/www/nolimits/public/application/cache

Actual result:
--
/var/www/nolimits/public/application






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

Bug #60308 [Com]: Buld fails against PHP-5.4.0RC2-dev

[fedora at famillecollet dot com]

Edit report at https://bugs.php.net/bug.php?id=60308&edit=1

 ID: 60308
 Comment by: fedora at famillecollet dot com
 Reported by:fedora at famillecollet dot com
 Summary:Buld fails against PHP-5.4.0RC2-dev
 Status: Open
 Type:   Bug
 Package:gmagick
 Operating System:   GNU/Linux (Fedora 15)
 PHP Version:5.4.0RC1
 Block user comment: N
 Private report: N

 New Comment:

Can't you please also provides the "tests" folder in the released tarball (for 
the next version) ?


Previous Comments:

[2011-11-15 17:29:44] fedora at famillecollet dot com

Description:

gmagick 1.0.9b1 don't build against latest PHP 5.4.0 snapshot.

Attached patch solves the various issues

All tests run fine
(except gmagick-006-annotateimage because of not available font)







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

[PHP-BUG] Bug #60308 [NEW]: Buld fails against PHP-5.4.0RC2-dev

[fedora at famillecollet dot com]

From: 
Operating system: GNU/Linux (Fedora 15)
PHP version:  5.4.0RC1
Package:  gmagick
Bug Type: Bug
Bug description:Buld fails against PHP-5.4.0RC2-dev

Description:

gmagick 1.0.9b1 don't build against latest PHP 5.4.0 snapshot.

Attached patch solves the various issues

All tests run fine
(except gmagick-006-annotateimage because of not available font)


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

Bug #60296 [Fbk->Opn]: Unable to convert domains valid under IDNA2008 Specification

[ameen at tasjeel dot ae]

Edit report at https://bugs.php.net/bug.php?id=60296&edit=1

 ID: 60296
 User updated by:ameen at tasjeel dot ae
 Reported by:ameen at tasjeel dot ae
 Summary:Unable to convert domains valid under IDNA2008
 Specification
-Status: Feedback
+Status: Open
 Type:   Bug
 Package:idn
 Operating System:   Fedora
-PHP Version:5.3.8
+PHP Version:5.3.6-1
 Block user comment: N
 Private report: N

 New Comment:

The version for libicu is 4.4.2-2


Previous Comments:

[2011-11-15 09:30:10] paj...@php.net

reported at http://bugs.icu-project.org/trac/ticket/8937


[2011-11-14 22:55:34] paj...@php.net

I suppose you use intl's idn_to_ascii right?

In this case, this is most likely a bug in the ICU library, can you please try 
to 
report a bug at the icu-project.org directly. PHP only wraps ICU functions of 
the 
ICU library and data (unicode data). As it is supposed to implement IDNA2008 in 
its latest release, it should work.

btw, which ICU version do you use?


[2011-11-14 15:09:45] ameen at tasjeel dot ae

Description:

The idn implementation in php does not seem to fully support BIDI rules as 
defined in IDNA2008 specification which are the IETF RFCs 5890 - 5894. This has 
been noticed because it does not seem to support converting right-to-left 
script labels ending with a number, and this was addressed by these RFC's.

With the function below there is no output.











Test script:
---
echo idn_to_ascii("اختبار7.امارات"); 

Expected result:

xn--7-ymcadjxy.xn--mgbaam7a8h







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

Bug #52624 [Opn->Csd]: tempnam() by-pass open_basedir with inexistent directory

[felipe]

Edit report at https://bugs.php.net/bug.php?id=52624&edit=1

 ID: 52624
 Updated by: fel...@php.net
 Reported by:hirad dot navid at t-systems dot at
-Summary:tempnam() in SAFE Mode
+Summary:tempnam() by-pass open_basedir with inexistent
 directory
-Status: Open
+Status: Closed
 Type:   Bug
 Package:Unknown/Other Function
 Operating System:   RHEL 5
 PHP Version:5.2.14
-Assigned To:
+Assigned To:felipe
 Block user comment: N
 Private report: N

 New Comment:

This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.

 For Windows:

http://windows.php.net/snapshots/
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:

[2011-11-15 16:59:49] fel...@php.net

Automatic comment from SVN on behalf of felipe
Revision: http://svn.php.net/viewvc/?view=revision&revision=319255
Log: - Fixed bug #52624 (tempnam() by-pass open_basedir with inexistent 
directory)


[2011-05-10 15:19:33] alexis dot olivier at unicaen dot fr

Hello everybody,

We got the same case with open_basedir restriction.

The users have no access to /tmp (they have their own tmp dir). When calling 
tempnam('/tmp', 'tempname'), The open_basedir restriction takes effect and 
creation of the file is forbidden.

But, when calling tempnam('path_that_doesnt_exist', 'tempname'), the function 
takes /tmp in fallback and file is created (overriding the open_basedir 
restriction). The file can't be written (open_basedir restriction), but this 
bug can be used to overflow tmp directory.

I think it lacks a test in the function to protect from writing out of 
open_basedir restriction.

Test script:

With open_basedir not including /tmp : 



[2010-08-17 14:39:52] hirad dot navid at t-systems dot at

Description:

Dear php Team,

We are using php 5.2.13 and Safe_mod is ON.

we have a problem using tempnam, at first we had tempnam('',tempfile); 
This did not work - error "can not access /tmp

Later I investigated and have written the testscript and have following 
behavior. Attention script must be owned by non root user

the script with 7th line $tmp_name = tempnam ( 'tmp', 'tempname' ); works fine 
also with safe_mode

when i change it to $tmp_name = tempnam ( '/tmp', 'tempname' ); a safe_mode 
restriction takes effect (the one with compares UID/GID and puts out 
Warning: tempnam() [function.tempnam]: SAFE MODE Restriction in effect. The 
script whose uid/gid is 506/506 is not allowed to access /tmp owned by uid/gid 
0/0 in /home/httpd/html/default/tempfile.php on line 7

but why does it work without the beginning '/'?
Can you clarify this behavior please? and another issuse is that when i try 
with $tmp_name = tempnam ( '/tmp', 'tempname' ); it does not make a diference 
putting /tmp to openbasedir or safe_mode_includedir it dies not work.


I have also read the changelog and have found that since PHP 5.2.12 some issues 
with tempname and safe_mode have been fixed - there was a bug that tempnam 
ignores safe_mode. And this correct because i tested with php 5.2.11 and it 
worked with /tmp also. Can you tell me ehat exactly is changed saince version 
5.2.12?




Test script:
---
';
for ( $x = 0; $x <= 5; $x++ )
{
  $tmp_name = tempnam ( 'tmp', 'tempname' );
  echo $tmp_name . '';
}
$str = 'standing in a tempfile';
$tmp_file = fopen ( $tmp_name, 'w' );
fputs ( $tmp_file, $str );
fclose ( $tmp_file );
$fp = fopen ( $tmp_name, 'r' );
$str = fgets ( $fp, 50 );
fclose ( $fp );
echo $str;
?>

Expected result:

script above works fine also in safe mode change 7th line from
$tmp_name = tempnam ( 'tmp', 'tempname' );
to
$tmp_name = tempnam ( '/tmp', 'tempname' ); bringe a safe_mode restriction 
which is also ok, but why does it work without / and why does it not make a 
diference putting /tmp to openbasedir or safe_mode_include_dir








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

Bug #51806 [Opn]: chdir wont'work on phar files

[felipe]

Edit report at https://bugs.php.net/bug.php?id=51806&edit=1

 ID: 51806
 Updated by: fel...@php.net
 Reported by:goetas at lignano dot it
 Summary:chdir wont'work on phar files
 Status: Open
 Type:   Bug
 Package:PHAR related
 Operating System:   Slackware
 PHP Version:5.3.2
 Block user comment: N
 Private report: N

 New Comment:

Probably related to #52769


Previous Comments:

[2010-05-13 10:19:20] goetas at lignano dot it

Description:

cant change current working directory into phar package file

Test script:
---
';

include 'phar://test.tar.phar/index.php';





Expected result:

string(50) "phar:///mnt/md1/www/htdocs/test/phar/test.tar.phar"

bool(true)


Actual result:
--
string(50) "phar:///mnt/md1/www/htdocs/test/phar/test.tar.phar"


Warning:  chdir() [function.chdir]: No such 
file or directory (errno 2) in 
phar:///mnt/md1/www/htdocs/test/phar/test.tar.phar/indxed.php on line 
1
bool(false)







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

Bug #52769 [Opn]: realpath not working inside phar

[felipe]

Edit report at https://bugs.php.net/bug.php?id=52769&edit=1

 ID: 52769
 Updated by: fel...@php.net
 Reported by:miha dot vrhovnik at domenca dot com
 Summary:realpath not working inside phar
 Status: Open
 Type:   Bug
 Package:PHAR related
 Operating System:   any
 PHP Version:5.3.3
 Block user comment: N
 Private report: N

 New Comment:

Probably related to bug #51806


Previous Comments:

[2010-09-03 12:45:51] miha dot vrhovnik at domenca dot com

Description:

When you run a realpath returns false when run on phar paths.

Test script:
---
put a test script inside \foo\bar\test.php

and create a phar where \bar\test.php is inisde it

run created phar..

https://bugs.php.net/bug.php?id=52769&edit=1

Bug #52165 [Opn->Csd]: a closure fails to modify a variable in the outer scope

[felipe]

Edit report at https://bugs.php.net/bug.php?id=52165&edit=1

 ID: 52165
 Updated by: fel...@php.net
 Reported by:TerenceHardwicke at safetymail dot info
 Summary:a closure fails to modify a variable in the outer
 scope
-Status: Open
+Status: Closed
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Debian Linux 5
 PHP Version:5.3.2
-Assigned To:
+Assigned To:felipe
 Block user comment: N
 Private report: N

 New Comment:

This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.

 For Windows:

http://windows.php.net/snapshots/
 
Thank you for the report, and for helping us make PHP better.

It has already been fixed. Thanks.


Previous Comments:

[2010-06-23 22:32:27] TerenceHardwicke at safetymail dot info

Description:

my configure line was:

./configure  --prefix /usr/local/php/5.3.2 --disable-libxml --disable-dom 
--disable-simplexml --disable-xml --disable-xmlreader --disable-xmlwriter 
--without-pear

Test script:
---
https://bugs.php.net/bug.php?id=52165&edit=1

Bug #52329 [Opn->Bgs]: ftp_connect doesn't work on web script but works on command line

[felipe]

Edit report at https://bugs.php.net/bug.php?id=52329&edit=1

 ID: 52329
 Updated by: fel...@php.net
 Reported by:daniel dot requena at gmail dot com
 Summary:ftp_connect doesn't work on web script but works on
 command line
-Status: Open
+Status: Bogus
 Type:   Bug
 Package:FTP related
 Operating System:   Centos
 PHP Version:5.3.3RC2
 Block user comment: N
 Private report: N

 New Comment:

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.

Probably due the firewall?


Previous Comments:

[2010-07-13 15:28:28] daniel dot requena at gmail dot com

Description:

Hi,
I have the next script:

When I call this script using command line with the next command:
>php pruftp.php, I always get "Connected!!", but when I call from accessible 
>public url as the next: http://emucent/pruftp.php I always get Now connected 
>to 1192.168.1.120. 
What can be the problem?

Expected result:

Connected!!

Actual result:
--
Not connected to 192.168.1.120!!






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

Bug #52176 [Opn->Bgs]: unlink() cannot delete symbolic link which points to a directory

[felipe]

Edit report at https://bugs.php.net/bug.php?id=52176&edit=1

 ID: 52176
 Updated by: fel...@php.net
 Reported by:o_shes01 at uni-muenster dot de
 Summary:unlink() cannot delete symbolic link which points to
 a directory
-Status: Open
+Status: Bogus
 Type:   Bug
 Package:Filesystem function related
 Operating System:   Windows Vista SP2
 PHP Version:5.3.2
 Block user comment: N
 Private report: N

 New Comment:

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php




Previous Comments:

[2010-06-24 19:37:57] o_shes01 at uni-muenster dot de

Description:

unlink($fname) fails if the file named by $fname is a symbolic link which 
points to a directory. 

Such a link (not the directory which it points to!) can however be deleted via 
"rmdir($fname)", which is also a bug (IMHO). 

Note: if the link points to a regular file (not directory), then unlink works 
as expected (deletes the link, not the file pointed to). 








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

Bug #52107 [Opn->Fbk]: Eval does not recognize local scope variables

[felipe]

Edit report at https://bugs.php.net/bug.php?id=52107&edit=1

 ID: 52107
 Updated by: fel...@php.net
 Reported by:nick dot mitin at gmail dot com
 Summary:Eval does not recognize local scope variables
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Ubuntu 10.04 32bit
 PHP Version:5.3.2
 Block user comment: N
 Private report: N

 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-06-17 08:26:33] nick dot mitin at gmail dot com

Description:

Sometimes under undetermined conditions eval() does not see the local scope 
function variables.


$returnTo = $_SERVER['REQUEST_URI'];
eval('$this->content = "' . 
$this->application->getTemplate('/admin/user/login/login') . '";');

Assuming that I have $returnTo variable inside a '/admin/user/login/login', I 
see the "Notice: undefined variable $returnTo", while evaling it.

But, If I create a dummy function moo() and eval somthing there the notice is 
gone.

See whole listing for details.


Test script:
---
Whole listing: http://kinokapsula.artgorbunov.ru/bug.php







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

Bug #52146 [Opn->Fbk]: bcadd large number problem

[felipe]

Edit report at https://bugs.php.net/bug.php?id=52146&edit=1

 ID: 52146
 Updated by: fel...@php.net
 Reported by:acosonic at gmail dot com
 Summary:bcadd large number problem
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:BC math related
 Operating System:   windows XP
 PHP Version:5.3.2
 Block user comment: N
 Private report: N

 New Comment:

Have you tried to use bc application direclty?


Previous Comments:

[2010-06-22 15:36:19] acosonic at gmail dot com

Description:

bcadd calculates different result than gmp_add or array_sum for given large 
number example.

Test script:
---
Solution for http://projecteuler.net/index.php?section=problems&id=13

Solution works for array_sum & gmp_add but not for bcadd
$str=<

Bug #60307 [Opn->Asn]: add_task(GEARMAN_INVALID_ARGUMENT) unique name longer then GEARMAN_UNIQUE_MAX_S

[hradtke]

Edit report at https://bugs.php.net/bug.php?id=60307&edit=1

 ID: 60307
 Updated by: hrad...@php.net
 Reported by:hrad...@php.net
 Summary:add_task(GEARMAN_INVALID_ARGUMENT) unique name
 longer then GEARMAN_UNIQUE_MAX_S
-Status: Open
+Status: Assigned
 Type:   Bug
 Package:gearman
 Operating System:   CentOS 5.7
 PHP Version:5.3.8
-Assigned To:
+Assigned To:hradtke
 Block user comment: N
 Private report: N



Previous Comments:

[2011-11-15 15:46:58] hrad...@php.net

Description:

Ok, updated everything to .25 and re-built all packages.

The new feature of GEARMAN_UNIQUE_MAX_SIZE is causing problems.

GearmanClient::doBackground(): add_task(GEARMAN_INVALID_ARGUMENT)
unique name longer then GEARMAN_UNIQUE_MAX_SIZE -> libgearman/add.cc:
131 in /blah/blah.php

We use the same ID for the message and the uniqueId and have never had
any problems in the past.

Usage:

$client->doBackground('jobs_publish', 42789639, 42789639);

At first I thought maybe its just interpreting the uniqueId as an int
so I explicitly cast it as a string first and still failed.

$client->doBackground('rtu_careers_jobs_publish', 42789639,
(string)42789639);

Let me know if I can provide any additional information.

CentOS 5.7
PHP 5.3.6
PECL Gearman 0.8
Gearmand 0.25

Ok, we figured out a work-around already.

Passing in a pure integer as uniqueId does not work. Even when casting
as a string.

However, we simply changed the uniqueId to something like this:

$uniqueId =
substr(str_shuffle(str_repeat('ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789',
5)),0,5);
$client->doBackground('jobs_publish', 42789639, $uniqueId);


And everything works!!!







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

[PHP-BUG] Bug #60307 [NEW]: add_task(GEARMAN_INVALID_ARGUMENT) unique name longer then GEARMAN_UNIQUE_MAX_S

[hrad...@php.net]

From: hradtke
Operating system: CentOS 5.7
PHP version:  5.3.8
Package:  gearman
Bug Type: Bug
Bug description:add_task(GEARMAN_INVALID_ARGUMENT) unique name longer then 
GEARMAN_UNIQUE_MAX_S

Description:

Ok, updated everything to .25 and re-built all packages.

The new feature of GEARMAN_UNIQUE_MAX_SIZE is causing problems.

GearmanClient::doBackground(): add_task(GEARMAN_INVALID_ARGUMENT)
unique name longer then GEARMAN_UNIQUE_MAX_SIZE -> libgearman/add.cc:
131 in /blah/blah.php

We use the same ID for the message and the uniqueId and have never had
any problems in the past.

Usage:

$client->doBackground('jobs_publish', 42789639, 42789639);

At first I thought maybe its just interpreting the uniqueId as an int
so I explicitly cast it as a string first and still failed.

$client->doBackground('rtu_careers_jobs_publish', 42789639,
(string)42789639);

Let me know if I can provide any additional information.

CentOS 5.7
PHP 5.3.6
PECL Gearman 0.8
Gearmand 0.25

Ok, we figured out a work-around already.

Passing in a pure integer as uniqueId does not work. Even when casting
as a string.

However, we simply changed the uniqueId to something like this:

$uniqueId =
substr(str_shuffle(str_repeat('ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789',
5)),0,5);
$client->doBackground('jobs_publish', 42789639, $uniqueId);


And everything works!!!


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

Bug #51802 [Opn->Fbk]: PHP temp files not deleted when also using a CGI script

[felipe]

Edit report at https://bugs.php.net/bug.php?id=51802&edit=1

 ID: 51802
 Updated by: fel...@php.net
 Reported by:relayadmin at disney dot com
 Summary:PHP temp files not deleted when also using a CGI
 script
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:CGI/CLI related
 Operating System:   Windows Server 2003
 PHP Version:5.2.13
 Block user comment: N
 Private report: N

 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-05-12 21:07:14] relayadmin at disney dot com

Description:

This bug is very specific to Windows.  When executing a generic file upload 
using PHP, if at anytime while the file is being uploaded Apache then runs a 
CGI script like PERL or a C program, and the upload ends while the CGI script 
is still running, the uploaded file(s) in the temp directory will remain behind 
forever.

In order to avoid this the “php_do_open_temporary_file” routine will have 
to not use the “VCWD_OPEN_MODE” routine to open the temp file.  A generic 
Windows “open” call allows child processes to inherit their handles.  The 
temp file would need to be opened with a “CreateFile” call to open the file 
and specify the pSecurityAttributes option with bInheritHandle set to FALSE so 
that a child process will not inherit the open file handle.  The rub is this 
call uses a non-compatible handle so everyone who uses this handle has to be 
modified as well.



Test script:
---
Write or use any simple PHP upload program.  Next use CGI program below -- it 
doesn't need to do anything except take time.  So start the PHP upload, then 
start the CGI program below from a webpage.  Make sure the PHP upload completes 
before the script ends.


#include 

void main(){
  Sleep(2*60*1000); // sleep 2 minutes
}

Expected result:

The file should be uploaded and the temp file in the temp directory should not 
be present when done.  It should be moved to the destination directory.

Actual result:
--
The temp file remains forever in the temp directory, though the file is copied 
correctly to the destination directory.






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

Bug #51862 [Opn->Bgs]: Error in Zend-module when linking

[felipe]

Edit report at https://bugs.php.net/bug.php?id=51862&edit=1

 ID: 51862
 Updated by: fel...@php.net
 Reported by:mdobrinic at cozmanova dot com
 Summary:Error in Zend-module when linking
-Status: Open
+Status: Bogus
 Type:   Bug
 Package:Compile Failure
 Operating System:   Mac OSX 10.5.8
 PHP Version:5.2.13
 Block user comment: N
 Private report: N

 New Comment:

Thank you for taking the time to report a problem with PHP.
Unfortunately you are not using a current version of PHP -- 
the problem might already be fixed. Please download a new
PHP version from http://www.php.net/downloads.php

If you are able to reproduce the bug with one of the latest
versions of PHP, please change the PHP version on this bug report
to the version you tested and change the status back to "Open".
Again, thank you for your continued support of PHP.




Previous Comments:

[2010-05-19 18:39:38] mdobrinic at cozmanova dot com

Description:

When trying to compile php, everything goes but linking produces this error:

ld: duplicate symbol _yytext in Zend/zend_ini_scanner.o and 
Zend/zend_language_scanner.o
 for architecture i386
collect2: ld returned 1 exit status
ld: duplicate symbol _yytext in Zend/zend_ini_scanner.o and 
Zend/zend_language_scanner.o
 for architecture x86_64
collect2: ld returned 1 exit status
ld: duplicate symbol _yytext in Zend/zend_ini_scanner.o and 
Zend/zend_language_scanner.o
 for architecture ppc
collect2: ld returned 1 exit status
ld: duplicate symbol _yytext in Zend/zend_ini_scanner.o and 
Zend/zend_language_scanner.o
 for architecture ppc64
collect2: ld returned 1 exit status



Test script:
---
I have looked into other bug reports concerning this message, and came to the 
conclusion that the linked on Mac OSX is a bit more strict than on other 
platforms.

To make the error go away, I modified the sourcefiles:
Zend/zend_ini_scanner.c
and
Zend/zend_language_scanner.c

Both zend_ini_scanner.c as well as zend_language_scanner.c contained a line 
with:
char *yytext

that I changed to become:
extern char *yytext


It's a quick-fix that makes the linker error go away, but I don't know whether 
it solves the problem.




Expected result:

does this solve the problem, or does it only do away with the linker error?







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

Bug #55371 [Asn->Csd]: get_magic_quotes_gpc() throws deprecation warning

[dsp]

Edit report at https://bugs.php.net/bug.php?id=55371&edit=1

 ID: 55371
 Updated by: d...@php.net
 Reported by:thbley at gmail dot com
 Summary:get_magic_quotes_gpc() throws deprecation warning
-Status: Assigned
+Status: Closed
 Type:   Bug
 Package:Safe Mode/open_basedir
 Operating System:   Win7 6.1.7600
 PHP Version:5.4.0alpha3
 Assigned To:dsp
 Block user comment: N
 Private report: N

 New Comment:

This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.

 For Windows:

http://windows.php.net/snapshots/
 
Thank you for the report, and for helping us make PHP better.

Thanks david, patch applied.


Previous Comments:

[2011-11-15 13:22:42] d...@php.net

Automatic comment from SVN on behalf of dsp
Revision: http://svn.php.net/viewvc/?view=revision&revision=319249
Log: Fixed bug #55371 (get_magic_quotes_gpc() throws deprecation warning.)

Patch by David Zuelke 


[2011-11-15 13:09:43] paj...@php.net

Let me clarify this pointer. Getter should not raise any warning. Setters do.


[2011-11-15 13:01:45] david dot zuelke at bitextender dot com

A warning definitely is a bad idea, it makes it impossible to write portable 
code 
to detect magic quotes without version check stunts. It's fine if the two 
functions simply return false forever, there's not even a need to remove them 
as 
they don't do any harm whatsoever.


[2011-11-15 12:58:20] paj...@php.net

Hi David,

please do it, I do not have the time to do it before RC2.

Cheers,


[2011-11-14 11:14:00] bj...@php.net

Throwing any kind of warnings for the getters is a cruel punishment targetting 
the people who were actually dealing with the problem we gave them in the first 
place.




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

https://bugs.php.net/bug.php?id=55371


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

Bug #55371 [Asn]: Function get_magic_quotes_gpc() is deprecated

[pajoye]

Edit report at https://bugs.php.net/bug.php?id=55371&edit=1

 ID: 55371
 Updated by: paj...@php.net
 Reported by:thbley at gmail dot com
 Summary:Function get_magic_quotes_gpc() is deprecated
 Status: Assigned
 Type:   Bug
 Package:Safe Mode/open_basedir
 Operating System:   Win7 6.1.7600
 PHP Version:5.4.0alpha3
 Assigned To:dsp
 Block user comment: N
 Private report: N

 New Comment:

Let me clarify this pointer. Getter should not raise any warning. Setters do.


Previous Comments:

[2011-11-15 13:01:45] david dot zuelke at bitextender dot com

A warning definitely is a bad idea, it makes it impossible to write portable 
code 
to detect magic quotes without version check stunts. It's fine if the two 
functions simply return false forever, there's not even a need to remove them 
as 
they don't do any harm whatsoever.


[2011-11-15 12:58:20] paj...@php.net

Hi David,

please do it, I do not have the time to do it before RC2.

Cheers,


[2011-11-14 11:14:00] bj...@php.net

Throwing any kind of warnings for the getters is a cruel punishment targetting 
the people who were actually dealing with the problem we gave them in the first 
place.


[2011-11-12 21:57:29] tyr...@php.net

Just my 2 cents: 
I think that raising an E_DEPRECATED now is better, if we want to remove the 
get 
methods with the major/minor version after 5.4.


[2011-11-12 12:12:01] david dot zuelke at bitextender dot com

According to several mailing list threads I've searched, it should not give a 
deprecation warning. So it's not a documentation problem but a bug. The 
attached 
patch fixes the problem (uses PHP_FE instead of PHP_DEP_FE for 
get_magic_quotes_gpc() and get_magic_quotes_runtime()) and adds and updates 
tests 
accordingly.




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

https://bugs.php.net/bug.php?id=55371


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

Bug #55371 [Com]: Function get_magic_quotes_gpc() is deprecated

[david dot zuelke at bitextender dot com]

Edit report at https://bugs.php.net/bug.php?id=55371&edit=1

 ID: 55371
 Comment by: david dot zuelke at bitextender dot com
 Reported by:thbley at gmail dot com
 Summary:Function get_magic_quotes_gpc() is deprecated
 Status: Assigned
 Type:   Bug
 Package:Safe Mode/open_basedir
 Operating System:   Win7 6.1.7600
 PHP Version:5.4.0alpha3
 Assigned To:dsp
 Block user comment: N
 Private report: N

 New Comment:

A warning definitely is a bad idea, it makes it impossible to write portable 
code 
to detect magic quotes without version check stunts. It's fine if the two 
functions simply return false forever, there's not even a need to remove them 
as 
they don't do any harm whatsoever.


Previous Comments:

[2011-11-15 12:58:20] paj...@php.net

Hi David,

please do it, I do not have the time to do it before RC2.

Cheers,


[2011-11-14 11:14:00] bj...@php.net

Throwing any kind of warnings for the getters is a cruel punishment targetting 
the people who were actually dealing with the problem we gave them in the first 
place.


[2011-11-12 21:57:29] tyr...@php.net

Just my 2 cents: 
I think that raising an E_DEPRECATED now is better, if we want to remove the 
get 
methods with the major/minor version after 5.4.


[2011-11-12 12:12:01] david dot zuelke at bitextender dot com

According to several mailing list threads I've searched, it should not give a 
deprecation warning. So it's not a documentation problem but a bug. The 
attached 
patch fixes the problem (uses PHP_FE instead of PHP_DEP_FE for 
get_magic_quotes_gpc() and get_magic_quotes_runtime()) and adds and updates 
tests 
accordingly.


[2011-11-07 02:54:54] 44318209 at qq dot com

I have the same problem




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

https://bugs.php.net/bug.php?id=55371


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

Bug #55371 [Asn]: Function get_magic_quotes_gpc() is deprecated

[pajoye]

Edit report at https://bugs.php.net/bug.php?id=55371&edit=1

 ID: 55371
 Updated by: paj...@php.net
 Reported by:thbley at gmail dot com
 Summary:Function get_magic_quotes_gpc() is deprecated
 Status: Assigned
 Type:   Bug
 Package:Safe Mode/open_basedir
 Operating System:   Win7 6.1.7600
 PHP Version:5.4.0alpha3
-Assigned To:pajoye
+Assigned To:dsp
 Block user comment: N
 Private report: N

 New Comment:

Hi David,

please do it, I do not have the time to do it before RC2.

Cheers,


Previous Comments:

[2011-11-14 11:14:00] bj...@php.net

Throwing any kind of warnings for the getters is a cruel punishment targetting 
the people who were actually dealing with the problem we gave them in the first 
place.


[2011-11-12 21:57:29] tyr...@php.net

Just my 2 cents: 
I think that raising an E_DEPRECATED now is better, if we want to remove the 
get 
methods with the major/minor version after 5.4.


[2011-11-12 12:12:01] david dot zuelke at bitextender dot com

According to several mailing list threads I've searched, it should not give a 
deprecation warning. So it's not a documentation problem but a bug. The 
attached 
patch fixes the problem (uses PHP_FE instead of PHP_DEP_FE for 
get_magic_quotes_gpc() and get_magic_quotes_runtime()) and adds and updates 
tests 
accordingly.


[2011-11-07 02:54:54] 44318209 at qq dot com

I have the same problem


[2011-10-27 11:27:19] a at b dot c dot de

NEWS_5_4_0_beta1.txt mentions that get_magic_quotes_{gpc|runtime}() always 
return false, but not that they're deprecated.




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

https://bugs.php.net/bug.php?id=55371


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

Bug #55371 [Opn->Asn]: Function get_magic_quotes_gpc() is deprecated

[dsp]

Edit report at https://bugs.php.net/bug.php?id=55371&edit=1

 ID: 55371
 Updated by: d...@php.net
 Reported by:thbley at gmail dot com
 Summary:Function get_magic_quotes_gpc() is deprecated
-Status: Open
+Status: Assigned
 Type:   Bug
 Package:Safe Mode/open_basedir
 Operating System:   Win7 6.1.7600
 PHP Version:5.4.0alpha3
-Assigned To:
+Assigned To:pajoye
 Block user comment: N
 Private report: N



Previous Comments:

[2011-11-14 11:14:00] bj...@php.net

Throwing any kind of warnings for the getters is a cruel punishment targetting 
the people who were actually dealing with the problem we gave them in the first 
place.


[2011-11-12 21:57:29] tyr...@php.net

Just my 2 cents: 
I think that raising an E_DEPRECATED now is better, if we want to remove the 
get 
methods with the major/minor version after 5.4.


[2011-11-12 12:12:01] david dot zuelke at bitextender dot com

According to several mailing list threads I've searched, it should not give a 
deprecation warning. So it's not a documentation problem but a bug. The 
attached 
patch fixes the problem (uses PHP_FE instead of PHP_DEP_FE for 
get_magic_quotes_gpc() and get_magic_quotes_runtime()) and adds and updates 
tests 
accordingly.


[2011-11-07 02:54:54] 44318209 at qq dot com

I have the same problem


[2011-10-27 11:27:19] a at b dot c dot de

NEWS_5_4_0_beta1.txt mentions that get_magic_quotes_{gpc|runtime}() always 
return false, but not that they're deprecated.




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

https://bugs.php.net/bug.php?id=55371


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

Bug #51009 [Opn->Fbk]: PDO with pgsql returning NULL when integer expected in prepared query

[felipe]

Edit report at https://bugs.php.net/bug.php?id=51009&edit=1

 ID: 51009
 Updated by: fel...@php.net
 Reported by:peter at allicient dot co dot uk
 Summary:PDO with pgsql returning NULL when integer expected
 in prepared query
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:PDO related
 Operating System:   FreeBSD 8.0
 PHP Version:5.2.12
 Block user comment: N
 Private report: N

 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-11 03:27:00] peter at allicient dot co dot uk

Description:

When using a prepared SELECT query of the form "SELECT table_a.column_id, 
table_a.column_some_string FROM table_a LEFT OUTER JOIN table_b ON 
(table_a.column_id = table_b.foreign_key_id)" - which executes successfully - 
there is a problem fetching the results.

Using fetchAll( PDO::FETCH_ASSOC ) returns the rows with the strings intact but 
the column_id (integer) as NULL.  PDO::FETCH_BOTH shows that numerically 
indexed rows have the column_id as expected but the error still present when 
indexed by the column name.

The same query performed via pgadmin3 returns the expected results, and is the 
same as PDO::FETCH_NUM so there is definitely a problem with PDO::FETCH_ASSOC.

Other SELECT queries work as expected, it seems to be related to the "LEFT 
OUTER JOIN".

It can be coded around but is nonetheless a curious error.

Expected result:

For the PDO::FETCH_ASSOC to return the same data as PDO::FETCH_NUM.







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

Bug #49260 [Opn->Fbk]: IPC msg_get_queue fails to retrieve common resource id across scripts

[felipe]

Edit report at https://bugs.php.net/bug.php?id=49260&edit=1

 ID: 49260
 Updated by: fel...@php.net
 Reported by:ivan dot barrios at gmail dot com
 Summary:IPC msg_get_queue fails to retrieve common resource
 id across scripts
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:Semaphore related
 Operating System:   MacOS v10.5.7
 PHP Version:5.2.10
 Block user comment: N
 Private report: N

 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:

[2009-08-14 19:51:16] ivan dot barrios at gmail dot com

Description:

Identical PHP scripts function on Ubuntu 9.04 Desktop perfectly. 

Mac OSX configuration:

PHP version: 5.2.10
sysvmsg version: $Revision: 1.20.2.3.2.8 $
sysvmsg package installed as an extension (.so file)

Ubuntu configuration:

PHP version: 5.2.10
sysvmsg version: $Revision: 1.20.2.3.2.7 $
sysvmsg package installed as an extension (.so file)



Reproduce code:
---
See http://www.phpfreaks.com/forums/index.php/topic,264945.0.html

for source code: 2 files (msg_client.php, msg_server.php)

Expected result:

Code should print following text to PHP error log:

 says hello.\n
COREPHP\n



Actual result:
--
Nothing gets printed because the $serverQueue in the Client script 
(msg_client.php) never gets loaded with the correct queue id for the 
Server.






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

Bug #58453 [Com]: in CLI mode APC cache is not working in windows

[clepsos2003 at hotmail dot com]

Edit report at https://bugs.php.net/bug.php?id=58453&edit=1

 ID: 58453
 Comment by: clepsos2003 at hotmail dot com
 Reported by:pradeep dot gems at gmail dot com
 Summary:in CLI mode APC cache is not working in windows
 Status: Open
 Type:   Bug
 Package:APC
 Operating System:   Windows
 PHP Version:5.2.5
 Block user comment: N
 Private report: N

 New Comment:

Same problem on Wamp (PHP 5.3.7 - Apache 2.2.11)

Here is the command line code :
php -d apc.enable_cli=1 -r "apc_clear_cache();"


Previous Comments:

[2009-12-16 10:17:50] spoon at nexdot dot net

System has 1.3GB of physical ram not in use. Ive tried 
everything from setting the shm size to 1M to forcing 
apache/php to run as admin w/ full rights. Its quite awkward.

It appears that APC is running just fine when I load php using  
fcgi - load tests & phpinfo() confirm its loaded.

Only fails when loading php as a module or when trying to run 
cli when fcgi is running (im assuming this is because of a 
sharing violation of some sort?)


[2009-12-12 22:51:07] sh...@php.net

Can you verify that your system is not running low on/ or out of memory?  
Perhaps this could be a failure due to the system being unable to allocate 
memory for the shared memory segment.


[2009-12-09 15:22:59] spoon at nexdot dot net

Same problem here.

Server 2003, Apache 2.2.14 VC9, PHP 5.3.1 VC9 (both TS and 
NTS), APC 3.1 VC9 (both TS and NTS) from 
http://downloads.php.net/pierre/ (dated: 20091026)

When running PHP as a module in apache, web pages come up 
blank, if I run php.exe (while apache is still running) I receive 

[apc-error] apc_shm_create: shmget(0,
31457280,658) failed: No such file or directory. It is 
possible that
the
chosen
egment size is higher than the operation system allows. 
Linux has
usually a default limit of 32MB per segment.


If i stop apache, I can successfully run php.exe but 
that doesnt help me too much :)


[2009-10-12 01:35:27] pradeep dot gems at gmail dot com

apc]
extension=php_apc.dll
apc.enabled = On
apc.enable_cli = On


[2009-10-10 10:11:07] kukulich at kukulich dot cz

I got same error with this APC settings:

[apc]
extension=php_apc.dll
apc.enabled = On
apc.enable_cli = On

WinXP, Apache 2.2 VC9, PHP 5.3.1 RC 1 VC9, APC 3.1.3p1
(I got same error with 5.2 VC6 and older version of APC)




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

https://bugs.php.net/bug.php?id=58453


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

Bug #60303 [Opn->Csd]: Custom session handlers fail when using header redirect

[wdouglascampbell at hotmail dot com]

Edit report at https://bugs.php.net/bug.php?id=60303&edit=1

 ID: 60303
 User updated by:wdouglascampbell at hotmail dot com
 Reported by:wdouglascampbell at hotmail dot com
 Summary:Custom session handlers fail when using header
 redirect
-Status: Open
+Status: Closed
 Type:   Bug
 Package:Session related
 Operating System:   Linux 2.6.40.4-5
 PHP Version:5.3.8
 Block user comment: N
 Private report: N

 New Comment:

Sorry.  I had an error in my sess_write routine and the sessions table entry 
was not being properly updated.

There is no bug.


Previous Comments:

[2011-11-14 21:43:51] wdouglascampbell at hotmail dot com

Description:

I have a custom session handler.  My session variables are not saved when I use 
a header redirect.  In fact, the $_SESSION array is shown as empty.

If I use the standard session handlers, everything works fine as expected.




Test script:
---
The three files for replicating this problem are can be retrieve from the 
following archive:

https://globalopsccci.org/TheKey_AuthTest/testfiles.tar.bz2



Expected result:

The following output should be displayed:

testarray(1) { ["test"]=> string(4) "test" } 


The above is displayed if I comment out the include_once line in test.php and 
test2.php.









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

Bug #60236 [Asn]: TLA timezone dates are not converted properly from timestamp

[pajoye]

Edit report at https://bugs.php.net/bug.php?id=60236&edit=1

 ID: 60236
 Updated by: paj...@php.net
 Reported by:s...@php.net
 Summary:TLA timezone dates are not converted properly from
 timestamp
 Status: Assigned
 Type:   Bug
 Package:Date/time related
 Operating System:   *
 PHP Version:5.4.0beta2
 Assigned To:derick
 Block user comment: N
 Private report: N

 New Comment:

reported at http://bugs.icu-project.org/trac/ticket/8937


Previous Comments:

[2011-11-07 18:10:33] s...@php.net

Description:

If you convert a date with TLA timezone (like EDT) to timestamp, and then 
convert 
it back from timestamp, resulting date is off by an hour. See example below.

Test script:
---
format('U');
var_dump($ts);
$t->setTimestamp($ts);
var_dump($t);


Expected result:

string(10) "1278455908"
object(DateTime)#1 (3) {
  ["date"]=>
  string(19) "2010-07-06 18:38:28"
  ["timezone_type"]=>
  int(2)
  ["timezone"]=>
  string(3) "EDT"
}


Actual result:
--
string(10) "1278455908"
object(DateTime)#1 (3) {
  ["date"]=>
  string(19) "2010-07-06 17:38:28"
  ["timezone_type"]=>
  int(2)
  ["timezone"]=>
  string(3) "EDT"
}







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

Bug #60296 [Fbk]: Unable to convert domains valid under IDNA2008 Specification

[pajoye]

Edit report at https://bugs.php.net/bug.php?id=60296&edit=1

 ID: 60296
 Updated by: paj...@php.net
 Reported by:ameen at tasjeel dot ae
 Summary:Unable to convert domains valid under IDNA2008
 Specification
 Status: Feedback
 Type:   Bug
 Package:idn
 Operating System:   Fedora
 PHP Version:5.3.8
 Block user comment: N
 Private report: N

 New Comment:

reported at http://bugs.icu-project.org/trac/ticket/8937


Previous Comments:

[2011-11-14 22:55:34] paj...@php.net

I suppose you use intl's idn_to_ascii right?

In this case, this is most likely a bug in the ICU library, can you please try 
to 
report a bug at the icu-project.org directly. PHP only wraps ICU functions of 
the 
ICU library and data (unicode data). As it is supposed to implement IDNA2008 in 
its latest release, it should work.

btw, which ICU version do you use?


[2011-11-14 15:09:45] ameen at tasjeel dot ae

Description:

The idn implementation in php does not seem to fully support BIDI rules as 
defined in IDNA2008 specification which are the IETF RFCs 5890 - 5894. This has 
been noticed because it does not seem to support converting right-to-left 
script labels ending with a number, and this was addressed by these RFC's.

With the function below there is no output.











Test script:
---
echo idn_to_ascii("اختبار7.امارات"); 

Expected result:

xn--7-ymcadjxy.xn--mgbaam7a8h







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

Bug #60236 [Asn]: TLA timezone dates are not converted properly from timestamp

[pajoye]

Edit report at https://bugs.php.net/bug.php?id=60236&edit=1

 ID: 60236
 Updated by: paj...@php.net
 Reported by:s...@php.net
 Summary:TLA timezone dates are not converted properly from
 timestamp
 Status: Assigned
 Type:   Bug
 Package:Date/time related
 Operating System:   *
 PHP Version:5.4.0beta2
 Assigned To:derick
 Block user comment: N
 Private report: N

 New Comment:

reported at http://bugs.icu-project.org/trac/ticket/8937


Previous Comments:

[2011-11-07 18:10:33] s...@php.net

Description:

If you convert a date with TLA timezone (like EDT) to timestamp, and then 
convert 
it back from timestamp, resulting date is off by an hour. See example below.

Test script:
---
format('U');
var_dump($ts);
$t->setTimestamp($ts);
var_dump($t);


Expected result:

string(10) "1278455908"
object(DateTime)#1 (3) {
  ["date"]=>
  string(19) "2010-07-06 18:38:28"
  ["timezone_type"]=>
  int(2)
  ["timezone"]=>
  string(3) "EDT"
}


Actual result:
--
string(10) "1278455908"
object(DateTime)#1 (3) {
  ["date"]=>
  string(19) "2010-07-06 17:38:28"
  ["timezone_type"]=>
  int(2)
  ["timezone"]=>
  string(3) "EDT"
}







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

Bug #59450 [Com]: ./configure fails with "Cannot find php_pdo_driver.h"

[esserj at gmail dot com]

Edit report at https://bugs.php.net/bug.php?id=59450&edit=1

 ID: 59450
 Comment by: esserj at gmail dot com
 Reported by:jan dot declercq at gmail dot com
 Summary:./configure fails with  "Cannot find
 php_pdo_driver.h"
 Status: Open
 Type:   Bug
 Package:PDO_INFORMIX
 Operating System:   Linux (opensuse 11.3)
 PHP Version:5.3.3
 Block user comment: N
 Private report: N

 New Comment:

same problem on UBUNTU,
solved the problem as per 
"[2010-10-06 02:56 UTC] jan dot declercq at gmail dot com" comment


Previous Comments:

[2010-10-06 02:56:44] jan dot declercq at gmail dot com

I manually altered /tmp/pear/download/PDO_INFORMIX-
1.2.6/configure

Where you have the lines:

if test -f $abs_srcdir/include/php/ext/pdo/php_pdo_driver.h; 
then
 pdo_inc_path=$abs_srcdir/ext
   elif test -f $abs_srcdir/ext/pdo/php_pdo_driver.h; then
 pdo_inc_path=$abs_srcdir/ext
   elif test -f 
$prefix/include/php/ext/pdo/php_pdo_driver.h; then
 pdo_inc_path=$prefix/include/php/ext
   else
 as_fn_error "Cannot find php_pdo_driver.h." "$LINENO" 5
   fi
 
 
 I added this lines so it would find the header file:  
(../php5/..
 instead of
 .../php/..  )
 
   elif test -f 
$prefix/include/php5/ext/pdo/php_pdo_driver.h; then
 pdo_inc_path=$prefix/include/php5/ext


[2010-10-06 02:51:03] jan dot declercq at gmail dot com

Description:

 Cannot find php_pdo_driver.h


The ./configure script doesn't look in in /usr/include/php5 
for the php_pdo_driver.h


Extra info:

#php -v
PHP 5.3.3 (cli) 
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend 
Technologies

# rpm -q php5
php5-5.3.3-0.1.2.x86_64

# rpm -q php5-pdo
php5-pdo-5.3.3-0.1.2.x86_64

# php-config --include-dir
/usr/include/php5



Reproduce code:
---
pecl install -n pdo_informix



Expected result:

pdo_informix should install..

Actual result:
--
> checking for PDO includes... configure: error: Cannot find
> php_pdo_driver.h.
> ERROR: `/tmp/pear/download/PDO_INFORMIX-1.2.6/configure
> --with-pdo-informix=/opt/IBM/informix' failed






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

Bug #60306 [Asn]: zend-multibyte failed in 5.4

[laruence]

Edit report at https://bugs.php.net/bug.php?id=60306&edit=1

 ID: 60306
 Updated by: larue...@php.net
 Reported by:larue...@php.net
 Summary:zend-multibyte failed in 5.4
 Status: Assigned
 Type:   Bug
 Package:mbstring related
 PHP Version:5.4.0RC1
 Assigned To:dmitry
 Block user comment: N
 Private report: N

 New Comment:

the same script as above, will trigger a abort in this way:

$php54 -d mbstring.internal_encoding=cp936 /tmp/1.php 

php: Zend/zend_language_scanner.l:126: encoding_filter_script_to_internal: 
Assertion `internal_encoding && 
zend_multibyte_check_lexer_compatibility(internal_encoding)' failed.
Aborted (core dumped)


Previous Comments:

[2011-11-15 08:27:09] larue...@php.net

if I change the script to:


also set fenc=cp936, then a memory leak will be reported:

$ php54 -d mbstring.internal_encoding=utf8 -dzend.script_encoding=cp936 
/tmp/1.php 
string(7) "洪仁?"
[Tue Nov 15 16:26:36 2011]  Script:  '/tmp/1.php'
***php-src/trunk/ext/mbstring/mbstring.c(612) :  Freeing 0x2A95DDDF68 (131 
bytes), script=/tmp/1.php
=== Total 1 memory leaks detected ===


[2011-11-15 07:37:53] larue...@php.net

dmitry, plz look at this, thanks :)


[2011-11-15 07:29:21] larue...@php.net

Description:

same script, same ini,  5.4 result a wrong result .





Test script:
---


save the test script in  fenc=cp936. 

run:
php53 -dmbstring.internal_encoding=utf8 test.php 
and
php54 -dmbstring.internal_encoding=utf8 test.php 

Expected result:

string(9) "洪仁玕"

Actual result:
--
5.3 works fine. 

but 5.4 output:
string(3) "æ´ª"






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

Bug #60306 [Asn]: zend-multibyte failed in 5.4

[laruence]

Edit report at https://bugs.php.net/bug.php?id=60306&edit=1

 ID: 60306
 Updated by: larue...@php.net
 Reported by:larue...@php.net
 Summary:zend-multibyte failed in 5.4
 Status: Assigned
 Type:   Bug
 Package:mbstring related
 PHP Version:5.4.0RC1
 Assigned To:dmitry
 Block user comment: N
 Private report: N

 New Comment:

if I change the script to:


also set fenc=cp936, then a memory leak will be reported:

$ php54 -d mbstring.internal_encoding=utf8 -dzend.script_encoding=cp936 
/tmp/1.php 
string(7) "洪仁?"
[Tue Nov 15 16:26:36 2011]  Script:  '/tmp/1.php'
***php-src/trunk/ext/mbstring/mbstring.c(612) :  Freeing 0x2A95DDDF68 (131 
bytes), script=/tmp/1.php
=== Total 1 memory leaks detected ===


Previous Comments:

[2011-11-15 07:37:53] larue...@php.net

dmitry, plz look at this, thanks :)


[2011-11-15 07:29:21] larue...@php.net

Description:

same script, same ini,  5.4 result a wrong result .





Test script:
---


save the test script in  fenc=cp936. 

run:
php53 -dmbstring.internal_encoding=utf8 test.php 
and
php54 -dmbstring.internal_encoding=utf8 test.php 

Expected result:

string(9) "洪仁玕"

Actual result:
--
5.3 works fine. 

but 5.4 output:
string(3) "æ´ª"






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