from:"nlopess"

Req #53583 [Asn->Csd]: [PATCH] add support for compiler "alloc_size" attribute

2012-06-01 Thread nlopess

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

 ID: 53583
 Updated by: nlop...@php.net
 Reported by:crrodriguez at opensuse dot org
 Summary:[PATCH] add support for compiler "alloc_size"
 attribute
-Status: Assigned
+Status: Closed
 Type:   Feature/Change Request
 Package:Scripting Engine problem
 Operating System:   All
 PHP Version:5.3SVN-2010-12-20 (SVN)
-Assigned To:dmitry
+Assigned To:    nlopess
 Block user comment: N
 Private report: N

 New Comment:

I commited a similar patch already.


Previous Comments:

[2010-12-20 19:19:27] crrodriguez at opensuse dot org

Description:

The attached patch Introduces support for GCC alloc_size attribute, very useful 
to catch buffer overflows at compile time.





Test script:
---
PHP_FUNCTION(verybuggy) {
[...]

char *p;
p = emalloc(6);
strcpy(p,"cdcdccdscdscscsdcscddsc");
[...]
}

Expected result:

#make

buggy.c:N:N:
/usr/include/bits/string3.h:107:3: warning: call to __builtin___strcpy_chk will 
always overflow destination buffer


Actual result:
--
No warning at all, dangerous code goes unnoticed.







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

Bug #56213 [Opn->Bgs]: tidy.so not recognized as a valid Zend Extension

2012-01-21 Thread nlopess

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

 ID: 56213
 Updated by: nlop...@php.net
 Reported by:nicolas dot guennoc at edf dot fr
 Summary:tidy.so not recognized as a valid Zend Extension
-Status: Open
+Status: Bogus
 Type:   Bug
-Package:tidy
+Package:*General Issues
 Operating System:   Linux RH 7.2
 PHP Version:4.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:

[2004-10-12 10:06:58] nicolas dot guennoc at edf dot fr

Description:

Hello,
I can't load the tidy php extension.

Here is a description of the employed versions of the softwares :
- Apache 2.0.49
- PHP 4.3.5
- Linux RedHat 7.2
- tidy-02October2003-1 (RPM build from the last sources of tidy)

Here is my PHP configuration line :
'./configure' '--prefix=/logiciels/apache/apa_2.0.49/php_4.3.5' 
'--enable-calendar' 
'--with-config-file-path=/logiciels/apache/apa_2.0.49/php_4.3.5' 
'--with-apxs2=/logiciels/apache/apa_2.0.49/bin/apxs' 
'--with-dom=/logiciels/apache/apa_2.0.49/lib/libxml2_2.6.4' 
'--with-zlib-dir=/logiciels/apache/apa_2.0.49/lib/zlib_1.2.1' 
'--with-zlib=/logiciels/apache/apa_2.0.49/lib/zlib_1.2.1' '--with-gd' 
'--enable-gd-native-ttf' '--with-jpeg-dir=/usr' '--with-png-dir=/usr' 
'--with-dom-xslt=/logiciels/apache/apa_2.0.49/lib/libxslt_1.1.2' 
'--with-dom-exslt=/logiciels/apache/apa_2.0.49/lib/libxslt_1.1.2' 
'--with-ldap=/logiciels/apache/apa_2.0.49/lib/old_2.1.22' 
'--with-mysql=/logiciels/apache/apa_2.0.49/lib/sql_4.0.18' 
'--with-mm=/logiciels/apache/apa_2.0.49/lib/mm_1.3.0' 
'--with-iconv=/logiciels/apache/apa_2.0.49/lib/libiconv_1.9.1' 
'--with-openssl-dir=/logiciels/apache/apa_2.0.49/lib/openssl_0.9.7c' 
'--with-openssl=/logiciels/apache/apa_2.0.49/lib/openssl_0.9.7c' '--enable-ftp' 
'--enable-sockets' '--enable-static' '--disable-shared' '--enable-memory-limit'.

i've tried the following installations of the extension :
- pear installation of tidy 1.1 (using a local download archive, can't go 
through the auth proxy)
- pear installation of tidy 1.0 (using a local download archive, can't go 
through the auth proxy)
- manual installation of tidy 1.1
- manual installation of tidy 1.0
none of them worked. 

BTW, i'm also using xdebug and mmcache on this installation and they're both 
working.
php.ini :
...
Zend_extension="/logiciels/apache/apa_2.0.49/php_4.3.5/lib/php/extensions/no-debug-non-zts-20020429/xdebug.so"
Zend_extension="/logiciels/apache/apa_2.0.49/php_4.3.5/lib/php/extensions/no-debug-non-zts-20020429/mmcache.so"
Zend_extension="/logiciels/apache/apa_2.0.49/php_4.3.5/lib/php/extensions/no-debug-non-zts-20020429/tidy.so"
...

If you wish, i can send you my compiled versions of tidy.so for esasier 
debugging.

Yours sincerely,
NG

Reproduce code:
---










Expected result:

Tidy Module loaded and available

Actual result:
--
Here is the error shown in the error log :
/logiciels/apache/apa_2.0.49/php_4.3.5/lib/php/extensions/no-debug-non-zts-20020429/tidy.so
 doesn't appear to be a valid Zend extension






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

Req #47456 [Asn->Opn]: Missing PCRE option 'J'

2012-01-20 Thread nlopess

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

 ID: 47456
 Updated by: nlop...@php.net
 Reported by:rodricg at sellingsource dot com
 Summary:Missing PCRE option 'J'
-Status: Assigned
+Status: Open
 Type:   Feature/Change Request
 Package:PCRE related
 Operating System:   Linux
 PHP Version:5.3CVS-2009-02-19 (CVS)
-Assigned To:    nlopess
+Assigned To:
 Block user comment: N
 Private report: N



Previous Comments:

[2009-02-19 23:47:05] rodricg at sellingsource dot com

Didn't see how else to include this diff for php_pcre.c
http://diff.pastebin.com/f5639d5a5


[2009-02-19 23:36:11] fel...@php.net

Currently you can only use PCRE_INFO_JCHANGED by (?J) in the pattern. I have 
suggested times ago to the maintainer, but it wasn't accept the addiction of 
'J' as valid modifier in the extension.

Anyway, assigned to maintainer.


[2009-02-19 23:12:33] rodricg at sellingsource dot com

Description:

The PCRE extension does not recognize the 'J' option for setting PCRE_DUPNAMES.

Reproduce code:
---
[ac])(?\d)|(?[b])/J', 'a1bc3', $m, 
PREG_SET_ORDER);
print_r($m);
?>


Expected result:

Array
(
[0] => Array
(
[0] => a1
[chr] => a
[1] => a
[num] => 1
[2] => 1
)
[1] => Array
(
[0] => b
[chr] => b
[1] =>
[num] =>
[2] =>
[3] => b
)
[2] => Array
(
[0] => c3
[chr] => c
[1] => c
[num] => 3
[2] => 3
)
)


Actual result:
--
PHP Warning:  preg_match(): Unknown modifier 'J' in 






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

Bug #49151 [Asn->Opn]: relocation must bind locally

2012-01-20 Thread nlopess

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

 ID: 49151
 Updated by: nlop...@php.net
 Reported by:tech at uscki dot nl
 Summary:relocation must bind locally
-Status: Assigned
+Status: Open
 Type:   Bug
 Package:Compile Failure
 Operating System:   Sun Solaris 5.10 (i386)
 PHP Version:5.3.0
-Assigned To:nlopess
+Assigned To:
 Block user comment: N
 Private report: N



Previous Comments:

[2010-09-13 23:45:24] brentk at birs dot ca

I'm getting the same problem with PHP 5.3.3 on Solaris 10 (x64), gcc 4.3.3.  
The 
compile dies at php_date.o with the same message as the original post.  If I 
remove the "-fvisibility=hidden" part from configure, this doesn't happen.


[2010-05-24 17:20:11] dbakyle at gmail dot com

I've removed the -fvisibility=hidden from the Makefile and tried the make 
again.  
The process is still failing on glob_wrapper.lo

I'm using 4.1.2 of gcc and 2.6.18-92.1.22.0.1 of Red Hat.


[2009-08-17 09:42:07] j...@php.net

It should be as simple as adding 'static' in the macro 
ZEND_DECLARE_MODULE_GLOBALS since those should be static anyway..




[2009-08-14 23:13:32] tech at uscki dot nl

Yeah, got it compiling! I removed "-fvisibility=hidden" from the Makefile after 
running ./configure, guess that boils down to the same result, though your 
suggestion is a bit tidier.

Compiler: gcc (GCC) 4.0.1

Thanks for all your help!


[2009-08-14 21:54:04] nlop...@php.net

sorry, I forgot to say that before ./configure you must run ./buildconf




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=49151


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

Bug #60745 [Opn->Bgs]: Tidy compile error

2012-01-13 Thread nlopess

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

 ID: 60745
 Updated by: nlop...@php.net
 Reported by:jose dot nobile at gmail dot com
 Summary:Tidy compile error
-Status: Open
+Status: Bogus
 Type:   Bug
 Package:Compile Failure
 Operating System:   Centos 5.6 x86_64
 PHP Version:5.3.9
 Block user comment: N
 Private report: N

 New Comment:

that's a problem related with how you compiled tidy vs how you're compiling php.
It's not a bug in PHP.


Previous Comments:

[2012-01-13 16:03:38] jose dot nobile at gmail dot com

A Additional detail.
I'm using a Tidy with HTML5 Support from:
https://github.com/w3c/tidy-html5 (autor is W3C)

In PHP 5.3.8 it work fine.


[2012-01-13 14:41:04] jose dot nobile at gmail dot com

Is a Compile Failure related to Tidy Extension.


[2012-01-13 14:16:49] jose dot nobile at gmail dot com

Description:

I tried to compile PHP 5.3.9 and it show a compile error (make) related to Tidy.


Test script:
---
Over PHP 5.3.9 directory run the next configure (in PHP 5.3.8 this work fine)

'./configure' '--bindir=/usr/bin' '--build=x86_64-redhat-linux-gnu' '--cache-
file=../config.cache' '--datadir=/usr/share' '--disable-rpath' '--enable-bcmath'
'--enable-calendar' '--enable-dba=shared' '--enable-dom' '--enable-exif' '--
enable-ftp' '--enable-gd-jis-conv' '--enable-gd-native-ttf' '--enable-intl' '--
enable-magic-quotes' '--enable-maintainer-zts' '--enable-mbregex' '--enable-
mbstring' '--enable-pcntl' '--enable-pdo' '--enable-shmop' '--enable-soap' '--
enable-soap=shared' '--enable-sockets' '--enable-sqlite-utf8' '--enable-static'
'--enable-sysvmsg' '--enable-sysvsem' '--enable-sysvshm' '--enable-ucd-snmp-
hack' '--enable-wddx' '--enable-zip' '--exec-prefix=/usr' '--host=x86_64-redhat-
linux-gnu' '--includedir=/usr/include' '--infodir=/usr/share/info' '--
libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--
mandir=/usr/share/man' '--prefix=/usr' '--program-prefix=' '--sbindir=/usr/sbin'
'--sharedstatedir=/usr/com' '--sysconfdir=/etc' '--target=x86_64-redhat-linux-
gnu' '--with-apxs2=/usr/sbin/apxs' '--with-bz2' '--with-config-file-path=/etc'
'--with-config-file-scan-dir=/etc/php.d' '--with-curl' '--with-db4=/usr' '--
with-exec-dir=/usr/bin' '--with-freetype-dir=/usr' '--with-gd' '--with-gettext'
'--with-gmp' '--with-iconv' '--with-jpeg-dir=/usr' '--with-kerberos' '--with-
layout=GNU' '--with-ldap' '--with-ldap-sasl' '--with-libdir=lib64' '--with-
libmbfl' '--with-libxml-dir=/usr' '--with-mcrypt' '--with-mhash' '--with-mysql-
sock=/var/lib/mysql/mysql.sock' '--with-mysql=mysqlnd' '--with-mysqli=mysqlnd'
'--enable-mysqlnd' '--with-onig' '--with-openssl' '--with-pcre-regex=/usr' '--
with-pdo-mysql=mysqlnd' '--with-pdo-odbc=shared,unixODBC,/usr' '--with-pdo-
pgsql' '--with-pdo-pgsql=shared,/usr' '--with-pdo-sqlite=shared,/usr' '--with-
pgsql' '--with-pic' '--with-png-dir=/usr' '--with-pspell' '--with-recode' '--
with-snmp' '--with-unixODBC=shared,/usr' '--with-t1lib' '--with-tidy' '--with-
xmlrpc' '--with-xsl' '--with-xsl=shared,/usr' '--with-zlib' '--without-gdbm' '--
enable-zend-multibyte'

Expected result:

Not errors, PHP is compiled fine.

Actual result:
--
/usr/bin/ld: /usr/local/lib/libtidy.a(alloc.o): relocation R_X86_64_32 against 
`a 
local symbol' can not be used when making a shared object; recompile with -fPIC
/usr/local/lib/libtidy.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
make: *** [libphp5.la] Error 1






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

#50887 [Opn->WFx]: preg_match , last optional sub-patterns ignored when empy

2010-01-31 Thread nlopess

 ID:   50887
 Updated by:   nlop...@php.net
 Reported By:  hapo at gmail dot com
-Status:   Open
+Status:   Wont fix
 Bug Type: PCRE related
 Operating System: Windows
 PHP Version:  5.3.1
 New Comment:

I don't think we can change that behaviour at this point for the sake
of not brekaing BC.


Previous Comments:


[2010-01-30 16:58:58] hapo at gmail dot com

Description:

in preg_match , when optional sub-patterns (using ? or {0,n} ) are the
last sub-patterns and empty (e.g. not matched) they are ignored in
$matches array
this behavior is inconsistent with preg_match_all , and with the case
when the empty optional sub-pattern isn't the last one

Reproduce code:
---
$str="1";
preg_match("#\d(\d)?#",$str,$mt);
var_dump($mt);

Expected result:

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

(the string(0) "" does appear on all cases with preg_match_all , and
with preg_match , when there is any additional sub-patterns after it)

Actual result:
--
array(1) {
  [0]=>
  string(1) "1"
}

(the value of sub-pattern vanished)





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

#49151 [Opn]: relocation must bind locally

2009-08-14 Thread nlopess

 ID:   49151
 Updated by:   nlop...@php.net
 Reported By:  tech at uscki dot nl
 Status:   Open
 Bug Type: Compile Failure
 Operating System: Sun Solaris 5.10 (i386)
 PHP Version:  5.3.0
 Assigned To:  nlopess
 New Comment:

you can disable the visibility patch by editing the configure.in file
and removing the occurrence of "-fvisibility=hidden". Then do a
./vcsclean && ./configure && make. Then please report if it worked, and
which compiler version you used. thanks.


Previous Comments:


[2009-08-14 10:08:07] tech at uscki dot nl

Hmmm, adding static isn't trivial, these first two methods were the tip
of the iceberg... Looks like I'll be adding it all through the code if I
go through with this (I stopped after about 10 changes in various
files). 

How do I "disable the visibility thing", as Nuno noted?



[2009-08-13 10:01:53] j...@php.net

in ext/date/php_date.c:485, add static in front of this line:

ZEND_DECLARE_MODULE_GLOBALS(date)




[2009-08-13 09:50:30] tech at uscki dot nl

Hi, the suggestion of making date_ce_date static seems to help! But I'm
not quite there yet :( , date_globals gives a similar error:

ld: fatal: relocation error: R_386_GOTOFF: file
ext/date/.libs/php_date.o: symbol date_globals: relocation must bind
locally

I'm not quite able to find its definition to make that one static as
well (due to my lousy C-skills ... ;) ). Any ideas where to do this?



[2009-08-10 22:51:29] nlop...@php.net

If adding static doesn't help, we can disable the visibility thing on
solaris. (due to the apparently broken compiler/assembler).



[2009-08-05 14:48:12] j...@php.net

Would this help:

ext/date/php_date.c:511

-zend_class_entry *date_ce_date, *date_ce_timezone, *date_ce_interval,
*date_ce_period;
+static zend_class_entry *date_ce_date, *date_ce_timezone,
*date_ce_interval, *date_ce_period;

(add static there :)



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

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

#49151 [Opn]: relocation must bind locally

2009-08-14 Thread nlopess

 ID:   49151
 Updated by:   nlop...@php.net
 Reported By:  tech at uscki dot nl
 Status:   Open
 Bug Type: Compile Failure
 Operating System: Sun Solaris 5.10 (i386)
 PHP Version:  5.3.0
 Assigned To:  nlopess
 New Comment:

sorry, I forgot to say that before ./configure you must run ./buildconf


Previous Comments:


[2009-08-14 16:49:14] nlop...@php.net

you can disable the visibility patch by editing the configure.in file
and removing the occurrence of "-fvisibility=hidden". Then do a
./vcsclean && ./configure && make. Then please report if it worked, and
which compiler version you used. thanks.



[2009-08-14 10:08:07] tech at uscki dot nl

Hmmm, adding static isn't trivial, these first two methods were the tip
of the iceberg... Looks like I'll be adding it all through the code if I
go through with this (I stopped after about 10 changes in various
files). 

How do I "disable the visibility thing", as Nuno noted?



[2009-08-13 10:01:53] j...@php.net

in ext/date/php_date.c:485, add static in front of this line:

ZEND_DECLARE_MODULE_GLOBALS(date)




[2009-08-13 09:50:30] tech at uscki dot nl

Hi, the suggestion of making date_ce_date static seems to help! But I'm
not quite there yet :( , date_globals gives a similar error:

ld: fatal: relocation error: R_386_GOTOFF: file
ext/date/.libs/php_date.o: symbol date_globals: relocation must bind
locally

I'm not quite able to find its definition to make that one static as
well (due to my lousy C-skills ... ;) ). Any ideas where to do this?



[2009-08-10 22:51:29] nlop...@php.net

If adding static doesn't help, we can disable the visibility thing on
solaris. (due to the apparently broken compiler/assembler).



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

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

#49151 [Fbk]: relocation must bind locally

2009-08-10 Thread nlopess

 ID:   49151
 Updated by:   nlop...@php.net
 Reported By:  tech at uscki dot nl
 Status:   Feedback
 Bug Type: Compile Failure
 Operating System: Sun Solaris 5.10 (i386)
 PHP Version:  5.3.0
 Assigned To:  nlopess
 New Comment:

If adding static doesn't help, we can disable the visibility thing on
solaris. (due to the apparently broken compiler/assembler).


Previous Comments:


[2009-08-05 14:48:12] j...@php.net

Would this help:

ext/date/php_date.c:511

-zend_class_entry *date_ce_date, *date_ce_timezone, *date_ce_interval,
*date_ce_period;
+static zend_class_entry *date_ce_date, *date_ce_timezone,
*date_ce_interval, *date_ce_period;

(add static there :)



[2009-08-05 14:39:14] j...@php.net

Assigned to Nuno who's patch broke this.



[2009-08-05 08:26:45] tech at uscki dot nl

Not sure what you mean exactly with that post, but the LDFLAGS are set
before compilation to the following:

export LDFLAGS="$LDFLAGS -L/phil/sw/sunos/i386/lib"
export LDFLAGS="$LDFLAGS -R/phil/sw/sunos/i386/lib"

This all worked fine with php 5.2.9 . Anyway thanks for the help so
far! I will be out for about a week, so I will look at it again by that
time (hopefully with fresh new insight! ;) )

Kind regards,
Coert



[2009-08-04 19:15:30] j...@php.net

http://www.opensolaris.org/jive/thread.jspa?
threadID=35812&tstart=0#145783



[2009-08-04 17:04:26] tech at uscki dot nl

Alas, same result



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

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

#48790 [Opn->Bgs]: Unicode character properties misbehave

2009-07-03 Thread nlopess

 ID:   48790
 Updated by:   nlop...@php.net
 Reported By:  php at pwnt dot be
-Status:   Open
+Status:   Bogus
 Bug Type: PCRE related
 Operating System: All
 PHP Version:  5.2.10
 New Comment:

The reproduce code is broken (I cannot read the input character), but
anyway if this is a bug, it's surelly not in PHP.
If you strongly believe this is a bug, please report it to the PCRE
team.


Previous Comments:


[2009-07-03 17:09:04] php at pwnt dot be

This also occurs on Linux.



[2009-07-03 16:59:52] php at pwnt dot be

Description:

The behavior described at
http://php.net/manual/en/regexp.reference.unicode.php seems to have
changed between PHP 5.2.8 and 5.2.10 (don't know about 5.2.9). I use
preg_match() with a \p regexp to check if a character is a letter (or a
number, in this case), and this seems to fail for wide characters in
5.2.10.

Reproduce code:
---
echo preg_match('/^[\pL\pN]$/', 'é');

Expected result:

1

Actual result:
--
PHP 5.2.8: 1
PHP 5.2.10: 0





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

#48464 [Asn]: No regexp match in utf8 mode

2009-06-03 Thread nlopess

 ID:   48464
 Updated by:   nlop...@php.net
 Reported By:  daniel at poradnik-webmastera dot com
 Status:   Assigned
 Bug Type: PCRE related
 Operating System: windows xp
 PHP Version:  5.2.9
 Assigned To:  nlopess
 New Comment:

I don't have PHP 6 compiled at hand, but I assume that PHP 6 is
replacing the bad char before sending the string to pcre.
Can you check if it's the case by printing $str?


Previous Comments:


[2009-06-03 21:00:20] j...@php.net

Nuno, how come the script says "match" with HEAD?



[2009-06-03 20:49:50] scott...@php.net

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.

Check preg_last_error() it will return PREG_BAD_UTF8_ERROR

\xab isn't valid UTF-8, however \xc2\xab is. It should be 2 bytes.



[2009-06-03 20:49:19] j...@php.net

Works in HEAD.



[2009-06-03 20:48:44] nlop...@php.net

$str is not a valid UTF-8 string, and thus the pcre engine rejects it.
no bug here.



[2009-06-03 17:50:59] daniel at poradnik-webmastera dot com

Description:

preg_match() doesn't match string when utf-8 mode is enabled and 0xAB
char ("«") is present in input. Everything works correctly when
utf-8 mode is disabled.

Reproduce code:
---


Expected result:

'Match' printed

Actual result:
--
'No match' printed





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

#48464 [Opn->Bgs]: No regexp match in utf8 mode

2009-06-03 Thread nlopess

 ID:   48464
 Updated by:   nlop...@php.net
 Reported By:  daniel at poradnik-webmastera dot com
-Status:   Open
+Status:   Bogus
 Bug Type: PCRE related
 Operating System: windows xp
 PHP Version:  5.2.9
 New Comment:

$str is not a valid UTF-8 string, and thus the pcre engine rejects it.
no bug here.


Previous Comments:


[2009-06-03 17:50:59] daniel at poradnik-webmastera dot com

Description:

preg_match() doesn't match string when utf-8 mode is enabled and 0xAB
char ("«") is present in input. Everything works correctly when
utf-8 mode is disabled.

Reproduce code:
---


Expected result:

'Match' printed

Actual result:
--
'No match' printed





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

#48347 [Opn->Bgs]: Connection Interrupted after invalid preg_match_all

2009-05-21 Thread nlopess

 ID:   48347
 Updated by:   nlop...@php.net
 Reported By:  kenorb at gmail dot com
-Status:   Open
+Status:   Bogus
 Bug Type: PCRE related
 Operating System: win32 only - Windows7
 PHP Version:  5.2.9
 New Comment:

just a normal stack overflow.
let's wait for windows binaries with bigger stacks (Pierre!)..


Previous Comments:


[2009-05-21 19:20:52] carsten_sttgt at gmx dot de

I can reproduce this on Windows XP too. But only with PHP as Apache
(2.2.x) Module.
The code is working in a CGI setup or with the CLI in the shell.

In Apaches' error.log you can found:
Parent: child process exited with status 3221225477 -- Restarting.

Regards,
Carsten



[2009-05-21 12:29:36] j...@php.net

Works fine under *nix.



[2009-05-20 19:26:43] kenorb at gmail dot com

Could be related to bug:
#20698 (but of course I can't add a comment there)



[2009-05-20 19:15:52] kenorb at gmail dot com

Description:

Following code crashing whole website.
A could reproduce it with php5.2.9-1 on Win7 (using WAMP).
I couldn't on 5.2.6 on FreeBSD configuration.


Reproduce code:
---
$data = "; \$Id: administerusersbyrole.info,v 1.1.2.1 2009/01/27
20:40:40 smokris Exp \$\nname = Administer Users by Role\ndescription =
\"Allows users with 'administer users' permission and a role (specified
in 'Permissions') to edit/delete other users with a specified role.  If
the user being edited has multiple roles, the user doing the editing
must have permission to edit ALL of the user being edited's roles.  Also
provides control over user creation.  Works well in conjunction with role_delegation.\"\ncore
= 6.x\n\n; Information added by drupal.org packaging script on
2009-01-28\nversion = \"6.x-1.3\"\ncore = \"6.x\"\nproject =
\"administerusersbyrole\"\ndatestamp = \"1233114605\"\n\n";
preg_match_all('
@^\s*   # Start at the beginning of a line,
ignoring leading whitespace
((?:
  [^=;\[\]]|# Key names cannot contain equal
signs, semi-colons or square brackets,
  \[[^\[\]]*\]  # unless they are balanced and not
nested
)+?)
\s*=\s* # Key/value pairs are separated by
equal signs (ignoring white-space)
(?:
  ("(?:[^"]|(?<=)")*")| # Double-quoted string, which may
contain slash-escaped quotes/slashes
  (\'(?:[^\']|(?<=)\')*\')| # Single-quoted string, which may
contain slash-escaped quotes/slashes
  ([^\r\n]*?)   # Non-quoted string
)\s*$   # Stop at the next end of a line,
ignoring trailing whitespace
@msx', $data, $matches, PREG_SET_ORDER);


Expected result:

Continue execution.

Actual result:
--
On Firefox: Connection Interrupted
On Chrome: Error 101 (net::ERR_CONNECTION_RESET): Unknown error.






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

#48196 [Ver->Bgs]: Bug in string concatenation after calling preg_match_all()

2009-05-09 Thread nlopess

 ID:   48196
 Updated by:   nlop...@php.net
 Reported By:  saulo_gil at argentina dot com
-Status:   Verified
+Status:   Bogus
 Bug Type: PCRE related
 Operating System: win32 only - Windows XP
 PHP Version:  5.*, 6CVS (2009-05-09)
 New Comment:

The problem is that the input has \r. This means that $name also has a
\r, which makes the console's cursor go back and override the '[' char.
If you change the EOL of the input file just to \n, you'll see you
expected output.

No bug here.


Previous Comments:


[2009-05-09 04:03:34] j...@php.net

Verified under windows. Does NOT happen with other OSes.



[2009-05-09 01:18:28] saulo_gil at argentina dot com

Forgot to mention one thing, I've tried to reproduce this bug using the
PHP CLI, calling this script with php.exe -q 
I've just reproduced it again on a freshly installed XP box. Same
happened with PHP 5.2.9-2.



[2009-05-08 23:26:18] fel...@php.net

I can't reproduce it.



[2009-05-08 20:33:55] saulo_gil at argentina dot com

Description:

If I try to perform a simple concatenation involving a variable created
from the matches output of preg_match_all() the resulting string is
borked. Please see the code above.

What I want to do: echo "[" . $var . "]";


Reproduce code:
---


Expected result:

[SPD_EXECUTIVE_PROVIDER_DEALER]

Actual result:
--
]SPD_EXECUTIVE_PROVIDER_DEALER





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

#47811 [Asn->Bgs]: preg_match that can cause segmentation fault

2009-04-14 Thread nlopess

 ID:   47811
 Updated by:   nlop...@php.net
 Reported By:  travis at wikihow dot com
-Status:   Assigned
+Status:   Bogus
 Bug Type: Reproducible crash
 Operating System: CentOS release 4.4 & Mac OS 10.4
 PHP Version:  5.2.9
 Assigned To:  nlopess
 New Comment:

Felipe is right. This is not a bug, just the expected stack overflow.
You can "fix" the problem by increasing the stack size.


Previous Comments:


[2009-04-02 12:39:01] fel...@php.net

This stack overflow is expected. See the earlies bug reports.



[2009-04-02 12:27:26] Phil dot H at gmx dot net

Another php preg_match crash using php 5.2.9-1 on Windows XP and
2003R2:

 (?:.(?!\[% ))*.(?=\[%| $))/isx';

if (preg_match($regexp, $string, $aMatches, PREG_OFFSET_CAPTURE, 0)) {
echo "matched\n";
}
echo "finished";
?>



[2009-03-30 12:22:15] paj...@php.net

Nuno, can you take a look please? Can reproduce it here too.



[2009-03-30 11:24:40] scope at planetavent dot de

Here's another snippet:



This one crashes apache 2.2.8 and 2.2.11 with php-5.2.9 and php-5.2.9-1
on windows 2003.



[2009-03-27 23:53:44] dennis dot birkholz at nexxes dot net

I have a similar segfault testcase for preg_match. It always crashes at
a stringlength of around 6700. PHP is 5.2.8 on gentoo linux.

# Create my test-string
for ($i=0; $i<2; $i++) {
$string .= 'a';
}

# The pattern matches for \\, \", everything except " and "
$pattern = '/^(|\\"|[^"]|")+$/';

print "Trying with string length " . "\033" . '[s';

for ($counter=6600; $counterhttp://bugs.php.net/47811

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

#47586 [Opn->Bgs]: preg_replace_callback crashes on static method call that are NOT defined static

2009-04-10 Thread nlopess

 ID:   47586
 Updated by:   nlop...@php.net
 Reported By:  didier dot peereboom at gmail dot com
-Status:   Open
+Status:   Bogus
 Bug Type: PCRE related
 Operating System: linux
 PHP Version:  5.2.9
 New Comment:

works here with 5.3-cvs.


Previous Comments:


[2009-03-10 10:34:07] j...@php.net

Note: Your script does not crash for me with PHP 5.2.9.




[2009-03-06 12:17:39] didier dot peereboom at gmail dot com

Description:

preg_replace_callback can be passed a method, including static
methods.

However if said function is not declared with the keyword static then
it crashes hard. This is NOT the same as the behavior call_user_func
which continues happily no matter what the function has been declared
as.

Either call_user_func is wrong in working with incorrect code or
preg_replace_callback is wrong in not working. The hard crash itself can
hardly be intended behavior in either case.



Reproduce code:
---
ToBeCalledStatic('Regular');
testing::ToBeCalledStatic('Static call');
$var = "Method passed as array";
$var1 = "Method passed as static string";
$func = array('testing','ToBeCalledStatic');
$func1 = 'testing::ToBeCalledStatic';
call_user_func($func, $var);
preg_replace_callback('/.*/', $func , $var);
call_user_func($func1, $var1);
preg_replace_callback('/.*/', $func1 , $var1);
}
function ToBeCalledStatic($msg) {
echo "Been called with [{$msg}]\n";
}
}
$tmp1 = new testing();
$tmp1->Main();
?>

Expected result:

Either an error message in both cases that the function should be
declared static OR to work in both cases.

Not to work for call_user_func and fail for preg_replace_callback.

Perhaps with the update to the static notiation option
preg_replace_callback was overlooked?


Actual result:
--
Been called with [Regular]
Been called with [Static call]
Been called with [Method passed as array]
Been called with [Array]
Been called with [Array]

Warning: call_user_func(testing::ToBeCalledStatic): First argument is
expected to be a valid callback in /home/didier/test.php on line 12

Call Stack:
0.0002 115008   1. {main}() /home/didier/test.php:0
0.0002 115384   2. testing->Main() /home/didier/test.php:20
0.0004 118432   3. call_user_func() /home/didier/test.php:12

Dump $_SERVER
Dump $_GET
Dump $_POST
Dump $_COOKIE
Dump $_FILES
Dump $_ENV
Dump $_SESSION
Dump $_REQUEST

Warning: preg_replace_callback(): Requires argument 2,
'testing::ToBeCalledStatic', to be a valid callback in
/home/didier/test.php on line 13

Call Stack:
0.0002 115008   1. {main}() /home/didier/test.php:0
0.0002 115384   2. testing->Main() /home/didier/test.php:20
0.0005 119104   3. preg_replace_callback()
/home/didier/test.php:13






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

#47526 [Opn->Bgs]: PCRE fails on Unicode surrogates

2009-04-10 Thread nlopess

 ID:   47526
 Updated by:   nlop...@php.net
 Reported By:  phpwnd at gmail dot com
-Status:   Open
+Status:   Bogus
 Bug Type: PCRE related
 Operating System: *
 PHP Version:  5.3CVS-2009-02-28 (CVS)
 New Comment:

As far as I understand that codepoint is invalid in UTF-8.
If you call preg_last_error() after preg_match() it will return
PREG_BAD_UTF8_ERROR, confirming my hipothesis.
So no bug here.


Previous Comments:


[2009-02-28 08:51:18] phpwnd at gmail dot com

Description:

According to http://docs.php.net/manual/en/regexp.reference.php PCRE
functions should be able to match surrogates in Unicode mode. However,
it is my understanding that surrogates are not allowed in UTF-8, which
is the encoding used by the Unicode mode. That would explain why
preg_match() and preg_replace() fail when operating on UTF-8-encoded
surrogates.

Note that both functions fail in a different way. preg_match() returns
0 whereas preg_replace() returns NULL.

I'm not sure what the fix should be. Being able to match surrogates
would make my life easier, but if it's not valid UTF-8 then it might be
more consistent (albeit in a twisted way) to return NULL, as that's what
PCRE functions do on invalid UTF-8.

Reproduce code:
---
// \xED\xA0\x80 is character 0xD800 in UTF-8
var_dump(preg_match('#.#u', ".\xED\xA0\x80"));
var_dump(preg_replace('#\p{Cs}#u', '', ".\xED\xA0\x80"));

Expected result:

int(1)
string(1) "."

Actual result:
--
int(0)
NULL





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

#47662 [Asn->Csd]: Crash with more that 127 named Subpattern

2009-04-10 Thread nlopess

 ID:   47662
 Updated by:   nlop...@php.net
 Reported By:  gmblar+php at gmail dot com
-Status:   Assigned
+Status:   Closed
 Bug Type: PCRE related
 Operating System: MacOSX 10.5
 PHP Version:  5.2.9
 Assigned To:  nlopess
 New Comment:

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:


[2009-04-10 15:31:14] nlop...@php.net

there's something wrong with the pcre library. I'll take a look.



[2009-04-06 23:19:27] gmblar+php at gmail dot com

PCRE fails with more that 127 Subpattern if PHP compiled as 64-Bit-
Binary



[2009-04-06 23:17:11] gmblar+php at gmail dot com

Problem only appears if PHP is compiled with 64-bit Support (x86_64)


$ gdb ./php
GNU gdb 6.3.50-20050815 (Apple version gdb-962) (Sat Jul 26 08:14:40 
UTC 2008)
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 "i386-apple-darwin"...Reading symbols for 
shared libraries .. done

(gdb) run ./test.php
Starting program: /Users/Blar/Sites/php/php-5.2.9/sapi/cli/php 
./test.php
warning: posix_spawn failed, trying execvp, error: 86
Reading symbols for shared libraries +.. done

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x00010079ae10
0x00010002308f in make_subpats_table (num_subpats=257, 
pce=0x101008b60) at /Users/Blar/Sites/php/php-
5.2.9/ext/pcre/php_pcre.c:213
213 subpat_names[name_idx] = name_table + 
2;
(gdb) bt
#0  0x00010002308f in make_subpats_table (num_subpats=257, 
pce=0x101008b60) at /Users/Blar/Sites/php/php-
5.2.9/ext/pcre/php_pcre.c:213
#1  0x0001000243b7 in php_pcre_match_impl (pce=0x101008b60, 
subject=0x10071a998 "foobar", subject_len=6, return_value=0x10071ad10,

subpats=0x0, global=0, use_flags=0, 
flags=0, start_offset=0) at /Users/Blar/Sites/php/php-
5.2.9/ext/pcre/php_pcre.c:598
#2  0x000100024196 in php_do_pcre_match (ht=2, 
return_value=0x10071ad10, return_value_ptr=0x0, this_ptr=0x0, 
return_value_used=0, global=0) at /Users/Blar/Sites/php/php-
5.2.9/ext/pcre/php_pcre.c:513
#3  0x000100025017 in zif_preg_match (ht=2, 
return_value=0x10071ad10, return_value_ptr=0x0, this_ptr=0x0, 
return_value_used=0) at /Users/Blar/Sites/php/php-
5.2.9/ext/pcre/php_pcre.c:762
#4  0x0001002f0803 in zend_do_fcall_common_helper_SPEC 
(execute_data=0x7fff5fbfebd0) at zend_vm_execute.h:200
#5  0x0001002f72b3 in ZEND_DO_FCALL_SPEC_CONST_HANDLER 
(execute_data=0x7fff5fbfebd0) at zend_vm_execute.h:1729
#6  0x0001002f0223 in execute (op_array=0x1007198d0) at 
zend_vm_execute.h:92
#7  0x0001002c599b in zend_execute_scripts (type=8, retval=0x0, 
file_count=3) at /Users/Blar/Sites/php/php-5.2.9/Zend/zend.c:1134
#8  0x000100263d28 in php_execute_script 
(primary_file=0x7fff5fbff5c0) at /Users/Blar/Sites/php/php-
5.2.9/main/main.c:2023
#9  0x000100351d7c in main (argc=2, argv=0x7fff5fbff728) at 
/Users/Blar/Sites/php/php-5.2.9/sapi/cli/php_cli.c:1133



[2009-04-06 21:00:31] j...@php.net

Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.





[2009-03-26 15:02:00] mmcnicklebugs at googlemail dot com

I can't replicate on Linux/Ubuntu 8.04 with 5.3CVS or 5.2.*

When I increase the number of patterns to a large number (say 6) I
get a suitable warning:

Warning: preg_match(): Compilation failed: too many named subpatterns
(maximum 1) at offset 148903 in
/home/martin/php_bugs/pcre/47622/test.php on line 10



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

#47662 [Opn->Asn]: Crash with more that 127 named Subpattern

2009-04-10 Thread nlopess

 ID:   47662
 Updated by:   nlop...@php.net
 Reported By:  gmblar+php at gmail dot com
-Status:   Open
+Status:   Assigned
 Bug Type: PCRE related
 Operating System: MacOSX 10.5
 PHP Version:  5.2.9
-Assigned To:  
+Assigned To:  nlopess
 New Comment:

there's something wrong with the pcre library. I'll take a look.


Previous Comments:


[2009-04-06 23:19:27] gmblar+php at gmail dot com

PCRE fails with more that 127 Subpattern if PHP compiled as 64-Bit-
Binary



[2009-04-06 23:17:11] gmblar+php at gmail dot com

Problem only appears if PHP is compiled with 64-bit Support (x86_64)


$ gdb ./php
GNU gdb 6.3.50-20050815 (Apple version gdb-962) (Sat Jul 26 08:14:40 
UTC 2008)
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 "i386-apple-darwin"...Reading symbols for 
shared libraries .. done

(gdb) run ./test.php
Starting program: /Users/Blar/Sites/php/php-5.2.9/sapi/cli/php 
./test.php
warning: posix_spawn failed, trying execvp, error: 86
Reading symbols for shared libraries +.. done

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x00010079ae10
0x00010002308f in make_subpats_table (num_subpats=257, 
pce=0x101008b60) at /Users/Blar/Sites/php/php-
5.2.9/ext/pcre/php_pcre.c:213
213 subpat_names[name_idx] = name_table + 
2;
(gdb) bt
#0  0x00010002308f in make_subpats_table (num_subpats=257, 
pce=0x101008b60) at /Users/Blar/Sites/php/php-
5.2.9/ext/pcre/php_pcre.c:213
#1  0x0001000243b7 in php_pcre_match_impl (pce=0x101008b60, 
subject=0x10071a998 "foobar", subject_len=6, return_value=0x10071ad10,

subpats=0x0, global=0, use_flags=0, 
flags=0, start_offset=0) at /Users/Blar/Sites/php/php-
5.2.9/ext/pcre/php_pcre.c:598
#2  0x000100024196 in php_do_pcre_match (ht=2, 
return_value=0x10071ad10, return_value_ptr=0x0, this_ptr=0x0, 
return_value_used=0, global=0) at /Users/Blar/Sites/php/php-
5.2.9/ext/pcre/php_pcre.c:513
#3  0x000100025017 in zif_preg_match (ht=2, 
return_value=0x10071ad10, return_value_ptr=0x0, this_ptr=0x0, 
return_value_used=0) at /Users/Blar/Sites/php/php-
5.2.9/ext/pcre/php_pcre.c:762
#4  0x0001002f0803 in zend_do_fcall_common_helper_SPEC 
(execute_data=0x7fff5fbfebd0) at zend_vm_execute.h:200
#5  0x0001002f72b3 in ZEND_DO_FCALL_SPEC_CONST_HANDLER 
(execute_data=0x7fff5fbfebd0) at zend_vm_execute.h:1729
#6  0x0001002f0223 in execute (op_array=0x1007198d0) at 
zend_vm_execute.h:92
#7  0x0001002c599b in zend_execute_scripts (type=8, retval=0x0, 
file_count=3) at /Users/Blar/Sites/php/php-5.2.9/Zend/zend.c:1134
#8  0x000100263d28 in php_execute_script 
(primary_file=0x7fff5fbff5c0) at /Users/Blar/Sites/php/php-
5.2.9/main/main.c:2023
#9  0x000100351d7c in main (argc=2, argv=0x7fff5fbff728) at 
/Users/Blar/Sites/php/php-5.2.9/sapi/cli/php_cli.c:1133



[2009-04-06 21:00:31] j...@php.net

Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.





[2009-03-26 15:02:00] mmcnicklebugs at googlemail dot com

I can't replicate on Linux/Ubuntu 8.04 with 5.3CVS or 5.2.*

When I increase the number of patterns to a large number (say 6) I
get a suitable warning:

Warning: preg_match(): Compilation failed: too many named subpatterns
(maximum 1) at offset 148903 in
/home/martin/php_bugs/pcre/47622/test.php on line 10



[2009-03-15 14:37:22] gmblar+php at gmail dot com

Description:

With more than 63 Subpattern in a Regular-Expression, PHP crashes with
a 
Segmention-Fault.

Reproduce code:
---
))';
}
$regex .= '@';
 
preg_match($regex, 'foobar');

?>

Expected result:

Nothing

Actual result:
--
$ php foobar.php
Segmentation fault






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

#47689 [Opn->Asn]: crash with certain regular expression

2009-04-10 Thread nlopess

 ID:   47689
 Updated by:   nlop...@php.net
 Reported By:  vr...@php.net
-Status:   Open
+Status:   Assigned
 Bug Type: PCRE related
-Operating System: Windows
+Operating System: Windows only
-PHP Version:  5.2.9
+PHP Version:  *
-Assigned To:  
+Assigned To:  pajoye
 New Comment:

this is the usual stack problem.
Since we now use the stack for PCRE recursion on Windows, I think we
could increase the stack size. The default (1 MB) is a little short..
Pierre: can you please increase the stack size on windows binaries to
e.g. 8 MB? It's a matter of adding one parameter to the compile
arguments.
More details at:
http://msdn.microsoft.com/en-us/library/tdkhxaks(VS.71).aspx


Previous Comments:


[2009-03-19 10:22:04] vr...@php.net

Both configuration directives are on the default value 10.

I've found out that with much longer input (600 lines) the script
crashes also in CLI.

There's no crash in PHP 5.2.8, only PHP 5.2.9 is affected.



[2009-03-18 23:16:14] fel...@php.net

Hi Jakub,
please check the pcre.backtrack_limit and pcre.recursion_limit value.



[2009-03-18 13:10:15] vr...@php.net

I've uploaded the backtrace analysis to
http://www.vrana.cz/phpbug47689.zip



[2009-03-17 13:57:03] vr...@php.net

Description:

Apache 2.2.11 crashes with PHP 5.2.9-1 on the following code. The same
script run from CLI executes without crash.

Reproduce code:
---
http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing,
 * software distributed under the License is distributed on an
 * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
 * KIND, either express or implied.  See the License for the
 * specific language governing permissions and limitations
 * under the License.
 */';
// shortest possible example, omitting last line causes no crash

$contents = preg_replace('@/\\*(?:.|[\\n\\r])*?\\*/@', '', $contents);
?>


Expected result:

Empty string in $contents.

Actual result:
--
Apache crash.





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

#47907 [Opn->Bgs]: Segmentation fault during many preg_matches

2009-04-10 Thread nlopess

 ID:   47907
 Updated by:   nlop...@php.net
 Reported By:  tafkad at web dot de
-Status:   Open
+Status:   Bogus
 Bug Type: PCRE related
 Operating System: Linux Debian Lenny
 PHP Version:  5.2.9
 New Comment:

It doesn't crash for me. It seems you need to increase the stack size
(with ulimit -s).


Previous Comments:


[2009-04-06 13:02:29] tafkad at web dot de

Description:

I use a class(phpcc) to transform a searchstring into an SQL where
clause. If it has many options like brackets or operators or if it is a
very long string php ends in a segmentation fault. I've tested it with
two php version 5.2.6 and 5.2.9. I use the cli version.

I've created a test script with a for loop that generates a simple
searchstatement with 2000 searchterms. If I run this script it crash.
When I'll decrase the amount of searchterms to 1000 it will run clean.

GDB shows preg_match as last execute, thats why I think there must be
an error.

The script uses a very huge amount of memory(I've configured php.ini
with 1024M).

php.ini changes from against default(debian)
max_execution_time = 3 ; 30 ; Maximum execution time of each
script, in seconds
max_input_time = 6 ; 60 ; Maximum amount of time each script may
spend parsing request data
;max_input_nesting_level = 64 ; Maximum input variable nesting level
memory_limit = 1024M ; 32M  ; Maximum amount of memory a script may
consume (32MB)

Active modules (php -m)
[PHP Modules]
bcmath,bz2,calendar,ctype,curl,date,dba,dbase,dom,exif,ffmpeg,filter,ftp,gd,gettext,hash,iconv,json,libxml,mbstring,mime_magic,mysql,mysqli,ncurses,openssl,pcntl,pcre,PDO,pdo_mysql,posix,readline,Reflection,session,shmop,SimpleXML,soap,sockets,SPL,standard,sysvmsg,sysvsem,sysvshm,tidy,tokenizer,wddx,xml,xmlreader,xmlwriter,zip,zlib

Reproduce code:
---
Code is to long.
Under http://paste.root-zone.info/debug.tar.gz is a dir with the class
and an testscript.


Expected result:

Before the script can finish, php crashes.

Actual result:
--
#23 0x004783db in match (eptr=0x0,
ecode=0x107108e8 "'TESTSTR1160' or OR_ID = 'TESTSTR1161' or
OR_ID = 'TESTSTR1162' or OR_ID = 'TESTSTR1163' or OR_ID =
'TESTSTR1164' or OR_ID = 'TESTSTR1165' or OR_ID =
'TESTSTR1166' or OR_ID"..., mstart=0x2 , offset_top=32767, md=0x0, ims=15, eptrb=0x47a157,
flags=0, rdepth=0)
at
/usr/src/php5/source/php5-5.2.9/ext/pcre/pcrelib/pcre_exec.c:1184
#24 0x0047a157 in match (eptr=0x1 ,
ecode=0x107108e8 "'TESTSTR1160' or OR_ID = 'TESTSTR1161' or
OR_ID = 'TESTSTR1162' or OR_ID = 'TESTSTR1163' or OR_ID =
'TESTSTR1164' or OR_ID = 'TESTSTR1165' or OR_ID =
'TESTSTR1166' or OR_ID"..., mstart=0x2 , offset_top=32767, md=0x0, ims=3, eptrb=0x4803f4,
flags=0, rdepth=0)
at
/usr/src/php5/source/php5-5.2.9/ext/pcre/pcrelib/pcre_exec.c:714
#25 0x004803f4 in match (eptr=0x2ed1fe5 "",
ecode=0x107108e8 "'TESTSTR1160' or OR_ID = 'TESTSTR1161' or
OR_ID = 'TESTSTR1162' or OR_ID = 'TESTSTR1163' or OR_ID =
'TESTSTR1164' or OR_ID = 'TESTSTR1165' or OR_ID =
'TESTSTR1166' or OR_ID"..., mstart=0x27c2b71e0 , offset_top=32767, md=0x0, ims=45889320, eptrb=0x481f97,
flags=0, rdepth=0)
at
/usr/src/php5/source/php5-5.2.9/ext/pcre/pcrelib/pcre_exec.c:2035
#26 0x00481f97 in php_pcre_exec (argument_re=0x10716821,
extra_data=0x2ed2016, subject=0x20 ,
length=275843303, start_offset=0,
options=275843304, offsets=0x488020, offsetcount=275614368) at
/usr/src/php5/source/php5-5.2.9/ext/pcre/pcrelib/pcre_exec.c:4844
#27 0x00488020 in php_pcre_match_impl (pce=0x107108e8,
subject=0x5f390048662f ,
subject_len=0, return_value=0x10718550,
subpats=0xc106f7fd0, global=0, use_flags=4753947, flags=0,
start_offset=0) at
/usr/src/php5/source/php5-5.2.9/ext/pcre/php_pcre.c:621
#28 0x00488a1b in php_do_pcre_match (ht=3,
return_value=0x106f7fd0, return_value_ptr=0x7fff7c2b31a0,
this_ptr=0x7fff7c2b31b0, return_value_used=208324, global=0)
at /usr/src/php5/source/php5-5.2.9/ext/pcre/php_pcre.c:513
#29 0x006c01ad in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fff7c2b7b60) at
/usr/src/php5/source/php5-5.2.9/Zend/zend_vm_execute.h:200
#30 0x006ac6a4 in execute (op_array=0x2be9420) at
/usr/src/php5/source/php5-5.2.9/Zend/zend_vm_execute.h:92
#31 0x006bfabe in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fff7c2b8410) at
/usr/src/php5/source/php5-5.2.9/Zend/zend_vm_execute.h:234
#32 0x006ac6a4 in execute (op_array=0x2bbd4e8) at
/usr/src/php5/source/php5-5.2.9/Zend/zend_vm_execute.h:92
#33 0x006bfabe in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fff7c2b9110) at
/usr/src/php5/source/php5-5.2.9/Zend/zend_vm_execute.h:234
#34 0x006ac6a4 in execute (op_array=0x2be08b8) at
/usr/src

#47480 [Opn->Bgs]: preg_replace with "/i" is not case insensitive

2009-03-12 Thread nlopess

 ID:   47480
 Updated by:   nlop...@php.net
 Reported By:  sehh at ionos dot gr
-Status:   Open
+Status:   Bogus
 Bug Type: PCRE related
 Operating System: Linux
 PHP Version:  5.2.8
 New Comment:

not an issue in php. check the unicode standard.


Previous Comments:


[2009-03-12 09:39:51] sehh at ionos dot gr

Do you think it would be better if I contacted the developers of the
PCRE library at http://www.pcre.org/ ?

Maybe submitting a patch or bug report to them would cover a lot more
open source projects, instead of patching the PCRE library used by php
only.



[2009-03-09 17:20:56] mmcnickle at gmail dot com

It wouldn't be impossible, no. But to someone without detailed
knowledge of Greek it would be. The unicode.org article on regular
expressions [1] has this to say:

"All of the above deals with a default specification for a regular
expression. However, a regular expression engine also may want to
support tailored specifications, typically tailored for a particular
language or locale. This may be important when the regular expression
engine is being used by end-users instead of programmers, such as in a
word-processor allowing some level of regular expressions in
searching."

Earlier in the document it says about how basic regex engines are only
required to include the basic unicode uppercase/lowercase matching.

Looking though the source code of the PRCE library, it does seem
possible to generate locale-specific character tables; this may be an
avenue to look into.

Perhaps the best thing to do would be to drop a message in the
internationalization mailing list (http://marc.info/?l=php-i18n) and see
what they have to say.

[1] http://unicode.org/reports/tr18/#Tailored_Support



[2009-03-09 16:01:59] sehh at ionos dot gr

Indeed thats far from ideal, its impossible from my development point
of view to re-write every single accented character with its possible
equivalent for the entire string, for every string in the regex.

For example, this:
/Âáëâßäåò åéóáãùãÞò-åîáãùãÞò/i

Would become a monster like this:
/Âáëâ[É|ß|º]ä[Å|å|¸]ò åéóáãùã[Ç|Þ|¹]ò-åîáãùã[Ç|Þ|¹]ò/i

We would need a regex to create the regex! or at least a text
search/replace method in PHP.

Are you sure its impossible to add a few exceptions within the PCRE
library?



[2009-03-09 15:25:51] mmcnickle at gmail dot com

Yes, unfortunately trying to include locale and language specific cases
is next to impossible for regular expression engine developers. 

The best that can be done, though far from ideal, is for the user to
try to take these changes into account when they are crafting the
regex:

$target1 = "ÊÉÍÇÔ[Ç|Þ]ÑÁ"; // Greek;

$target1 = "Stra[ss|ß]ebahn" // German



[2009-03-09 15:00:25] sehh at ionos dot gr

I forgot the capital accented characters, so the above should read:

"Ç" == "Þ" == "ç" == "¹"
"Á" == "Ü" == "á" == "¶"
etc..

Remember that in Greek, the accent may be omitted from capital letters
or may be included for the first letter only. So that should produce
proper case-insensitive results.



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

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

#46347 [Asn->Csd]: parse_ini_file() does not like asterisk (*) in key

2009-02-02 Thread nlopess

 ID:   46347
 Updated by:   nlop...@php.net
 Reported By:  duke at masendav dot com
-Status:   Assigned
+Status:   Closed
 Bug Type: Scripting Engine problem
 Operating System: *
 PHP Version:  5.3CVS-2008-11-11
 Assigned To:  scottmac
 New Comment:

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:


[2009-01-01 23:10:10] nlop...@php.net

jani: try [*] or "*" to match a single '*' char



[2009-01-01 11:57:00] j...@php.net

I don't know how to allow literal * in re2c. (\* did not work)
And I don't have spare time to debug this. Ask Pierre if he has.



[2008-12-24 13:58:39] scott...@php.net

Jani, this wasn't broken by any of the re2c stuff.

The changes you made to zend_ini_scanner.l revision 1.48 are the cause.



[2008-10-20 21:01:03] duke at masendav dot com

More like undocumented feature then. Nothing at
http://www.php.net/parse_ini_file says that * cannot be used inside
keys. So we are using it in a few in-house applications and this came as
unpleasant surprise.

We can of course implement a different solution, if you really consider
the current (5.2) behaviour bug.

In which case it would be nice to have a better explanation in
parse_ini_file documentation with regard to what is considered a valid
syntax and what not.



[2008-10-20 20:45:16] j...@php.net

Why should it like it? That looks like a bug that got fixed by the 
new parser. 



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

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

#47229 [Csd]: preg_quote should escape "-" (minus) as well

2009-01-28 Thread nlopess

 ID:   47229
 Updated by:   nlop...@php.net
 Reported By:  daniel at code-emitter dot com
 Status:   Closed
 Bug Type: PCRE related
 Operating System: any, see docs
 PHP Version:  5.2.8
 Assigned To:  nlopess
 New Comment:

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:


[2009-01-28 13:23:30] fel...@php.net

Ah, OK.

Assigning to maintainer...



[2009-01-28 12:44:48] daniel at code-emitter dot com

preg_match('/^([a-zA-Z0-9'.preg_quote("!#$%&'*+-/=?^_`{|}~.",
'/').']{1,64})@(.*)$/', $address, $matches)

This will not work. I got this regexp from an example somewhere in the
docs, so it seems that I'm not the only one who has built this into his
application.



[2009-01-28 12:42:35] daniel at code-emitter dot com

preg_match('/^([a-zA-Z0-9\-'.preg_quote("!#$%&'*+/=?^_`{|}~.",
'/').']{1,64})@(.*)$/', $address, $matches)

But this will become a problem, when mixing like shown above. An
escaped "-" outside of [...] does no harm, but an unescaped "-" inside
does.



[2009-01-28 12:38:36] fel...@php.net

The '-' just have special meaning in the regex when used whithin '[ ]',
which are escaped as expected. So, there is no possibility to '-' break
something.

var_dump(preg_quote("[0-2]")); // string(7) "\[0-2\]"



[2009-01-28 12:23:33] daniel at code-emitter dot com

Description:

preg_quote does not escape the "-" (minus) character but it should.

Reproduce code:
---
preg_quote("0-9", '/')

Expected result:

preg_quote("0-9", '/') == "0\-9"

Actual result:
--
preg_quote("0-9", '/') == "0-9"

Depending on the used string this can become a dead loss of the used
regular expression because all characters become valid.





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

#46347 [Asn]: parse_ini_file() does not like asterisk (*) in key

2009-01-01 Thread nlopess

 ID:   46347
 Updated by:   nlop...@php.net
 Reported By:  duke at masendav dot com
 Status:   Assigned
 Bug Type: Scripting Engine problem
 Operating System: *
 PHP Version:  5.3CVS-2008-11-11
 Assigned To:  scottmac
 New Comment:

jani: try [*] or "*" to match a single '*' char


Previous Comments:


[2009-01-01 11:57:00] j...@php.net

I don't know how to allow literal * in re2c. (\* did not work)
And I don't have spare time to debug this. Ask Pierre if he has.



[2008-12-24 13:58:39] scott...@php.net

Jani, this wasn't broken by any of the re2c stuff.

The changes you made to zend_ini_scanner.l revision 1.48 are the cause.



[2008-10-20 21:01:03] duke at masendav dot com

More like undocumented feature then. Nothing at
http://www.php.net/parse_ini_file says that * cannot be used inside
keys. So we are using it in a few in-house applications and this came as
unpleasant surprise.

We can of course implement a different solution, if you really consider
the current (5.2) behaviour bug.

In which case it would be nice to have a better explanation in
parse_ini_file documentation with regard to what is considered a valid
syntax and what not.



[2008-10-20 20:45:16] j...@php.net

Why should it like it? That looks like a bug that got fixed by the 
new parser. 



[2008-10-20 19:40:21] duke at masendav dot com

Description:

parse_ini_file no longer likes * (asterisk) in configuration keys.

Works just fine in PHP 5.2.5


Reproduce code:
---
Ini file with the following content:
[section]
part1.*.part2 = 1

PHP file:
http://bugs.php.net/?id=46347&edit=1

#46844 [Csd->Opn]: First line of included files not output if they begin with #

2009-01-01 Thread nlopess

 ID:   46844
 Updated by:   nlop...@php.net
 Reported By:  phildrisc...@php.net
-Status:   Closed
+Status:   Open
 Bug Type: Scripting Engine problem
 Operating System: Ubuntu Gutsy
 PHP Version:  5.3.0alpha3
 New Comment:

reopen, the bug is still alive.
just change test.inc to
#!1
...


Previous Comments:


[2009-01-01 20:19:46] il...@php.net

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.





[2008-12-29 12:52:01] johan...@php.net

That should be fixed for 5.3.



[2008-12-17 02:45:55] j...@php.net

I was kinda hoping it was some CLI/CGI thing only. :)





[2008-12-16 18:41:52] phildrisc...@php.net

Yes Jani - my test setup has PHP compiled as an Apache2 module.



[2008-12-16 18:20:41] j...@php.net

I can reproduce this with CLI and CGI, but does it happen also with
f.e. Apache SAPIs? 



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

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

#46959 [Opn->WFx]: PCRE compiles even if configured not to compile it

2008-12-28 Thread nlopess

 ID:   46959
 Updated by:   nlop...@php.net
 Reported By:  ravitanra at gmail dot com
-Status:   Open
+Status:   Wont fix
 Bug Type: PCRE related
 Operating System: Linux
 PHP Version:  5.2.8
 New Comment:

this is by design.
Some time ago it was decided to disallow the disabling of some core
extensions, pcre included.


Previous Comments:


[2008-12-28 08:21:46] ravitanra at gmail dot com

Description:

I am trying to build a minimal PHP by removing heavy stuff like PCRE. 

Problem is that PCRE always compiles even if configured not to compile
it. Below is the configure line

./configure --prefix=/rt --exec-prefix=/rt
--with-config-file-path=/rt/etc --disable-all --disable-ipv6
--with-pcre-regex=no --disable-posix --disable-session
--disable-reflection --disable-simplexml --disable-xml
--disable-xmlreader --disable-xmlwriter --without-pear
--disable-inline-optimization --enable-maintainer-zts
--enable-embed=static --disable-pcre

I also tried "--without-pcre-regex" without any luck. All PCRE function
are present in the final build. Please refer to output of the build
below


/bin/sh /root/php-5.2.8/libtool --silent --preserve-dup-deps
--mode=link /root/php-5.2.8/meta_ccld -export-dynamic -g -O2 -pthread
-DZTS ext/pcre/pcrelib/pcre_chartables.lo
ext/pcre/pcrelib/pcre_ucd.lo ext/pcre/pcrelib/pcre_compile.lo
ext/pcre/pcrelib/pcre_config.lo ext/pcre/pcrelib/pcre_exec.lo
ext/pcre/pcrelib/pcre_fullinfo.lo ext/pcre/pcrelib/pcre_get.lo
ext/pcre/pcrelib/pcre_globals.lo ext/pcre/pcrelib/pcre_info.lo
ext/pcre/pcrelib/pcre_maketables.lo ext/pcre/pcrelib/pcre_newline.lo
ext/pcre/pcrelib/pcre_ord2utf8.lo ext/pcre/pcrelib/pcre_refcount.lo
ext/pcre/pcrelib/pcre_study.lo ext/pcre/pcrelib/pcre_tables.lo
ext/pcre/pcrelib/pcre_try_flipped.lo ext/pcre/pcrelib/pcre_valid_utf8.lo
ext/pcre/pcrelib/pcre_version.lo ext/pcre/pcrelib/pcre_xclass.lo
ext/pcre/php_pcre.lo ext/date/php_date.lo ext/date/lib/astro.lo
ext/date/lib/dow.lo ext/date/lib/parse_date.lo ext/date/lib/parse_tz.lo
ext/date/lib/timelib.lo ext/date/lib/tm2unixtime.lo
ext/date/lib/unixtime2tm.lo regex/regcomp.lo regex/regexec.lo
regex/regerror.lo regex/regfree.lo ext/standard/array.lo
ext/standard/base64.lo ext/standard/basic_functions.lo
ext/standard/browscap.lo ext/standard/crc32.lo ext/standard/crypt.lo
ext/standard/cyr_convert.lo ext/standard/datetime.lo ext/standard/dir.lo
ext/standard/dl.lo ext/standard/dns.lo ext/standard/exec.lo
ext/standard/file.lo ext/standard/filestat.lo
ext/standard/flock_compat.lo ext/standard/formatted_print.lo
ext/standard/fsock.lo ext/standard/head.lo ext/standard/html.lo
ext/standard/image.lo ext/standard/info.lo ext/standard/iptc.lo
ext/standard/lcg.lo ext/standard/link.lo ext/standard/mail.lo
ext/standard/math.lo ext/standard/md5.lo ext/standard/metaphone.lo
ext/standard/microtime.lo ext/standard/pack.lo ext/standard/pageinfo.lo
ext/standard/quot_print.lo ext/standard/rand.lo ext/standard/reg.lo
ext/standard/soundex.lo ext/standard/string.lo ext/standard/scanf.lo
ext/standard/syslog.lo ext/standard/type.lo ext/standard/uniqid.lo
ext/standard/url.lo ext/standard/url_scanner.lo ext/standard/var.lo
ext/standard/versioning.lo ext/standard/assert.lo
ext/standard/strnatcmp.lo ext/standard/levenshtein.lo
ext/standard/incomplete_class.lo ext/standard/url_scanner_ex.lo
ext/standard/ftp_fopen_wrapper.lo ext/standard/http_fopen_wrapper.lo
ext/standard/php_fopen_wrapper.lo ext/standard/credits.lo
ext/standard/css.lo ext/standard/var_unserializer.lo
ext/standard/ftok.lo ext/standard/sha1.lo ext/standard/user_filters.lo
ext/standard/uuencode.lo ext/standard/filters.lo
ext/standard/proc_open.lo ext/standard/streamsfuncs.lo
ext/standard/http.lo TSRM/TSRM.lo TSRM/tsrm_strtok_r.lo
TSRM/tsrm_virtual_cwd.lo main/main.lo main/snprintf.lo main/spprintf.lo
main/php_sprintf.lo main/safe_mode.lo main/fopen_wrappers.lo
main/alloca.lo main/php_scandir.lo main/php_ini.lo main/SAPI.lo
main/rfc1868.lo main/php_content_types.lo main/strlcpy.lo
main/strlcat.lo main/mergesort.lo main/reentrancy.lo
main/php_variables.lo main/php_ticks.lo main/network.lo
main/php_open_temporary_file.lo main/php_logos.lo main/output.lo
main/streams/streams.lo main/streams/cast.lo main/streams/memory.lo
main/streams/filter.lo main/streams/plain_wrapper.lo
main/streams/userspace.lo main/streams/transports.lo
main/streams/xp_socket.lo main/streams/mmap.lo
Zend/zend_language_parser.lo Zend/zend_language_scanner.lo
Zend/zend_ini_parser.lo Zend/zend_ini_scanner.lo Zend/zend_alloc.lo
Zend/zend_compile.lo Zend/zend_constants.lo Zend/zend_dynamic_array.lo
Zend/zend_execute_API.lo Zend/zend_highlight.lo Zend/zend_llist.lo
Zend/zend_opcode.lo Zend/zend_operators.lo Zend/zend_ptr_stack.lo
Zend/zend_stack.lo Zend/zend_variables.lo Zend/zend.lo Zend/zend_API.lo
Zend/zend_extensions.lo Zend/zend_hash.lo Zend/zend_list.lo
Zend/zend_indent.lo Zend/zend_builtin_functio

#46890 [Opn->Bgs]: Regex works in perl, not with preg_match

2008-12-18 Thread nlopess

 ID:   46890
 Updated by:   nlop...@php.net
 Reported By:  gohanman at gmail dot com
-Status:   Open
+Status:   Bogus
 Bug Type: PCRE related
 Operating System: CentOS
 PHP Version:  5.2.8
 New Comment:

it works here.
try to do a var_dump($groups); and watch it closely. (btw you shouldn't
do 'echo var_dump'..)


Previous Comments:


[2008-12-18 08:50:07] php at degoulet dot net

[r...@pix root]# cat a.php 


[r...@pix root]# php -v
PHP 5.2.8 (cli) (built: Dec 17 2008 16:18:21) 
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies

[r...@pix root]# php a.php 
int(1)



[2008-12-17 20:51:06] gohanman at gmail dot com

Description:

I'm having a preg_match function fail periodically. I finally found a
specific input string that fails in PHP but works fine in Perl. I'm at a
loss why.

Reproduce code:
---
$pattern = "/(\w\w\w) (\d+) (\d\d\d\d) (\d+):(\d\d)(\w)M/";
$input = "Dec 17 2008 2:23PM";
$rv = preg_match($pattern, $input, $groups);
echo var_dump($rv);

Expected result:

A non-zero result indicating the pattern matched.

Actual result:
--
Zero.





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

#46817 [Opn->Ver]: tokenizer misses last single-line comment

2008-12-10 Thread nlopess

#46779 [Bgs]: Compilation failed in preg_replace for Unicode character properties

2008-12-10 Thread nlopess

 ID:   46779
 Updated by:   [EMAIL PROTECTED]
 Reported By:  dytrych at webovy-servis dot cz
 Status:   Bogus
 Bug Type: PCRE related
 Operating System: Debian GNU/Linux 2.6.23.17
 PHP Version:  5.2.7
 New Comment:

btw, this might be related with http://bugs.php.net/46800


Previous Comments:


[2008-12-08 22:04:32] [EMAIL PROTECTED]

I can't reproduce this problem.
My guess is that you are linking against your system's PCRE library
(which can be confirmed by checking if pcre appears in output of "ldd
`which php`") instead of using the bundled version. If that is the case,
then your library was compiled without unicode support.



[2008-12-06 11:24:51] dytrych at webovy-servis dot cz

Description:

Unicode character properties doesn't work in preg_replace (since PHP
5.2.7).

PCRE (Perl Compatible Regular Expressions) Support  enabled
PCRE Library Version: 7.8 2008-09-05 


Results with phpinfo: http://seo-servis.cz/testpl.php

Reproduce code:
---
echo preg_replace("~[^\\pL]+~u", '-', "a 3");

echo preg_replace('~[^\\p{L}]+~u', '-', "a 3");

Expected result:

a-3
a-3

Actual result:
--
Warning: preg_replace() [function.preg-replace]: Compilation failed:
unknown property name after \P or \p at offset 4 in xxx on line 3

Warning: preg_replace() [function.preg-replace]: Compilation failed:
unknown property name after \P or \p at offset 6 in xxx on line 4





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

#46800 [Asn->Csd]: Warning on ~[^\\pL0-9_]+~u

2008-12-10 Thread nlopess

 ID:   46800
 Updated by:   [EMAIL PROTECTED]
 Reported By:  svoboda at svoon dot net
-Status:   Assigned
+Status:   Closed
 Bug Type: PCRE related
 Operating System: debian etch
 PHP Version:  5.2.7
 Assigned To:  nlopess
 New Comment:

PHP 5.3 & 6 already had the fix for a long time. so I'm closing this
bug report.


Previous Comments:


[2008-12-10 07:49:43] [EMAIL PROTECTED]

http://cvs.php.net/viewvc.cgi/php-src/main/php_compat.h?r1=1.25.2.3.2.5&r2=1.25.2.3.2.6&view=patch

Nuno: What about the rest of the branches?



[2008-12-10 07:06:51] svoboda at svoon dot net

hi,
now it works fine.
could you please send me the fix? I will not use devel version - rather
to patch the 5.2.8 stable version.

thank you 
ondrej



[2008-12-09 22:03:11] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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

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

I've commited a fix. can you please check if it works for you?
(please wait ~1h30 counting from this msg to allow a new snapshot to be
generated)



[2008-12-09 20:02:03] svoboda at svoon dot net

could be it connected?
http://bugs.gentoo.org/238127



[2008-12-09 19:48:36] svoboda at svoon dot net

hi,
I have compiled it with following:
./configure --disable-all --disable-cgi --with-pcre-regex 
--with-apxs2=/usr/bin/apxs2
--with-config-file-path=/etc/php5/apache2/php.ini

the problem still remains, but from command line it regexp works fine
(from command line it worked even with full configure command).
So the problem is connected with running through apache.

I confirmed this bug on ubuntu hardy.

ondrej



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

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

#46800 [Opn->Fbk]: Warning on ~[^\\pL0-9_]+~u

2008-12-09 Thread nlopess

 ID:   46800
 Updated by:   [EMAIL PROTECTED]
 Reported By:  svoboda at svoon dot net
-Status:   Open
+Status:   Feedback
 Bug Type: PCRE related
 Operating System: debian etch
 PHP Version:  5.2.7
 New Comment:

Please try using this CVS snapshot:

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

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

I've commited a fix. can you please check if it works for you?
(please wait ~1h30 counting from this msg to allow a new snapshot to be
generated)


Previous Comments:


[2008-12-09 20:02:03] svoboda at svoon dot net

could be it connected?
http://bugs.gentoo.org/238127



[2008-12-09 19:48:36] svoboda at svoon dot net

hi,
I have compiled it with following:
./configure --disable-all --disable-cgi --with-pcre-regex 
--with-apxs2=/usr/bin/apxs2
--with-config-file-path=/etc/php5/apache2/php.ini

the problem still remains, but from command line it regexp works fine
(from command line it worked even with full configure command).
So the problem is connected with running through apache.

I confirmed this bug on ubuntu hardy.

ondrej



[2008-12-08 22:31:07] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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

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

And use this configure line:

# ./configure --disable-all --disable-cgi --with-pcre-regex 



[2008-12-08 19:04:21] svoboda at svoon dot net

Description:

this code:
preg_replace('~[^\\pL0-9_]+~u', '-', $url);

results in:
Warning: preg_replace() [function.preg-replace]: Compilation failed: 
unknown property name after \P or \p at offset 4 in functions.inc.php

in 5.2.6 version it works fine

ondrej






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

#46779 [Opn->Bgs]: Compilation failed in preg_replace for Unicode character properties

2008-12-08 Thread nlopess

 ID:   46779
 Updated by:   [EMAIL PROTECTED]
 Reported By:  dytrych at webovy-servis dot cz
-Status:   Open
+Status:   Bogus
 Bug Type: PCRE related
 Operating System: Debian GNU/Linux 2.6.23.17
 PHP Version:  5.2.7
 New Comment:

I can't reproduce this problem.
My guess is that you are linking against your system's PCRE library
(which can be confirmed by checking if pcre appears in output of "ldd
`which php`") instead of using the bundled version. If that is the case,
then your library was compiled without unicode support.


Previous Comments:


[2008-12-06 11:24:51] dytrych at webovy-servis dot cz

Description:

Unicode character properties doesn't work in preg_replace (since PHP
5.2.7).

PCRE (Perl Compatible Regular Expressions) Support  enabled
PCRE Library Version: 7.8 2008-09-05 


Results with phpinfo: http://seo-servis.cz/testpl.php

Reproduce code:
---
echo preg_replace("~[^\\pL]+~u", '-', "a 3");

echo preg_replace('~[^\\p{L}]+~u', '-', "a 3");

Expected result:

a-3
a-3

Actual result:
--
Warning: preg_replace() [function.preg-replace]: Compilation failed:
unknown property name after \P or \p at offset 4 in xxx on line 3

Warning: preg_replace() [function.preg-replace]: Compilation failed:
unknown property name after \P or \p at offset 6 in xxx on line 4





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

#46040 [Csd]: [PATCH] pcre_internal.h parse error during compilation

2008-09-29 Thread nlopess

 ID:   46040
 Updated by:   [EMAIL PROTECTED]
 Reported By:  Bjorn dot Wiberg at its dot uu dot se
 Status:   Closed
 Bug Type: Compile Failure
 Operating System: IBM AIX 5.3 5300-08-01-0819
 PHP Version:  5.3CVS-2008-09-10 (snap)
 New Comment:

we will fix it when upstream developers fix it. In general we do not
patch bundled libraries for non-critical issues (i.e. security bugs).


Previous Comments:


[2008-09-29 06:06:28] Bjorn dot Wiberg at its dot uu dot se

Hi again!

It seems that my patch has not (yet?) been included with
php5.3-200809290430. Will it be, or are you expecting the PCRE
developers to release a fix and include that with PHP 5.3 instead?
Should this bug really be closed until this has been resolved?

Thanks in advance!

Best regards,
Björn



[2008-09-28 20:48:08] [EMAIL PROTECTED]

forwarded upstream: http://bugs.exim.org/show_bug.cgi?id=761



[2008-09-16 11:29:20] Bjorn dot Wiberg at its dot uu dot se

Will you report this upstream?
And apply the fix in the meantime?

Many thanks in advance!

Best regards,
BjÃ¶rn



[2008-09-11 12:27:33] [EMAIL PROTECTED]

This really needs to go upstream to
http://bugs.exim.org/enter_bug.cgi?product=PCRE

We can fix it as well though.



[2008-09-11 11:39:10] Bjorn dot Wiberg at its dot uu dot se

Attaching patch below which solves the problem.


*** php5.3-200809100630/ext/pcre/pcrelib/pcre_internal.h.ORIGINAL  
2008-09-11 13:19:06.0 +0200
--- php5.3-200809100630-my/ext/pcre/pcrelib/pcre_internal.h
2008-09-11 13:19:46.0 +0200
***
*** 562,570 
  /* Miscellaneous definitions. The #ifndef is to pacify compiler
warnings in
  environments where these macros are defined elsewhere. */
  
! #ifndef FALSE
  typedef int BOOL;
  
  #define FALSE   0
  #define TRUE1
  #endif
--- 562,572 
  /* Miscellaneous definitions. The #ifndef is to pacify compiler
warnings in
  environments where these macros are defined elsewhere. */
  
! #ifndef BOOL
  typedef int BOOL;
+ #endif
  
+ #ifndef FALSE
  #define FALSE   0
  #define TRUE1
  #endif



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

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

#46074 [Opn->Fbk]: Bus error during running PHP CLI under IRIX 6.5.30

2008-09-28 Thread nlopess

 ID:   46074
 Updated by:   [EMAIL PROTECTED]
 Reported By:  neko at nekochan dot net
-Status:   Open
+Status:   Feedback
 Bug Type: Reproducible crash
 Operating System: IRIX 6.5.30
 PHP Version:  5.3.0alpha2
 New Comment:

weird, bus errors on these platforms usually mean unaligned data..
can you please try the following commands in GDB and report back the
output?

p value
p *value
p variable_ptr_ptr
p *variable_ptr_ptr
p **variable_ptr_ptr


Previous Comments:


[2008-09-15 13:51:11] neko at nekochan dot net

No change with latest CVS.

[EMAIL PROTECTED] /opt/build/php5.3-200809151230
 # dbx ./sapi/cli/php core 
dbx version 7.3.7 (96015_Nov16 MR) Nov 16 2004 07:34:16
Core from signal SIGBUS: Bus error
(dbx) where

Thread 0x1
>  0 zend_assign_to_variable(0x14a0, 0x1080a55c, 0x0, 0xc, 0x21000, 
0x1000, 0xc, 0x106c6e28) ["/opt/build/php5.3-
200809151230/Zend/zend_execute.c":739, 0x103a118c]
   1 ZEND_ASSIGN_SPEC_CV_TMP_HANDLER(0x1080a4e8, 0xd, 0x0, 0xc, 
0x21000, 0x1000, 0xc, 0x106c6e28) ["/opt/build/php5.3-
200809151230/Zend/zend_vm_execute.h":25843, 0x103f1d00]
   2 execute(0x106c6840, 0xd, 0x0, 0xc, 0x21000, 0x1000, 0xc, 
0x106c6e28) ["/opt/build/php5.3-
200809151230/Zend/zend_vm_execute.h":104, 0x103a29d8]
   3 zend_execute_scripts(0x8, 0xd, 0x3, 0x0, 0x21000, 0x1000, 0xc, 
0x106c6e28) ["/opt/build/php5.3-200809151230/Zend/zend.c":1197, 
0x10377038]
   4 php_execute_script(0x14a0, 0xd, 0x0, 0xc, 0x21000, 0x1000, 0xc, 
0x106c6e28) ["/opt/build/php5.3-200809151230/main/main.c":2075, 
0x10315798]
   5 main(0xf, 0x7fff2ee4, 0x0, 0xc, 0x21000, 0x1000, 0xc, 0x106c6e28)

["/opt/build/php5.3-200809151230/sapi/cli/php_cli.c":1130, 0x104012e0]
   6 __start() ["/xlv55/kudzu-
apr12/work/irix/lib/libc/libc_n32_M4/csu/crt1text.s":177, 0x1004cb68]
(dbx) quit



[2008-09-15 08:00:24] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php5.3-latest.tar.gz
 
For Windows (zip):
 
  http://snaps.php.net/win32/php5.3-win32-latest.zip

For Windows (installer):

  http://snaps.php.net/win32/php5.3-win32-installer-latest.msi





[2008-09-14 07:15:54] neko at nekochan dot net

Description:

Bus error during 'Generatring phar.php' phase of build; also occurs if

using '--disable-phar' immediately after running 'gmake test'. Bus 
error occurs with both MIPSpro 7.4.4m and GCC-4.3.1 compilers under 
IRIX 6.5.30. Also tested with php5.3-200809140030 with same result.

./configure options:

'./configure' '--prefix=/usr/nekoware/php5' 
'--enable-dba' 
'--enable-calendar'
'--enable-wddx' 
'--with-config-file-path=/usr/nekoware/etc/php5' 
'--with-apxs2=/usr/nekoware/apache2/bin/apxs' 
'--enable-cli' '--with-libxml-dir=/usr/nekoware'
'--with-png-dir=/usr/nekoware' 
'--with-jpeg-dir=/usr/nekoware'
'--with-freetype-dir=/usr/nekoware' 
'--with-zlib-dir=/usr/nekoware' 
'--with-zlib'
'--with-curlwrappers' 
'--with-curl=shared,/usr/nekoware' 
'--with-openssl=shared,/usr/nekoware' 
'--with-mysql=shared,mysqlnd' 
'--with-mysqli=shared,mysqlnd' 
'--with-mhash=shared,/usr/nekoware' 
'--with-mcrypt=shared,/usr/nekoware'
'--with-bz2=shared,/usr/nekoware'
'--enable-ftp=shared' 
'--enable-sockets=shared' 
'--with-gd=shared' 
'--enable-exif=shared'
'--with-xmlrpc' 
'--with-gettext=shared,/usr/nekoware' 
'--with-iconv-dir=/usr/nekoware' 
'--enable-mbstring=shared' 
'--enable-sysvsem=shared'
'--enable-sysvshm=shared' 
'--enable-sysvmsg=shared' 
'--with-xpm-dir=/usr/lib32'
'--enable-zip=shared' 
'--with-pgsql=shared,/usr/nekoware/pgsql' 
'--with-mm=/usr/nekoware



Reproduce code:
---
gmake

or with '--disable-phar':

gmake test

Expected result:

Completed build and ability to run php test process.

Actual result:
--
...
Generating phar.php
gmake: *** [ext/phar/phar.php] Bus error (core dumped)
gmake: *** Deleting file `ext/phar/phar.php'

# dbx ./sapi/cli/php core
dbx version 7.3.7 (96015_Nov16 MR) Nov 16 2004 07:34:16
Core from signal SIGBUS: Bus error
(dbx) where

Thread 0x1
>  0 zend_assign_to_variable(0x14a0, 0x107fde5c, 0x0, 0xc, 0x21000, 
0x1000, 0xc, 0x106bab80) ["/opt/build/php-
5.3.0alpha2/Zend/zend_execute.c":739, 0x1039ebcc]
   1 ZEND_ASSIGN_SPEC_CV_TMP_HANDLER(0x107fdde8, 0xd, 0x0, 0xc, 
0x21000, 0x1000, 0xc, 0x106bab80) ["/opt/build/php-
5.3.0alpha2/Zend/zend_vm_execute.h":25843, 0x103ef740]
   2 execute(0x106ba598, 0xd, 0x0, 0xc, 0x21000, 0x1000, 0xc, 
0x106bab80) ["/opt/build/php-5.3.0alpha2/Zend/zend_vm_execute.h":104, 
0x103a0418]
   3 zend_execute_scripts(0x8, 0xd, 0x3, 0x0, 0x21000, 0x1000, 0xc, 
0x106bab80) ["/opt/build/php-5.3.0alpha2/Zend/zend.c":1197, 
0x10374a58]
   4 php_execute_script(0x14a0, 0xd, 0x0, 0xc, 0x21000, 0x1000, 0xc, 
0x106bab80) ["/opt/build/php-5.3.0alpha2/main/main.

#45522 [Opn->Asn]: FCGI_GET_VALUES request does not return supplied values

2008-09-28 Thread nlopess

 ID:   45522
 Updated by:   [EMAIL PROTECTED]
 Reported By:  arnaud dot lb at gmail dot com
-Status:   Open
+Status:   Assigned
 Bug Type: CGI related
 Operating System: *
 PHP Version:  5.3CVS-2008-07-15 (CVS)
-Assigned To:  
+Assigned To:  dmitry


Previous Comments:


[2008-07-15 16:02:09] arnaud dot lb at gmail dot com

Description:

FastCGI specifies that a FastCGI application may return the values
supplied by a FCGI_GET_VALUES request.

Actually the FastCGI SAPI returns all standard values (FCGI_MAX_CONNS,
FCGI_MAX_REQS, FCGI_MPXS_CONNS), *except* those supplied.

Also, it seems that the returns values does not reflect the actual
configuration (e.g. FCGI_MAX_CONNS and FCGI_MAX_REQS are always 1).

Reproduce code:
---
Requesting the FCGI_MAX_CONN value using a FCGI_GET_VALUES record in
the FastCGI protocol.


Expected result:

Requesting the FCGI_MAX_CONN returns FCGI_MAX_CONN value.

Actual result:
--
Requesting the FCGI_MAX_CONN returns FCGI_MAX_REQS and FCGI_MPXS_CONNS
values but not FCGI_MAX_CONN.





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

#46040 [Opn->Csd]: [PATCH] pcre_internal.h parse error during compilation

2008-09-28 Thread nlopess

 ID:   46040
 Updated by:   [EMAIL PROTECTED]
 Reported By:  Bjorn dot Wiberg at its dot uu dot se
-Status:   Open
+Status:   Closed
 Bug Type: Compile Failure
 Operating System: IBM AIX 5.3 5300-08-01-0819
 PHP Version:  5.3CVS-2008-09-10 (snap)
 New Comment:

forwarded upstream: http://bugs.exim.org/show_bug.cgi?id=761


Previous Comments:


[2008-09-16 11:29:20] Bjorn dot Wiberg at its dot uu dot se

Will you report this upstream?
And apply the fix in the meantime?

Many thanks in advance!

Best regards,
BjÃ¶rn



[2008-09-11 12:27:33] [EMAIL PROTECTED]

This really needs to go upstream to
http://bugs.exim.org/enter_bug.cgi?product=PCRE

We can fix it as well though.



[2008-09-11 11:39:10] Bjorn dot Wiberg at its dot uu dot se

Attaching patch below which solves the problem.


*** php5.3-200809100630/ext/pcre/pcrelib/pcre_internal.h.ORIGINAL  
2008-09-11 13:19:06.0 +0200
--- php5.3-200809100630-my/ext/pcre/pcrelib/pcre_internal.h
2008-09-11 13:19:46.0 +0200
***
*** 562,570 
  /* Miscellaneous definitions. The #ifndef is to pacify compiler
warnings in
  environments where these macros are defined elsewhere. */
  
! #ifndef FALSE
  typedef int BOOL;
  
  #define FALSE   0
  #define TRUE1
  #endif
--- 562,572 
  /* Miscellaneous definitions. The #ifndef is to pacify compiler
warnings in
  environments where these macros are defined elsewhere. */
  
! #ifndef BOOL
  typedef int BOOL;
+ #endif
  
+ #ifndef FALSE
  #define FALSE   0
  #define TRUE1
  #endif



[2008-09-10 20:13:58] [EMAIL PROTECTED]

"Perhaps" ?? Why don't you TRY it? And if it works -> send us a 
patch.



[2008-09-10 07:49:46] Bjorn dot Wiberg at its dot uu dot se

Description:

using gcc on AIX. Compilation failure due to BOOL not being defined?

Probably due to the ifndef check at
ext/pcre/pcrelib/pcre_internal.h:565:

#ifndef FALSE
typedef int BOOL;

#define FALSE   0
#define TRUE1
#endif

I supposed FALSE is already defined (but apparently not BOOL), and
hence compilation fails.

Perhaps two checks instead would fix this? Something like:

#ifndef BOOL
typedef int BOOL;
#endif

#ifndef FALSE
#define FALSE   0
#define TRUE1
#endif

Best regards,
Björn

Reproduce code:
---
#! /bin/sh
#
# Created by configure

LDFLAGS='-Wl,-bbigtoc' \
CC='gcc' \
'./configure' \
'--enable-bcmath' \
'--enable-calendar' \
'--enable-cli' \
'--enable-dba' \
'--enable-dbase' \
'--enable-debug' \
'--enable-exif' \
'--enable-flatfile' \
'--enable-ftp' \
'--enable-gd-jis-conv' \
'--enable-gd-native-ttf' \
'--enable-inifile' \
'--enable-mbstring' \
'--enable-pcntl' \
'--enable-shmop' \
'--enable-soap' \
'--enable-sockets' \
'--enable-sqlite-utf8' \
'--enable-sysvmsg' \
'--enable-sysvsem' \
'--enable-sysvshm' \
'--enable-wddx' \
'--enable-zip' \
'--enable-zend-multibyte' \
'--prefix=/apache/php' \
'--with-apxs2=/apache/bin/apxs' \
'--with-bz2' \
'--with-cdb' \
'--with-curl' \
'--with-freetype-dir' \
'--with-gd' \
'--with-gdbm' \
'--with-gettext' \
'--with-jpeg-dir' \
'--with-ldap' \
'--with-libxml-dir=/usr/local' \
'--with-mime-magic' \
'--with-mysql=mysqlnd' \
'--with-mysqli=mysqlnd' \
'--with-openssl=/opt/freeware' \
'--with-pdo-mysql=mysqlnd' \
'--with-png-dir' \
'--with-xmlrpc' \
'--with-xpm-dir' \
'--with-xsl' \
'--with-zlib' \
'--with-zlib-dir' \
"$@"

Expected result:

No compile failure.

Actual result:
--
 gcc -I/home/bwiberg/rpm/BUILD/php5.3-200809100630/ext/pcre/pcrelib
-Iext/pcre/ -I/home/bwiberg/rpm/BUILD/php5.3-200809100630/ext/pcre/
-DPHP_ATOM_INC -I/home/bwiberg/rpm/BUILD/php5.3-200809100630/include
-I/home/bwiberg/rpm/BUILD/php5.3-200809100630/main
-I/home/bwiberg/rpm/BUILD/php5.3-200809100630
-I/home/bwiberg/rpm/BUILD/php5.3-200809100630/ext/ereg/regex
-I/usr/local/include/libxml2 -I/opt/freeware/include
-I/usr/local/include
-I/home/bwiberg/rpm/BUILD/php5.3-200809100630/ext/date/lib
-I/usr/X11R6/include -I/usr/include/freetype2
-I/home/bwiberg/rpm/BUILD/php5.3-200809100630/ext/mbstring/oniguruma
-I/home/bwiberg/rpm/BUILD/php5.3-200809100630/ext/mbstring/libmbfl
-I/home/bwiberg/rpm/BUILD/php5.3-200809100630/ext/mbstring/libmbfl/mbfl
-I/home/bwiberg/rpm/BUILD/php5.3-200809100630/ext/sqlite3/libsqlite
-I/home/bwiberg/rpm/BUILD/php5.3-200809100630/TSRM
-I/home/bwiberg/rpm/BUILD/php5.3-200809100630/Zend -I/usr/include -g
-fvisibility=hidden -O0 -Wall -c
/home/bwiberg/rpm/BUILD/php5.3-200809100630/ext/pcre/pcrelib/pcre_chartables.c
 -DPIC -o ext/pcre/pcrelib/.libs/pcre_chartables.o
In file included from
/home/bwiberg/rpm/BUILD/php5.3-2008091006

#46184 [Opn->Bgs]: a problem with internal vars

2008-09-28 Thread nlopess

 ID:   46184
 Updated by:   [EMAIL PROTECTED]
 Reported By:  vasilkov80 at mail dot ru
-Status:   Open
+Status:   Bogus
 Bug Type: PCRE related
 Operating System: linux mandriva 2007
 PHP Version:  5.2.6
 New Comment:

your regex is wrong.

quote from the PCRE manual:
"Outside a character class, a backslash followed by a digit greater
than 0 (and possibly further digits) is a back reference to a capturing
sub-pattern  earlier  (that is, to its left) in the pattern, provided
there have been that many previous capturing left parentheses."



Previous Comments:


[2008-09-26 15:44:59] vasilkov80 at mail dot ru

sorry, expected result:

Array
(
[0] => "image.jpg"
[1] => "
[2] => image.jpg
)



[2008-09-26 15:38:24] vasilkov80 at mail dot ru

Description:

a problem with internal vars?

/\"([^\"]+\.jpg)\"/ - the pattern works fine...
/([\"\'])([^\\1]+\.jpg)\\1/ - a bit more complex pattern doesn't work
as expected!

Reproduce code:
---
if( preg_match("%([\"\']{1})([^\\1]+\.jpg)\\1%", '.. "bla bla
"image.jpg" .. " bla bla', $matches) )
print_r($matches);

Expected result:

Array
(
[0] => "image.jpg"
[1] => image.jpg
)

Actual result:
--
Array
(
[0] => "bla bla "image.jpg"
[1] => "
[2] => bla bla "image.jpg
)





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

#45546 [NoF]: PCRE with utf8 kill apache childprocess

2008-09-26 Thread nlopess

 ID:   45546
 Updated by:   [EMAIL PROTECTED]
 Reported By:  kaiser at macbureau dot de
 Status:   No Feedback
 Bug Type: PCRE related
 Operating System: FreeBSD 7
 PHP Version:  5.2.6
 New Comment:

again I cannot reproduce this problem. Try to adjust
pcre.backtrack_limit and pcre.recursion_limit to some sane values.


Previous Comments:


[2008-09-26 09:17:06] ale at FreeBSD dot org

The feedback was provided.

In any case the above script works if the string length is <= 2243 and
stops working if > 2243 'a' chars.



[2008-07-27 01:00:01] php-bugs at lists dot php dot net

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



[2008-07-25 13:45:15] hempalex at gmail dot com

I reproduced this on FreeBSD 7.0 + Apache/2.2.9 + PHP/5.2.6 (bundled
prce)


script:


mod_php: 
   in apache logs: [notice] child pid 54586 exit signal Illegal
instruction (4)

in cli works fine!



[2008-07-22 23:08:28] nikolas dot hagelstein at gmail dot com

Confirmed. 

System:
FreeBSD 7
PHP 5.2.6 (PCRE Library Version => 7.6 2008-01-28)
stack size  (kbytes, -s) 524288

Backtrace:

#6216 0x00080407a494 in match () from
/usr/local/lib/php/20060613/pcre.so
#
#6217 0x00080407701c in match () from
/usr/local/lib/php/20060613/pcre.so
#
#6218 0x00080407a494 in match () from
/usr/local/lib/php/20060613/pcre.so
#
#6219 0x00080407701c in match () from
/usr/local/lib/php/20060613/pcre.so
#
#6220 0x000804076d05 in match () from
/usr/local/lib/php/20060613/pcre.so
#
#6221 0x00080407f12f in php_pcre_exec ()
#
   from /usr/local/lib/php/20060613/pcre.so
#
 
#
#6222 0x000804084c02 in php_pcre_match_impl ()
#
   from /usr/local/lib/php/20060613/pcre.so
#
#6223 0x00080408569b in php_do_pcre_match ()
#
   from /usr/local/lib/php/20060613/pcre.so
#
#6224 0x00538912 in zend_do_fcall_common_helper_SPEC ()
#
#6225 0x00528603 in execute ()
#
#6226 0x005383a4 in zend_do_fcall_common_helper_SPEC ()
#
#6227 0x00528603 in execute ()
#
#6228 0x00508dd3 in zend_execute_scripts ()
#
#6229 0x004c5a5d in php_execute_script ()



[2008-07-19 12:19:46] [EMAIL PROTECTED]

I can reproduce. (PHP 5.2.7-dev)

==6244== Stack overflow in thread 1: can't grow stack to 0xBE04DFC0
==6244== 
==6244== Process terminating with default action of signal 11
(SIGSEGV)
==6244==  Access not within mapped region at address 0xBE04DFC0
==6244==at 0x8099F78: match (pcre_exec.c:1287)
==6244== Stack overflow in thread 1: can't grow stack to 0xBE04DF9C
==6244== 
==6244== Process terminating with default action of signal 11
(SIGSEGV)
==6244==  Access not within mapped region at address 0xBE04DF9C
==6244==at 0x401D200: _vgnU_freeres (vg_preloaded.c:56)




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

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

#46174 [Fbk->Bgs]: _pcre_utt_names is overridden from libpcre.so and results in \p match failure

2008-09-26 Thread nlopess

 ID:   46174
 Updated by:   [EMAIL PROTECTED]
 Reported By:  pageexec at freemail dot hu
-Status:   Feedback
+Status:   Bogus
 Bug Type: PCRE related
 Operating System: linux
 PHP Version:  5.2.6
 New Comment:

as the problem is already fixed in CVS, there's nothing left to do :)
PHP 5.3 will be released soon (we hope)


Previous Comments:


[2008-09-26 08:00:51] pageexec at freemail dot hu

yes, it's fixed in the snapshots indeed, now the only remaining issue
is that the 5.3 release isn't out yet ;).



[2008-09-25 17:20:35] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php5.3-latest.tar.gz
 
For Windows (zip):
 
  http://snaps.php.net/win32/php5.3-win32-latest.zip

For Windows (installer):

  http://snaps.php.net/win32/php5.3-win32-installer-latest.msi

I believe this is fixed in latest cvs.



[2008-09-25 16:18:02] pageexec at freemail dot hu

i guess the simple fix is to add

#define _pcre_utt_names php__pcre_utt_names

to main/php_compat.h.



[2008-09-25 16:13:04] pageexec at freemail dot hu

Description:

the pcre extension contains a copy of some specific version of libpcre,
with most of the names prefixed with php_ except for _pcre_utt_names
which is not prefixed. this means that if a libphp user such as apache2
also happens to load libpcre (mine's directly linked against it so it
loads before libphp), the symbols from the latter may override
_pcre_utt_names and libphp will use the wrong names table when analyzing
\p and \P (the indices would come from php__pcre_utt which is specific
for the _pcre_utt_names table contained in the pcre extension).

Reproduce code:
---
preg_match_all("/\pL/u", "php", $matches);
print_r($matches);

Expected result:

Array
(
[0] => Array
(
[0] => p
[1] => h
[2] => p
)

)


Actual result:
--
Warning: preg_match_all() [function.preg-match-all]: Compilation
failed: unknown property name after \P or \p at offset 3 in 
on line 





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

#46174 [Opn->Fbk]: _pcre_utt_names is overridden from libpcre.so and results in \p match failure

2008-09-25 Thread nlopess

 ID:   46174
 Updated by:   [EMAIL PROTECTED]
 Reported By:  pageexec at freemail dot hu
-Status:   Open
+Status:   Feedback
 Bug Type: PCRE related
 Operating System: linux
 PHP Version:  5.2.6
 New Comment:

Please try using this CVS snapshot:

  http://snaps.php.net/php5.3-latest.tar.gz
 
For Windows (zip):
 
  http://snaps.php.net/win32/php5.3-win32-latest.zip

For Windows (installer):

  http://snaps.php.net/win32/php5.3-win32-installer-latest.msi

I believe this is fixed in latest cvs.


Previous Comments:


[2008-09-25 16:18:02] pageexec at freemail dot hu

i guess the simple fix is to add

#define _pcre_utt_names php__pcre_utt_names

to main/php_compat.h.



[2008-09-25 16:13:04] pageexec at freemail dot hu

Description:

the pcre extension contains a copy of some specific version of libpcre,
with most of the names prefixed with php_ except for _pcre_utt_names
which is not prefixed. this means that if a libphp user such as apache2
also happens to load libpcre (mine's directly linked against it so it
loads before libphp), the symbols from the latter may override
_pcre_utt_names and libphp will use the wrong names table when analyzing
\p and \P (the indices would come from php__pcre_utt which is specific
for the _pcre_utt_names table contained in the pcre extension).

Reproduce code:
---
preg_match_all("/\pL/u", "php", $matches);
print_r($matches);

Expected result:

Array
(
[0] => Array
(
[0] => p
[1] => h
[2] => p
)

)


Actual result:
--
Warning: preg_match_all() [function.preg-match-all]: Compilation
failed: unknown property name after \P or \p at offset 3 in 
on line 





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

#45828 [Opn->Bgs]: preg_match_all result not correct

2008-08-15 Thread nlopess

 ID:   45828
 Updated by:   [EMAIL PROTECTED]
 Reported By:  chenjii at gmail dot com
-Status:   Open
+Status:   Bogus
 Bug Type: PCRE related
 Operating System: windows xp SP2
 PHP Version:  5.2.6
 New Comment:

Well if it was an OS update that broke PHP, we can't do much about
it..
I tested in Windows Vista SP1 and Windows XP SP3 and your test case
works, so there's something wrong on your end. (but don't ask me what..
:) I would advise you to reinstall PHP and then reboot the pc.


Previous Comments:


[2008-08-15 07:25:44] chenjii at gmail dot com

Oh , Date is 2008-08-15 not 2008-05-15



[2008-08-15 03:47:14] chenjii at gmail dot com

Description:

preg_match_all's result is correct before windows update !

But yesterday (2008-05-15) I update my windows xp by windows's Auto
Update , preg_match_all's result became not correct!


my OS: windows XP SP2 (Traditional Chinese)
php: 5.2.6 in windows

PCRE Library Version7.6 2008-01-28 

Reproduce code:
---
$array_matches = array();

$sql = 'SELECT b.* , u.account , u.name , u2.account as account2 ,
u2.name as name2 FROM bbss as b LEFT JOIN users as u on (u.uid =
b.post_uid) LEFT JOIN users as u2 on (u2.uid = b.modified_uid) WHERE
deleted = 0 AND view_start_time <= NOW() ORDER BY bid DESC LIMIT 0 ,
20';

$match_count = preg_match_all('/^(SELECT.*?)LIMIT/im', $sql,
$array_matches);


Expected result:

$match_count > 0;

$array_matches == 
Array(
  [0] => Array ( 'SELECT b.* , u.account , u.name , u2.account as
account2 , u2.name as name2 FROM bbss as b LEFT JOIN users as u on
(u.uid = b.post_uid) LEFT JOIN users as u2 on (u2.uid = b.modified_uid)
WHERE deleted = 0 AND view_start_time <= NOW() ORDER BY bid DESC LIMIT 0
, 20' ) 
  [1] => Array ( 'SELECT b.* , u.account , u.name , u2.account as
account2 , u2.name as name2 FROM bbss as b LEFT JOIN users as u on
(u.uid = b.post_uid) LEFT JOIN users as u2 on (u2.uid = b.modified_uid)
WHERE deleted = 0 AND view_start_time <= NOW() ORDER BY bid DESC ' )
)

Actual result:
--
$match_count == 0

$array_matches == Array ( [0] => Array ( ) [1] => Array ( ) )





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

#44923 [Opn]: ereg functions are not unicode aware: provide wrapper functions in PCRE

2008-08-14 Thread nlopess

 ID:   44923
 Updated by:   [EMAIL PROTECTED]
 Reported By:  tokul at users dot sourceforge dot net
 Status:   Open
-Bug Type: PCRE related
+Bug Type: Regexps related
 Operating System: Linux Debian Etch
 PHP Version:  6CVS-2008-05-06 (snap)
 New Comment:

PCRE and ereg_* have different syntaxes. So wrapping ereg to pcre will
break most regexes.


Previous Comments:


[2008-08-12 16:38:01] [EMAIL PROTECTED]

For unicode aware regexps use PCRE. The old ereg stuff should be
provided as wrapper functions which uses PCRE underneath though.



[2008-05-06 12:06:03] [EMAIL PROTECTED]

This is expected, the code isn't prepared to works with unicode
strings.
Actually it only use REG_EXTENDED with binary strings, and convert the
unicode string to normal string.



[2008-05-06 03:59:56] tokul at users dot sourceforge dot net

Description:

expressions that work in older versions fail on PHP6
unicode.semantics=on

Compared 5.2-dev, 5.3-dev and 6.0-dev snapshots

Reproduce code:
---
$line = "* 469 EXISTS\r\n";
if (ereg("[^ ]+ +([^ ]+) +EXISTS", $line, $match)) {
var_dump($match[1]);
} else {
var_dump(false);
}

$line = "* 469 FETCH (UID 508 BODY[1]<0> {154}\r\n";
if (ereg('\\{([^\\}]*)\\}', $line, $match)) {
var_dump($match[1]);
} else {
var_dump(false);
}

Expected result:

string(3) "469"
string(3) "154"

Actual result:
--
bool(false)

Warning: ereg(): REG_BADRPT in
/home/tomas/testbeds/test/php60/bin/ereg.php on line 10
bool(false)





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

#44925 [Asn->Csd]: preg_grep and array index - follow up on #44191

2008-08-14 Thread nlopess

 ID:  44925
 Updated by:  [EMAIL PROTECTED]
 Reported By: admin at ifyouwantblood dot de
-Status:  Assigned
+Status:  Closed
 Bug Type:PCRE related
 PHP Version: 5.2.6
 Assigned To: nlopess
 New Comment:

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:


[2008-07-17 15:46:26] [EMAIL PROTECTED]

non, really. It's just that the code will become much bigger to do the
copying :)



[2008-07-13 16:18:18] [EMAIL PROTECTED]

Functions should never ever modify the input array unless designed to
do so. According to documentation, preg_grep() is not supposed to modify
the input array. So it's a bug, not BC. What exactly is the usage case
where it should modify input array?



[2008-07-06 18:46:13] [EMAIL PROTECTED]

I don't really know what to do with this..
While I agree it shouldn't modify the original array, changing the
behavior would break BC.. Any opinions about this?



[2008-05-06 16:00:03] admin at ifyouwantblood dot de

> PHP obviously should convert the values to string to be used in
> regex matching. Hence, i think that it should returns the string
> that was matched.

sure, internally it'll has to be converted, but i see no reason for a
change of the input array. thus preg_grep should work with a copy of the
input array...



[2008-05-06 13:07:09] [EMAIL PROTECTED]

Well, preg_grep() != in_array()...
PHP obviously should convert the values to string to be used in regex
matching. Hence, i think that it should returns the string that was
matched.

Anyway, i'll assign to the maintainer to solve this issue.

Thanks.



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

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

#39992 [Fbk->Opn]: proc_terminate() leaves children of child running

2008-08-12 Thread nlopess

 ID:   39992
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: Program Execution
 Operating System: linux
 PHP Version:  6CVS-2006-12-30 (CVS)
 New Comment:

Yes, I'm still able to reproduce it. In some systems you may need
higher proviledges in order to reproduce this bug.


Previous Comments:


[2008-08-12 16:28:58] [EMAIL PROTECTED]

Nuno, is this still valid bug? I can't reproduce it even with PHP
5.2.6..



[2006-12-30 15:54:27] [EMAIL PROTECTED]

Ah I forgot: removing the "2>&1" part everything works fine.



[2006-12-30 15:52:20] [EMAIL PROTECTED]

Description:

With the short reproduce code below, PHP fork()s a new process (sh),
that itself forks a new one (php). proc_terminate() kill()s the sh
process, but the php one doesn't get killed.
I'm not really sure what is causing this problem, but it is breaking
run-tests.php on timeout.

Reproduce code:
---
&1';
$proc = proc_open($cmd, array(), $pipes);
var_dump(proc_terminate($proc));

?>






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

#45546 [Opn->Fbk]: PCRE with utf8 kill apache childprocess

2008-07-19 Thread nlopess

 ID:   45546
 Updated by:   [EMAIL PROTECTED]
 Reported By:  kaiser at macbureau dot de
-Status:   Open
+Status:   Feedback
 Bug Type: PCRE related
 Operating System: FreeBSD 7
 PHP Version:  5.2.6
 New Comment:

Please try using this CVS snapshot:

  http://snaps.php.net/php5.3-latest.tar.gz
 
For Windows (zip):
 
  http://snaps.php.net/win32/php5.3-win32-latest.zip

For Windows (installer):

  http://snaps.php.net/win32/php5.3-win32-installer-latest.msi

I can't reproduce the crash here, nor valgrind finds any problem. Can
you please try the cvs version please?


Previous Comments:


[2008-07-17 19:29:53] kaiser at macbureau dot de

Sorry, c&p error, thanks, looking forward to hear from you.

./test.php
Segmentation fault (core dumped)




#!/usr/local/bin/php




[2008-07-17 17:53:51] [EMAIL PROTECTED]

the pasted code is incomplete (doesn't even run). Please provide a
complete, but short, reproducible script.



[2008-07-17 16:31:50] kaiser at macbureau dot de

Description:

PCRE with utf8 (Typo3 Mailform) kills apache childprocess. With the 
following entry in apache errorlog on FreeBSD 7 with Apache 2.2.8:

[notice] child pid 6709 exit signal Illegal instruction (4)


Output of ulimit -a:

core file size  (blocks, -c) unlimited
data seg size   (kbytes, -d) 33554432
file size   (blocks, -f) unlimited
max locked memory   (kbytes, -l) unlimited
max memory size (kbytes, -m) unlimited
open files  (-n) 11095
pipe size(512 bytes, -p) 1
stack size  (kbytes, -s) 524288
cpu time   (seconds, -t) unlimited
max user processes  (-u) 5547
virtual memory  (kbytes, -v) unlimite

Reproduce code:
---
#!/usr/local/bin/php







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

#45546 [Opn->Fbk]: PCRE with utf8 kill apache childprocess

2008-07-17 Thread nlopess

 ID:   45546
 Updated by:   [EMAIL PROTECTED]
 Reported By:  kaiser at macbureau dot de
-Status:   Open
+Status:   Feedback
-Bug Type: Apache2 related
+Bug Type: PCRE related
 Operating System: FreeBSD 7
 PHP Version:  5.2.6
 New Comment:

the pasted code is incomplete (doesn't even run). Please provide a
complete, but short, reproducible script.


Previous Comments:


[2008-07-17 16:31:50] kaiser at macbureau dot de

Description:

PCRE with utf8 (Typo3 Mailform) kills apache childprocess. With the 
following entry in apache errorlog on FreeBSD 7 with Apache 2.2.8:

[notice] child pid 6709 exit signal Illegal instruction (4)


Output of ulimit -a:

core file size  (blocks, -c) unlimited
data seg size   (kbytes, -d) 33554432
file size   (blocks, -f) unlimited
max locked memory   (kbytes, -l) unlimited
max memory size (kbytes, -m) unlimited
open files  (-n) 11095
pipe size(512 bytes, -p) 1
stack size  (kbytes, -s) 524288
cpu time   (seconds, -t) unlimited
max user processes  (-u) 5547
virtual memory  (kbytes, -v) unlimite

Reproduce code:
---
#!/usr/local/bin/php







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

#44925 [Asn]: preg_grep and array index - follow up on #44191

2008-07-17 Thread nlopess

 ID:  44925
 Updated by:  [EMAIL PROTECTED]
 Reported By: admin at ifyouwantblood dot de
 Status:  Assigned
 Bug Type:PCRE related
 PHP Version: 5.2.6
 Assigned To: nlopess
 New Comment:

non, really. It's just that the code will become much bigger to do the
copying :)


Previous Comments:


[2008-07-13 16:18:18] [EMAIL PROTECTED]

Functions should never ever modify the input array unless designed to
do so. According to documentation, preg_grep() is not supposed to modify
the input array. So it's a bug, not BC. What exactly is the usage case
where it should modify input array?



[2008-07-06 18:46:13] [EMAIL PROTECTED]

I don't really know what to do with this..
While I agree it shouldn't modify the original array, changing the
behavior would break BC.. Any opinions about this?



[2008-05-06 16:00:03] admin at ifyouwantblood dot de

> PHP obviously should convert the values to string to be used in
> regex matching. Hence, i think that it should returns the string
> that was matched.

sure, internally it'll has to be converted, but i see no reason for a
change of the input array. thus preg_grep should work with a copy of the
input array...



[2008-05-06 13:07:09] [EMAIL PROTECTED]

Well, preg_grep() != in_array()...
PHP obviously should convert the values to string to be used in regex
matching. Hence, i think that it should returns the string that was
matched.

Anyway, i'll assign to the maintainer to solve this issue.

Thanks.



[2008-05-06 12:48:29] admin at ifyouwantblood dot de

>> this is a follow up on bug #44191. that was fixed, but everything
>> inside the array is now converted to a string. as i understand it,
>> the search array shouldn't change at all, so i think this is a
>> bug. please note that with objects without a __toString() method, >>
this of course leads to a fatal error.
>
> This is expected, the function is for matching strings.

sorry, but did you even take a look at the samples? preg_grep is a
SEARCH function, why should it change the INPUT array?



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

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

#44299 [Asn->Csd]: PCRE security issue

2008-07-17 Thread nlopess

 ID:   44299
 Updated by:   [EMAIL PROTECTED]
 Reported By:  test_junk at hotmail dot it
-Status:   Assigned
+Status:   Closed
 Bug Type: PCRE related
 Operating System: *
 PHP Version:  4.4.8
 Assigned To:  nlopess
 New Comment:

ok, I've upgraded it today.


Previous Comments:


[2008-07-17 01:00:06] [EMAIL PROTECTED]

Nuno, didn't you already upgrade PCRE in PHP_4_4 branch..? (for the
last release..)



[2008-03-04 19:35:42] test_junk at hotmail dot it

There are several script using eval() statement in an unsafe manner
(i.e. http://www.securityfocus.com/bid/14086), this makes the
vulnerability remotely exploitable and potentially dangerous.



[2008-03-03 10:50:03] [EMAIL PROTECTED]

Yes, that's true. This is only a problem if the program uses
user-supplied regexes.
I think that the most problematic thing was the pcre 7.0 BC break, that
was later fixed in 7.2 (we still bundle 7.0).
Anyway, Derick please reassign the bug report to me again if you want
me to upgrade pcre or close it otherwise. I can always upgrade PCRE
later if you decide to make a new release for some other reason.



[2008-03-03 08:17:02] [EMAIL PROTECTED]

>From what I can see from their ChangeLog:

1.  A character class containing a very large number of characters
with
codepoints greater than 255 (in UTF-8 mode, of course) caused a
buffer overflow.

Which is only an issue for the expression, and not "input" - so this
should only be an issue if you use user-supplied input. Otherwise it's
just a local-developer issue only. Which IMO doesn't warrant a new
release.



[2008-03-01 22:52:54] [EMAIL PROTECTED]

I can upgrade it in CVS, but I'm not sure there will be any further PHP
4 release. Derick can you comment on this?



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

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

#45479 [Opn->Csd]: wrong result when using preg_replace with /u and ungreedy *?

2008-07-15 Thread nlopess

 ID:   45479
 Updated by:   [EMAIL PROTECTED]
 Reported By:  michael dot virnstein at brodos dot de
-Status:   Open
+Status:   Closed
 Bug Type: PCRE related
 Operating System: Linux
 PHP Version:  5.2.6
 New Comment:

Bug was in PCRE (http://bugs.exim.org/show_bug.cgi?id=732) and not in
PHP. Anyway the fix will be bundled with the next PCRE release.


Previous Comments:


[2008-07-10 16:53:13] michael dot virnstein at brodos dot de

Description:

When i use preg_replace with the /u utf-8 modifier and an ungreedy
search e.g. with *?, the result is different to a call without /u.

Reproduce code:
---
";
echo "with /u: ".preg_replace('/^[^d]*?(d)?$/u', '\\1', 'abc');
?>

Expected result:

without /u:
with /u:

Actual result:
--
without /u:
with /u: abc





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

#45372 [Asn->Csd]: hash# check in new re2c parser breaks code

2008-07-08 Thread nlopess

 ID:   45372
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Assigned
+Status:   Closed
 Bug Type: Scripting Engine problem
 Operating System: linux
 PHP Version:  5.3CVS-2008-06-27 (CVS)
 Assigned To:  nlopess
 New Comment:

Ok, I think it is really fixed now. I even fixed other related bug.
Please test and let me know if you can still break it :-)


Previous Comments:


[2008-07-08 13:28:00] [EMAIL PROTECTED]

Nuno, fix not correct?



[2008-07-07 14:12:44] [EMAIL PROTECTED]

This is not fixed, actually (is it OK to change Status back to Open?).

Nuno, I saw your commit yesterday, which didn't seem like it would help
(as it wasn't related to what I said above), but wanted to wait until I
could check again to make sure I wasn't crazy with my above description.
:-)

I just tried the latest Windows snapshot and it's still generating a
parse error with the *single line file* (no newline at the end, which .+
won't match, therefore won't trigger the YYFILL() "return 0" thing)
descibed in this report (and the CLI example in Bug #44654). Can't be
only broken on Windows since everything uses the same generated scanner
code...

Something like Alan's scanning loop could be done after just matching
#, BUT that's just another workaround for that underlying re2c/YYFILL()
problem (also affecting other things). I believe if you use the
tokenizer extension, you can see that if the last token of code is
matched by a variable length rule, it won't be returned. e.g. my example
of a simple rule, [a-z]+ not matching input "foo"



[2008-07-06 17:01:55] [EMAIL PROTECTED]

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.





[2008-06-27 14:57:57] [EMAIL PROTECTED]

Not sure why re2c needs to deal with the #bang situation
looking at the code it would be better to eat that line outside of the
lexer..


Something like:

int ini_lex(zval *ini_lval TSRMLS_DC)
{
 if ((YYCTYPE*)yytext == SCNG(yy_start) && *yych == '#') {
 while(*yych != '\n' && *yych != '\n' && yych < yyend) {
yych++; 
 }
 while((*yych == '\n' || *yych == '\n') && yych < yyend) {
yych++; 
 }
 YYCURSOR = yych;
 }
.



[2008-06-27 11:26:18] [EMAIL PROTECTED]

Duplicated... Bug #45147



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

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

#44925 [Asn]: preg_grep and array index - follow up on #44191

2008-07-06 Thread nlopess

 ID:  44925
 Updated by:  [EMAIL PROTECTED]
 Reported By: admin at ifyouwantblood dot de
 Status:  Assigned
 Bug Type:PCRE related
 PHP Version: 5.2.6
 Assigned To: nlopess
 New Comment:

I don't really know what to do with this..
While I agree it shouldn't modify the original array, changing the
behavior would break BC.. Any opinions about this?


Previous Comments:


[2008-05-06 16:00:03] admin at ifyouwantblood dot de

> PHP obviously should convert the values to string to be used in
> regex matching. Hence, i think that it should returns the string
> that was matched.

sure, internally it'll has to be converted, but i see no reason for a
change of the input array. thus preg_grep should work with a copy of the
input array...



[2008-05-06 13:07:09] [EMAIL PROTECTED]

Well, preg_grep() != in_array()...
PHP obviously should convert the values to string to be used in regex
matching. Hence, i think that it should returns the string that was
matched.

Anyway, i'll assign to the maintainer to solve this issue.

Thanks.



[2008-05-06 12:48:29] admin at ifyouwantblood dot de

>> this is a follow up on bug #44191. that was fixed, but everything
>> inside the array is now converted to a string. as i understand it,
>> the search array shouldn't change at all, so i think this is a
>> bug. please note that with objects without a __toString() method, >>
this of course leads to a fatal error.
>
> This is expected, the function is for matching strings.

sorry, but did you even take a look at the samples? preg_grep is a
SEARCH function, why should it change the INPUT array?



[2008-05-06 10:57:14] [EMAIL PROTECTED]

> this is a follow up on bug #44191. that was fixed, but everything >
inside
> the array is now converted to a string. as i understand it, the
search
> array shouldn't change at all, so i think this is a bug. please note
> that with objects without a __toString() method, this of course leads
to
> a fatal error.

This is expected, the function is for matching strings.

> another thing is, preg_grep issues a warning if you give it an
object
> instead of converting the object to an array (like other function
like
> array_flip() do)

Exactly, preg_grep() is intended for works only with arrays.

> addtionally a question: how should preg_grep react on multi-
> dimensional
> arrays anyways? convert them to a string and try to match the
pattern?
> go through every level and return a multi-dimensional array? issue a
> warning?

The PHP converts for the literal string 'Array'.
That can be viewed with: var_dump(preg_grep('//', array(array(;



Thanks.



[2008-05-06 09:49:09] admin at ifyouwantblood dot de

Description:

this is a follow up on bug #44191. that was fixed, but everything
inside the array is now converted to a string. as i understand it, the
search array shouldn't change at all, so i think this is a bug. please
note that with objects without a __toString() method, this of course
leads to a fatal error.

another thing is, preg_grep issues a warning if you give it an object
instead of converting the object to an array (like other function like
array_flip() do)

addtionally a question: how should preg_grep react on multi-dimensional
arrays anyways? convert them to a string and try to match the pattern?
go through every level and return a multi-dimensional array? issue a
warning?

Reproduce code:
---
$array=Array("1",2,3,1.1,FALSE,NULL,Array());

var_dump($array); echo "\n";

var_dump(preg_grep('/asdf/',$array)); echo "\n";

var_dump($array); echo "\n";

var_dump(preg_grep('/asdf/',new stdClass)); echo "\n";

Expected result:

array(8) { [0]=> string(1) "1" [1]=> int(2) [2]=> int(3) [3]=>
float(1.1) [4]=> bool(false) [5]=> NULL [6]=> array(0) { } [7]=>
object(stdClass)#8 (0) { } } 

array(0) { }

array(8) { [0]=> string(1) "1" [1]=> int(2) [2]=> int(3) [3]=>
float(1.1) [4]=> bool(false) [5]=> NULL [6]=> array(0) { } }  

array(0) { }

Actual result:
--
array(7) { [0]=> string(1) "1" [1]=> int(2) [2]=> int(3) [3]=>
float(1.1) [4]=> bool(false) [5]=> NULL [6]=> array(0) { } } 

Notice: Array to string conversion in D:\_projects\preg_grep.php

array(0) { } 

array(7) { [0]=> string(1) "1" [1]=> string(1) "2" [2]=> string(1) "3"
[3]=> st

#45366 [Ver->Bgs]: preg_match_all() misses elements (corner-case)

2008-07-06 Thread nlopess

 ID:   45366
 Updated by:   [EMAIL PROTECTED]
 Reported By:  Arne dot Heizmann at csr dot com
-Status:   Verified
+Status:   Bogus
 Bug Type: PCRE related
 Operating System: *
 PHP Version:  5.2.6
 New Comment:

backtrack limit reached.
use the following:
ini_set('pcre.backtrack_limit', PHP_INT_MAX);


Previous Comments:


[2008-07-02 02:48:52] [EMAIL PROTECTED]

I can reproduce.

PS: The example works fine on pcretest (PCRE version 7.6).



[2008-06-26 13:37:36] Arne dot Heizmann at csr dot com

Description:

The following example code demonstrates that preg_match_all() does not
always return all elements as it should.

Almost any change to the input string makes the bug no longer trigger.
For example, remove one of the B's, and the bug no longer occurs. Same
goes for the regexp: if you change the (?=X|Y) to (?=X) or anything
simpler, the bug no longer triggers.

Reproduce code:
---



Expected result:

array (
  0 => 
  array (
0 => 'A',
1 => ',',
2 => ' ',
3 => 'B',
4 => 'B',
5 => 'B',
6 => 'B',
7 => 'B',
8 => 'B',
9 => 'B',
10 => 'B',
11 => ' ',
12 => 'a',
13 => 'b',
14 => 'c',
15 => 'd',
16 => ' ',
17 => 'a',
18 => 'b',
19 => 'c',
20 => 'd',
21 => '\'',
22 => 'y',
  ),
)

Actual result:
--
array (
  0 => 
  array (
0 => 'A',
1 => ',',
2 => ' ',
  ),
)





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

#39495 [Asn->WFx]: memory leak with php_pcre_match() (PHP 4 only!)

2008-07-06 Thread nlopess

 ID:   39495
 Updated by:   [EMAIL PROTECTED]
 Reported By:  rsky0711 at gmail dot com
-Status:   Assigned
+Status:   Wont fix
 Bug Type: PCRE related
 Operating System: ALL
 PHP Version:  4.4.4
 Assigned To:  andrei
 New Comment:

PHP 4 is dead. also those lines are never reached in practice.


Previous Comments:


[2006-11-13 13:40:06] rsky0711 at gmail dot com

Description:

This is a patch. This problem is already fixed in PHP_5_1, 
PHP_5_2 and HEAD branch.
--- php_pcre.c.orig 2006-11-13 21:56:27.0 +0900
+++ php_pcre.c  2006-11-13 21:58:42.0 +0900
@@ -454,6 +454,8 @@
if (rc < 0) {
php_error(E_WARNING, "%s: internal pcre_fullinfo
() error %d",
  get_active_function_name(TSRMLS_C), 
rc);
+   efree(offsets);
+   efree(subpat_names);
RETURN_FALSE;
}
if (name_cnt > 0) {
@@ -464,6 +466,8 @@
if (rc < 0) {
php_error(E_WARNING, "%s: internal 
pcre_fullinfo() error %d",
  get_active_function_name
(TSRMLS_C), rc);
+   efree(offsets);
+   efree(subpat_names);
RETURN_FALSE;
}
 







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

#45372 [Asn->Csd]: hash# check in new re2c parser breaks code

2008-07-06 Thread nlopess

 ID:   45372
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Assigned
+Status:   Closed
 Bug Type: Scripting Engine problem
 Operating System: linux
 PHP Version:  5.3CVS-2008-06-27 (CVS)
 Assigned To:  helly
 New Comment:

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:


[2008-06-27 14:57:57] [EMAIL PROTECTED]

Not sure why re2c needs to deal with the #bang situation
looking at the code it would be better to eat that line outside of the
lexer..


Something like:

int ini_lex(zval *ini_lval TSRMLS_DC)
{
 if ((YYCTYPE*)yytext == SCNG(yy_start) && *yych == '#') {
 while(*yych != '\n' && *yych != '\n' && yych < yyend) {
yych++; 
 }
 while((*yych == '\n' || *yych == '\n') && yych < yyend) {
yych++; 
 }
 YYCURSOR = yych;
 }
.



[2008-06-27 11:26:18] [EMAIL PROTECTED]

Duplicated... Bug #45147



[2008-06-27 09:31:21] [EMAIL PROTECTED]

This should work like in older releases, Marcus please check it!



[2008-06-27 09:05:48] [EMAIL PROTECTED]

(yyless(1) could just be used before the goto...)

Anyway, did you actually try that? AFAIK it still won't work, at least
with your single line example (which there's already been at least one
report about). While the local code fix is correct, the re2c code/logic
seems flawed to me. (Maybe this bug report can be about that instead, in
general, since I didn't get around to sending a follow-up message to the
internals@ list yet, explaining things. :-))

In this example, it will still be broken because of the YYFILL() check
-- each time it checks if the next character can match, even when it's
at the end of the input. YYFILL() then makes it return, completely
ignoring anything that has matched up to that point!

I'm not sure if this explanation is 100% correct, but I believe this
wrong behavior happens when EOF is encountered while trying to match the
variable length part of ANY rule; or something close to that. :-) It's
been over a month since I tried to track and figure out what was
happening. Granted, most of the cases (unlike yours), where the match is
aborted because of YYFILL(), it's with invalid code, but it shouldn't
happen. BTW, I think the part with the inline_char_handler label where
it looks for opening PHP tags in the HTML, while a good optimization
(using memchr() to find < etc.), was actually added as a workaround for
this re2c/YYFILL() behavior. I didn't try it, but from what I've
observed, I think whatever plain HTML was at the end of a file would
have been lost if a regular rule (like in Flex) was used to match it...

Oh, there are also some more bugs in the code that looks for opening
PHP tag, but they wouldn't be found as easily as this (and haven't been
reported so far). I think I know how it can be fixed nicely, along with
some more other scanner optimizations (for inline HTML and comments,
basically). But I haven't done anything yet since some of it won't even
work with these re2c/YYFILL() issues. :-/

Finally, to simplify what I think is the basic, underlying flaw with
the code of re2c and YYFILL() now, here's a super easy example. Say you
have one rule:

[a-z]+

It will NEVER match any input that a person would think, such as the
string "foo" -- seems pretty messed up to me!?



[2008-06-27 06:03:16] [EMAIL PROTECTED]

marking as critical



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

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

#44654 [Asn->Csd]: Syntax error for #

2008-07-06 Thread nlopess

 ID:   44654
 Updated by:   [EMAIL PROTECTED]
 Reported By:  xuefer at gmail dot com
-Status:   Assigned
+Status:   Closed
 Bug Type: Compile Failure
 Operating System: *
 PHP Version:  5.3CVS-2008-04-06 (CVS)
 Assigned To:  nlopess
 New Comment:

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:


[2008-04-07 17:51:50] [EMAIL PROTECTED]

It is.

http://lxr.php.net/source/ZendEngine2/zend_language_scanner.l#2155

Was added during the conversion to handle the shebang, it may not be
quite working as expected though.



[2008-04-07 17:04:09] xuefer at gmail dot com

tested with cli and fastcgi web (not cgi), so not a shebang problem.
we're talking about this bug at mailinglist and looks like it's
relatived to re2c lexer changes recentl



[2008-04-07 08:05:55] [EMAIL PROTECTED]

Are you running PHP in CGI mode? If so then it might be the CGI shebang
doing funky stuff after my guessings atleast in 2.php even though it
isn't #! as shebangs normally are...

For the CLI example I think (from memories) that you can't break in and
out of php with the -r option.



[2008-04-06 14:19:03] xuefer at gmail dot com

Description:

$ php -r 'if (1) { ?># ##

2.php
#
#

expected:
#1#1
actual:
#
#


Expected result:

used to work in php5.2 IIRC and echo # character

Actual result:
--
Parse error: syntax error, unexpected $end in Command line code on line
1






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

#45408 [Asn->Csd]: bundled version of libpcre misses security fix for CVE-2008-2371

2008-07-06 Thread nlopess

 ID:   45408
 Updated by:   [EMAIL PROTECTED]
 Reported By:  hoffie at gentoo dot org
-Status:   Assigned
+Status:   Closed
 Bug Type: PCRE related
 Operating System: Irrelevant
 PHP Version:  5.2.6
 Assigned To:  nlopess
 New Comment:

patch applied, thanks!


Previous Comments:


[2008-07-01 18:46:13] hoffie at gentoo dot org

Description:

The bundled version of libpcre misses the security fix for
CVE-2008-2371.

See http://bugs.gentoo.org/show_bug.cgi?id=228091 for details
(including a patch).

http://overlays.gentoo.org/proj/php/browser/patches/php-patches/5.2.6/5.2.6/012_pcre-integer-overflow.patch






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

#35691 [Asn->Ver]: Can't change to another drive letter using chdir()

2008-06-23 Thread nlopess

 ID:   35691
 Updated by:   [EMAIL PROTECTED]
 Reported By:  ejwaibel at gmail dot com
-Status:   Assigned
+Status:   Verified
 Bug Type: Directory function related
 Operating System: Windows
 PHP Version:  5CVS-2005-12-19 (snap)
 Assigned To:  nlopess
 New Comment:

I don't have time to investigate this problem further..


Previous Comments:


[2007-05-26 03:34:17] laifanleuk at net-yan dot com

Same problem here.  Try to open_dir to a SUBST'ed directory failed. 
Using XP sp2, Apache 2.2.4 is install by my admin, running as service . 
I have no administrator access right. 

Before my admin installed Apache as service, I was using apache as
normal user, running in console mode.  It worked perfectly then.



[2006-11-01 15:11:45] [EMAIL PROTECTED]

I reproduce this with both Windows XP and 2003.



[2006-11-01 15:05:44] [EMAIL PROTECTED]

OK, I was able to reproduce the problem.
I used Apache 2.0 and is_dir() doesn't work with network mapped drives.
other drives work and in CLI mode it also works. (it can be because
Apache runs as another user, although I haven't looked further into the
problem)



[2006-09-26 15:28:47] thiagomp at gmail dot com

The problem appeared here with the following configuration:
Windows XP SP2
PHP 5.0.5 (with Apache 1.3.33) and 5.1.6 (with Apache 2.0.59)



[2006-01-20 10:18:32] jarek at katnik dot pl

It happpens also with Apache 1.3.31.



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

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

#45035 [Opn->Bgs]: Reg exp. '/\w/u' not include ő, ű, Ő; and Ű; utf characters

2008-05-19 Thread nlopess

 ID:   45035
 Updated by:   [EMAIL PROTECTED]
 Reported By:  kamarton at gmail dot com
-Status:   Open
+Status:   Bogus
 Bug Type: PCRE related
 Operating System: Win XP
 PHP Version:  5.2.6
 New Comment:

Not a bug in PHP. Bugs in the PCRE lib should be filled at:
http://bugs.exim.org/enter_bug.cgi?product=PCRE


Previous Comments:


[2008-05-18 19:07:55] kamarton at gmail dot com

Reproduce code:
---
echo
preg_replace('/\w/u','_','öüóőúéáűíÖÜÓŐÚÉÁŰÍ');

Expected result:

echo -> '__'

Actual result:
--
echo -> '___ő___űŐ___Ű_'



[2008-05-18 18:52:42] kamarton at gmail dot com

Description:

The regular expression engine with 'u' modifiers '\w' class not include
few hungarian characters.
Not include: ő, ű, Ő and Ű.
PHP source file coding in utf8 with BOM.

Sorry my english.
Regards,
Marton

System:
WinXP, SP2
PHP 5.2.5 (xampp version)
(source editor: Notepad++ v4.9.2.)

Reproduce code:
---
echo
preg_replace('/\w/u','_','öüóőúéáűíÖÜÓŐÚÉÁŰÍ');

Expected result:

echo -> '__'

Actual result:
--
echo -> '___ő___űŐ___Ű_'





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

#44872 [Opn->Fbk]: canary mismatch on efree() - heap overflow detected

2008-05-02 Thread nlopess

 ID:   44872
 Updated by:   [EMAIL PROTECTED]
 Reported By:  mattr at shoplet dot com
-Status:   Open
+Status:   Feedback
 Bug Type: MySQLi related
 Operating System: FreeBSD 6.2
 PHP Version:  5.2.5
 New Comment:

Please try using this CVS snapshot:

  http://snaps.php.net/php5.3-latest.tar.gz
 
For Windows (zip):
 
  http://snaps.php.net/win32/php5.3-win32-latest.zip

For Windows (installer):

  http://snaps.php.net/win32/php5.3-win32-installer-latest.msi




Previous Comments:


[2008-04-30 17:19:34] mattr at shoplet dot com

Description:

The execution of the attached script halts unexpectedly with "ALERT -
canary mismatch on efree() - heap overflow detected (attacker
'REMOTE_ADDR not set', file '../library/Zend/Db/Statement/Mysqli.php',
line 113)" in the apache error log.


PHP Info:
---
PHP Version => 5.2.5
System => FreeBSD localhost 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Fri Jan
12 11:05:30 UTC 2007 [EMAIL PROTECTED]
alo.edu:/usr/obj/usr/src/sys/SMP i386
Configure Command =>  './configure'  '--with-layout=GNU'
'--with-config-file-scan-dir=/usr/local/etc/php' '--disable-all' '--e
nable-libxml' '--with-libxml-dir=/usr/local' '--enable-reflection'
'--program-prefix=' '--enable-fastcgi' '--with-apxs=/usr/lo
cal/sbin/apxs' '--with-regex=php' '--with-zend-vm=CALL'
'--enable-debug' '--enable-zend-multibyte' '--prefix=/usr/local' '--ma
ndir=/usr/local/man' '--infodir=/usr/local/info/'
PHP API => 20041225
PHP Extension => 20060613
Zend Extension => 220060519
Debug Build => yes
Thread Safety => disabled
Zend Memory Manager => enabled
IPv6 Support => enabled

This server is protected with the Suhosin Patch 0.9.6.2
Copyright (c) 2006 Hardened-PHP Project

---

Script fails on another machine running Debian 4 in the same
reproducible manner with and without the Suhosin patch.




Reproduce code:
---
#!/usr/local/bin/php
http://framework.zend.com
// Can attach to the ticket later if needed.

date_default_timezone_set('America/New_York');

$db =
Zend_Db::factory('mysqli',Array('host'=>'localhost','username'=>'','password'=>'','dbname'=>'eproc'));
$order_num = 1208212550;

$sql = $db->quoteInto("SELECT * FROM `eproc`.`Orders` WHERE
`order_num`=? LIMIT 1",$order_num);
$q = $db->fetchAll($sql);

$batch_status = $db->fetchOne("SELECT `to_po` FROM
`eproc2`.`batch_status` WHERE `status`='done' ORDER BY `to_po` DESC
LIMIT 1");

$items = $db->fetchAll("SELECT * FROM `eproc`.`Order_Item` WHERE
`order_num`='{$order_num}' ORDER BY `line_num` ASC");

$notes = $db->fetchAll("SELECT * FROM `eproc`.`notes` WHERE
`order_num`='{$order_num}' ORDER BY `sticky` DESC, `date_modified`
ASC");


$emails = $db->fetchAll("SELECT
`message_id`,`from_email`,`to_email`,`subject`,`date_received` FROM
`email_store`.`email` WHERE `order_num`='{$order_num}' ORDER BY
`date_received` ASC");

$attachments = $db->fetchAll("SELECT * FROM `files`.`order_attachments`
WHERE `order_num`='{$order_num}' ORDER BY `timestampAdded` ASC");

print_r($q);
print_r($order_id);
print_r($batch_status);
print_r($items);
print_r($notes);
print_r($emails);
print_r($attachments);


Expected result:

Several Arrays of database results

Actual result:
--
Execution:
[Wed Apr 30 12:45:01 2008]  Script:  './index.php'
---
/usr/ports/lang/php5/work/php-5.2.5/Zend/zend_opcode.c(238) : Block
0x0828d0e0 status:
Invalid pointer: ((prev=0x0045) != (prev.size=0x))
---
[Wed Apr 30 12:45:01 2008]  Script:  './index.php'
---
/usr/ports/lang/php5/work/php-5.2.5/Zend/zend_variables.h(35) : Block
0x0828d09c status:
/usr/ports/lang/php5/work/php-5.2.5/Zend/zend_variables.c(36) : Actual
location (location was relayed)
Invalid pointer: ((size=0x) != (next.prev=0x003d))
---
[Wed Apr 30 12:45:01 2008]  Script:  './index.php'
/usr/ports/databases/php5-mysqli/work/php-5.2.5/ext/mysqli/mysqli_api.c(362)
:  Freeing 0x0828D060 (0 bytes), script=./index.php
zend_mm_heap corrupted
Segmentation fault (core dumped)




Backtrace:

#0  0x28583ecb in kill () from /lib/libc.so.6
#1  0x08150f51 in zend_mm_panic (message=0x8252700 "zend_mm_heap
corrupted")
at /usr/ports/lang/php5/work/php-5.2.5/Zend/zend_alloc.c:94
#2  0x08151ef5 in zend_mm_find_leaks (segment=0x827e000, b=0x828d02c)
at /usr/ports/lang/php5/work/php-5.2.5/Zend/zend_alloc.c:1223
#3  0x08152070 in zend_mm_check_leaks (heap=0x827d400) at
/usr/ports/lang/php5/work/php-5.2.5/Zend/zend_alloc.c:1277
#4  0x08152aaf in zend_mm_shutdown (heap=0x827d400, full_shutdown=0,
silent=0)
at /usr/ports/lang/php5/work/php-5.2.5/Zend/zend_alloc.c:1632
#5  0x08154a76 in shutdown_memory_manager (silent=0, full_shutdown=0)
at /usr/ports/lang/php5/work/php-5.2.5/Zend/zend_all

#43348 [Asn]: Mail function returns true but no email sent

2008-04-19 Thread nlopess

 ID:   43348
 Updated by:   [EMAIL PROTECTED]
 Reported By:  RQuadling at GMail dot com
 Status:   Assigned
 Bug Type: Mail related
 Operating System: Windows XP SP2
 PHP Version:  5.3CVS-2007-11-20 (snap)
 Assigned To:  johannes
 New Comment:

a better fix is:
if (!sendmail_path || !*sendmail_path)

let me know if you want me to commit this.


Previous Comments:


[2008-04-17 14:45:55] RQuadling at GMail dot com

Hi.

I have finally managed to get php to compile for windows (yippee for
me).

So I can now try and get mail() working again.

The issue is that in  ext/standard/mail.c (/* $Id: mail.c,v
1.87.2.1.2.7.2.3 2007/12/31 07:17:15 sebastian Exp $ */), line 197,
the test of ...

if (!sendmail_path)

always evaluates to false when there is no sendmail_path which would
be the case on windows.

The next line differentiates between processing for windows/netware
and everything else.

If the test is

if(0 == strlen(sendmail_path))

then that would work.

The INI_STR call in Line 194 always returns a string if the directive
is known (doesn't need to be set, just has to exist as a directive).

So, I've attached a patch which I have compiled and tested on Windows.

This is in relation to bug http://bugs.php.net/bug.php?id=43348


Index: mail.c
===
RCS file: /repository/php-src/ext/standard/mail.c,v
retrieving revision 1.87.2.1.2.7.2.3
diff -u -u -r1.87.2.1.2.7.2.3 mail.c
--- mail.c  31 Dec 2007 07:17:15 -  1.87.2.1.2.7.2.3
+++ mail.c  17 Apr 2008 14:40:33 -
@@ -194,7 +194,7 @@
   char *sendmail_path = INI_STR("sendmail_path");
   char *sendmail_cmd = NULL;

-   if (!sendmail_path) {
+   if (0 == strlen(sendmail_path)) {
 #if (defined PHP_WIN32 || defined NETWARE)
   /* handle old style win smtp sending */
   if (TSendMail(INI_STR("SMTP"), &tsm_err, &tsm_errmsg,
headers,
subject, to, message, NULL, NULL, NULL TSRMLS_CC) == FAILURE) {



[2007-12-04 16:50:44] RQuadling at GMail dot com

Just to iterate, the mail function for windows in the CVS is broken for
CLI, CGI and ISAPI.



[2007-12-04 15:54:42] pipaff at comptrio dot com

Update: Switched back to CGI and mail works again... lost the ability
to 'except users' from safe_mode in Apache config
(php_admin_value/flag), but mail works.

This is on a Linux box CentOS4... 2.6.9 kernel



[2007-12-04 08:44:57] pipaff at comptrio dot com

The title caught my eye right away...

PHP 5.2.4 as DSO fails to work properly (Apache 2.0.61)

$mail = mail("[EMAIL PROTECTED]","test","test inside","From:
[EMAIL PROTECTED]");
if($mail){
print "true";
}else{
print"false";
}


Expected: "true" and an email to be received (or false without email)

Actual: "true", but no email received, no error message/log, no record
in MTA (exim)


Recently Changed: CGI to DSO, same code worked prior using same
PHP/Apache version



[2007-11-20 17:04:54] RQuadling at GMail dot com

C:\testmail.php


and then

C:\PHP4\PHP -n C:\testmail.php
I get 4.4.7-dev message

C:\PHP5\PHP -n C:\testmail.php
I get nothing.

V:\PHP5.2.2RC2-dev\PHP -n C:\testmail.php
I get 5.2.2RC2-dev message

Today, we made a change from McAfee AV to Symantec AV. I am getting
little alerts for PHP4 and the PHP5.2.2 messages going out, but nothing
for PHP5.3.0-dev



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

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

#44461 [Ver]: parse_ini_file crashes

2008-03-20 Thread nlopess

 ID:   44461
 Updated by:   [EMAIL PROTECTED]
 Reported By:  crrodriguez at suse dot de
 Status:   Verified
 Bug Type: Reproducible crash
 Operating System: Linux 64bit
 PHP Version:  5.3CVS-2008-03-17 (CVS)
 New Comment:

ok, I misread the action for '\r'.
there's this code as well:
yy286:
yych = *++YYCURSOR;
switch (yych) {
case '\n':  goto yy284;
default:goto yy285;
}

so it's yyfill(2) because of \r\n. Dunno where to patch this.. we can
either change the regex and check for the newline manually (which is
sort of a hack), enable yyfill for lens > 1 (what's the "safe"
threshold?), or change the yyfill macro to something smarter..


Previous Comments:


[2008-03-21 00:25:19] [EMAIL PROTECTED]

damn, oh I hate YYFILL.. the problem is this piece of code generated by
re2c:

yy282:
++YYCURSOR;
if ((YYLIMIT - YYCURSOR) < 2) YYFILL(2);
yych = *YYCURSOR;
yy283:
switch (yych) {
case '\n':  goto yy284;
case '\r':  goto yy286;
default:goto yy282;
}
yy284:
++YYCURSOR;
yy285:
yyleng = YYCURSOR - SCNG(yy_text);
#line 476 "zend_ini_scanner.l"
{ /* Comment */
BEGIN(INITIAL);
SCNG(lineno)++;
return END_OF_LINE;
}

the problem is that YYFILL(2) is ignored (because it's > 1). I dunno
why re2c doesn't generate a YYFILL(1) there instead..



[2008-03-19 21:34:51] [EMAIL PROTECTED]

I can confirm this, its over-reading by a character if there is no
newline at the end of the file.



[2008-03-19 21:12:37] crrodriguez at suse dot de

I have:

re2c -v
re2c 0.13.3


I have checked a fresh-, clean CVS copy just now and i can still
reproduce the problem.

Here I have the exact ini file that makes php crash

http://stuff.cristianrodriguez.net/phpbugs/bug44461.tar.bz2

# cd bug44461
# ./sapi/cli/php bug44461.php



[2008-03-18 21:50:57] [EMAIL PROTECTED]

Did you do './cvsclean && ./buildconf' ? And what re2c version do you
have installed?



[2008-03-17 23:35:39] [EMAIL PROTECTED]

Works fine to me.



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

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

#44461 [Ver]: parse_ini_file crashes

2008-03-20 Thread nlopess

 ID:   44461
 Updated by:   [EMAIL PROTECTED]
 Reported By:  crrodriguez at suse dot de
 Status:   Verified
 Bug Type: Reproducible crash
 Operating System: Linux 64bit
 PHP Version:  5.3CVS-2008-03-17 (CVS)
 New Comment:

damn, oh I hate YYFILL.. the problem is this piece of code generated by
re2c:

yy282:
++YYCURSOR;
if ((YYLIMIT - YYCURSOR) < 2) YYFILL(2);
yych = *YYCURSOR;
yy283:
switch (yych) {
case '\n':  goto yy284;
case '\r':  goto yy286;
default:goto yy282;
}
yy284:
++YYCURSOR;
yy285:
yyleng = YYCURSOR - SCNG(yy_text);
#line 476 "zend_ini_scanner.l"
{ /* Comment */
BEGIN(INITIAL);
SCNG(lineno)++;
return END_OF_LINE;
}

the problem is that YYFILL(2) is ignored (because it's > 1). I dunno
why re2c doesn't generate a YYFILL(1) there instead..


Previous Comments:


[2008-03-19 21:34:51] [EMAIL PROTECTED]

I can confirm this, its over-reading by a character if there is no
newline at the end of the file.



[2008-03-19 21:12:37] crrodriguez at suse dot de

I have:

re2c -v
re2c 0.13.3


I have checked a fresh-, clean CVS copy just now and i can still
reproduce the problem.

Here I have the exact ini file that makes php crash

http://stuff.cristianrodriguez.net/phpbugs/bug44461.tar.bz2

# cd bug44461
# ./sapi/cli/php bug44461.php



[2008-03-18 21:50:57] [EMAIL PROTECTED]

Did you do './cvsclean && ./buildconf' ? And what re2c version do you
have installed?



[2008-03-17 23:35:39] [EMAIL PROTECTED]

Works fine to me.



[2008-03-17 21:08:09] crrodriguez at suse dot de

Description:

parse_ini_file() is currenly crashing with a very simple ini file

Reproduce code:
---
test.ini

[attachments]
zip = "application/zip" ; MIME-type for ZIP files


test.php



Expected result:

ini file parsed correctly

Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
0x006f71f4 in ini_lex (ini_lval=0x7fff580c52d0) at
/home/cristian/php5.3/Zend/zend_ini_scanner.c:4063
4063yych = *YYCURSOR;
(gdb) bt full
#0  0x006f71f4 in ini_lex (ini_lval=0x7fff580c52d0) at
/home/cristian/php5.3/Zend/zend_ini_scanner.c:4063
yych = 0 '\0'
yyaccept = 2
yybm = {128 '\200', 128 '\200', 128 '\200', 128 '\200', 128
'\200', 128 '\200', 128 '\200', 128 '\200', 128 '\200', 192 '�',
  0 '\0', 128 '\200', 128 '\200', 0 '\0', 128 '\200' , 192 '�', 128 '\200' , 160 '�',
160 '�',
  128 '\200', 160 '�', 160 '�', 160 '�', 160
'�', 160 '�', 160 '�', 160 '�', 160
'�', 160 '�', 160 '�', 128 '\200', 128 '\200',
  128 '\200', 128 '\200', 128 '\200', 128 '\200', 128 '\200', 160
'�' , 128 '\200', 128 '\200', 128 '\200', 128
'\200',
  160 '�', 128 '\200', 160 '�' , 128
'\200' }
yybm = {16 '\020', 16 '\020', 16 '\020', 16 '\020', 16 '\020',
16 '\020', 16 '\020', 16 '\020', 16 '\020', 144 '\220',
  16 '\020' , 144 '\220', 16 '\020', 0 '\0', 16
'\020', 32 ' ', 16 '\020' , 64 '@',
  16 '\020' }
yybm = {66 'B', 66 'B', 66 'B', 66 'B', 66 'B', 66 'B', 66 'B',
66 'B', 66 'B', 194 '�', 64 '@', 66 'B', 66 'B', 64 '@',
  66 'B' , 194 '�', 66 'B', 64 '@', 66 'B', 68
'D', 66 'B', 66 'B', 0 '\0', 66 'B', 66 'B', 66 'B', 66 'B', 66 'B',
  66 'B', 66 'B', 66 'B', 114 'r', 114 'r', 114 'r', 114 'r', 114 'r',
114 'r', 114 'r', 114 'r', 114 'r', 114 'r', 66 'B', 64 '@',
  66 'B', 66 'B', 66 'B', 66 'B', 66 'B', 82 'R' , 66
'B', 72 'H', 64 '@', 66 'B', 82 'R', 66 'B',
  82 'R' , 66 'B' }
yybm = {160 '�', 160 '�', 160 '�', 160
'�', 160 '�', 160 '�', 160 '�', 160
'�', 160 '�', 224 '�', 0 '\0', 160 '�', 160
'�',
  0 '\0', 160 '�' , 224 '�', 160
'�' , 32 ' ', 160 '�', 32 ' ', 160
'�' }
yybm = {128 '\200', 128 '\200', 128 '\200', 128 '\200', 128
'\200', 128 '\200', 128 '\200', 128 '\200', 128 '\200', 192 '�',
  0 '\0', 128 '\200', 128 '\200', 0 '\0', 128 '\200' , 192 '�', 128 '\200' , 0 '\0',
  128 '\200' }
---Type  to continue, or q  to quit---
yybm = {132 '\204', 132 '\204', 132 '\204', 132 '\204', 132
'\204', 132 '\204', 132 '\204', 132 '\204', 132 '\204', 134 '\206',
  128 '\200', 132 '\204', 132 '\204', 128 '\200', 132 '\204' , 134 '\206', 132 '\204', 128 '\200', 132 '\204',
  136 '\210', 132 '\204', 132 '\204', 0 '\0', 132 '\204', 132 '\204',
132 '\204', 132 '\204', 132 '\204', 132 '\204', 132 '\204',
  132 '\204', 228 '�', 228 '�', 228 '�', 228
'�', 228 '�', 228 '�', 228 '�', 228
'�', 228 '�', 228 '�', 132 '\204', 128 '\200',
  132 '\204', 132 '\204', 132 '\204', 132 '\204', 132 '\204', 164
'

#44418 [Opn->Bgs]: Strange behaviour of preg_split with russian utf-8 strings

2008-03-12 Thread nlopess

 ID:   44418
 Updated by:   [EMAIL PROTECTED]
 Reported By:  yarodin at gmail dot com
-Status:   Open
+Status:   Bogus
 Bug Type: PCRE related
 Operating System: Windows XP PRO/5.1.2600
 PHP Version:  5.2.5
 New Comment:

if the input is UTF-8 you need to use the 'u' modifier. (e.g.
'#(\s)#u').


Previous Comments:


[2008-03-12 16:00:19] yarodin at gmail dot com

Description:

$split = preg_split('#(\s)#', $value, -1, PREG_SPLIT_NO_EMPTY |
PREG_SPLIT_DELIM_CAPTURE );
make wrong spliting sentences on words when sentence at russian UTF-8
and begin with russian letter 'Р' (hex D0h A0h). For example
russian
"Расширенные
поля
пользователей"
splits by php 5.2.5 on 7(!) words, but php4 is split correctly on 5
words. I think the problem at russian letter letter 'Р' wich split
as single word.


Reproduce code:
---
");
$split = preg_split('#(\s)#', $value, -1, PREG_SPLIT_NO_EMPTY |
PREG_SPLIT_DELIM_CAPTURE );
print_r($split);
?>

Expected result:

Array ( [0] =>
Расширенные
[1] => [2] => поля [3] => [4] =>
пользователей
)

Actual result:
--
Array ( [0] => Р [1] => [2] =>
асширенные
[3] => [4] => поля [5] => [6] =>
пользователей
)





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

#44214 [Ver->Csd]: Crash using preg_replace_callback and global variable

2008-03-08 Thread nlopess

 ID:   44214
 Updated by:   [EMAIL PROTECTED]
 Reported By:  php at bouchery dot fr
-Status:   Verified
+Status:   Closed
 Bug Type: Reproducible crash
 Operating System: Windows XP
 PHP Version:  5.3.0-dev
 New Comment:

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:


[2008-03-03 22:31:39] [EMAIL PROTECTED]

uhm, nice.. on windows I get the following stack trace:

zend_hash_destroy(_hashtable * ht=0x01f10318)  Line 525 + 0x5 bytes
_zval_dtor_func(_zval_struct * zvalue=0x01f0e9b8)  Line 44
_zval_ptr_dtor(_zval_struct * * zval_ptr=0x01f0eac4)  Line 422 + 0xe
bytes
zend_hash_destroy(_hashtable * ht=0x01f0e438)  Line 526 + 0x6 bytes
_zval_dtor_func(_zval_struct * zvalue=0x01f101a8)  Line 44
_zval_ptr_dtor(_zval_struct * * zval_ptr=0x01f10224)  Line 422 + 0xe
bytes
zend_hash_apply_deleter(_hashtable * ht=0x01e1e888, bucket *
p=0x01f10218)  Line 611 + 0x6 bytes
zend_hash_graceful_reverse_destroy(_hashtable * ht=0x01e1e888)  Line
647
shutdown_executor(void * * * tsrm_ls=0x002d2640)  Line 246 + 0x17
bytes
zend_deactivate(void * * * tsrm_ls=0x002d2640)  Line 882
php_request_shutdown(void * dummy=0x)  Line 1497

I don't have time to look at this today, though. The problem is related
with the global variable referencing and/or some reference counting bug.



[2008-03-03 15:27:40] php at bouchery dot fr

Same problem with nightly built "PHP 5.3.0-dev (cli) (built: Mar  3
2008 08:18:24)"



[2008-02-22 15:01:39] php at bouchery dot fr

Description:

When assigning callback parameter of preg_replace_callback into a
global variable, PHP CLI interpreter crash at the end of the script.
I generate this error with PHP v5.2.3.3, and I try the last 5.2.5.5,
but the result is the same.

Reproduce code:
---


Expected result:

No crash at the end of the script.

Actual result:
--
Windows crash report with signature error.
---
AppName: php.exe  AppVer: 5.2.5.5  ModName: php5ts.dll
ModVer: 5.2.5.5  Offset: 0009a10a
--





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

#44336 [Asn->Csd]: preg_replace with /u (unicode/UTF-8) and many hits = very bad performance

2008-03-08 Thread nlopess

 ID:   44336
 Updated by:   [EMAIL PROTECTED]
 Reported By:  frode at coretrek dot com
-Status:   Assigned
+Status:   Closed
 Bug Type: PCRE related
 Operating System: Debian GNU/Linux 4.0r3
 PHP Version:  5.2.6RC1
 Assigned To:  nlopess
 New Comment:

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.

this went to the PHP 5.3 and 6 branches only and won't be ported to PHP
5.2.


Previous Comments:


[2008-03-07 08:23:54] frode at coretrek dot com

Thanks :)

Do you have any idea if there's a chance to get this fix into PHP-5.2.6
before release?



[2008-03-05 16:34:41] [EMAIL PROTECTED]

Nice work! :) 

Assigned to maintainer.



[2008-03-05 15:46:27] frode at coretrek dot com

Here's the patch. If it doesn't come through cleanly, it's also
available at http://apollo.coretrek.com/~frode/phpbug-44336.patch.txt

--- php_pcre.c.orig 2008-03-05 16:37:09.0 +0100
+++ php_pcre.c  2008-03-05 16:38:18.0 +0100
@@ -599,20 +599,23 @@
 
match = NULL;
matched = 0;
PCRE_G(error_code) = PHP_PCRE_NO_ERROR;

do {
/* Execute the regular expression. */
count = pcre_exec(pce->re, extra, subject, subject_len,
start_offset,
  exoptions|g_notempty, 
offsets, size_offsets);
 
+   /* Prevent lengthy UTF8 check on subsequent pcre_exec() calls to
save time (See PHP bug 44336) */
+   exoptions |= PCRE_NO_UTF8_CHECK;
+   
/* Check for too many substrings condition. */  
if (count == 0) {
php_error_docref(NULL TSRMLS_CC, E_NOTICE, "Matched, 
but too many
substrings");
count = size_offsets/3;
}
 
/* If something has matched */
if (count > 0) {
matched++;
match = subject + offsets[0];
@@ -1002,20 +1005,23 @@
match = NULL;
*result_len = 0;
start_offset = 0;
PCRE_G(error_code) = PHP_PCRE_NO_ERROR;

while (1) {
/* Execute the regular expression. */
count = pcre_exec(pce->re, extra, subject, subject_len,
start_offset,
  exoptions|g_notempty, 
offsets, size_offsets);

+   /* Prevent lengthy UTF8 check on subsequent pcre_exec() calls to
save time (See PHP bug 44336) */
+   exoptions |= PCRE_NO_UTF8_CHECK;
+   
/* Check for too many substrings condition. */
if (count == 0) {
php_error_docref(NULL TSRMLS_CC,E_NOTICE, "Matched, but 
too many
substrings");
count = size_offsets/3;
}
 
piece = subject + start_offset;
 
if (count > 0 && (limit == -1 || limit > 0)) {
if (replace_count) {
@@ -1439,20 +1445,23 @@
last_match = subject;
match = NULL;
PCRE_G(error_code) = PHP_PCRE_NO_ERROR;

/* Get next piece if no limit or limit not yet reached and something
matched*/
while ((limit_val == -1 || limit_val > 1)) {
count = pcre_exec(pce->re, extra, subject,
  subject_len, start_offset,
  exoptions|g_notempty, 
offsets, size_offsets);
 
+   /* Prevent lengthy UTF8 check on subsequent pcre_exec() calls to
save time (See PHP bug 44336) */
+   exoptions |= PCRE_NO_UTF8_CHECK;
+   
/* Check for too many substrings condition. */
if (count == 0) {
php_error_docref(NULL TSRMLS_CC,E_NOTICE, "Matched, but 
too many
substrings");
count = size_offsets/3;
}

/* If something matched */
if (count > 0) {
match = subject + offsets[0];



[2008-03-05 15:44:49] frode at coretrek dot com

According to ext/pcre/pcrelib/doc/pcre.txt and
ext/pcre/pcrelib/ChangeLog there is a flag PCRE_NO_UTF8_CHECK which was
added in libpcre 4.5:

> 3. When matching a UTF-8 string, the test for a valid string at the
>start has
>

#44214 [Opn->Ver]: Crash using preg_replace_callback and global variable

2008-03-03 Thread nlopess

 ID:   44214
 Updated by:   [EMAIL PROTECTED]
 Reported By:  php at bouchery dot fr
-Status:   Open
+Status:   Verified
 Bug Type: Reproducible crash
 Operating System: Windows XP
 PHP Version:  5.3.0-dev
 New Comment:

uhm, nice.. on windows I get the following stack trace:

zend_hash_destroy(_hashtable * ht=0x01f10318)  Line 525 + 0x5 bytes
_zval_dtor_func(_zval_struct * zvalue=0x01f0e9b8)  Line 44
_zval_ptr_dtor(_zval_struct * * zval_ptr=0x01f0eac4)  Line 422 + 0xe
bytes
zend_hash_destroy(_hashtable * ht=0x01f0e438)  Line 526 + 0x6 bytes
_zval_dtor_func(_zval_struct * zvalue=0x01f101a8)  Line 44
_zval_ptr_dtor(_zval_struct * * zval_ptr=0x01f10224)  Line 422 + 0xe
bytes
zend_hash_apply_deleter(_hashtable * ht=0x01e1e888, bucket *
p=0x01f10218)  Line 611 + 0x6 bytes
zend_hash_graceful_reverse_destroy(_hashtable * ht=0x01e1e888)  Line
647
shutdown_executor(void * * * tsrm_ls=0x002d2640)  Line 246 + 0x17
bytes
zend_deactivate(void * * * tsrm_ls=0x002d2640)  Line 882
php_request_shutdown(void * dummy=0x)  Line 1497

I don't have time to look at this today, though. The problem is related
with the global variable referencing and/or some reference counting bug.


Previous Comments:


[2008-03-03 15:27:40] php at bouchery dot fr

Same problem with nightly built "PHP 5.3.0-dev (cli) (built: Mar  3
2008 08:18:24)"



[2008-02-22 15:01:39] php at bouchery dot fr

Description:

When assigning callback parameter of preg_replace_callback into a
global variable, PHP CLI interpreter crash at the end of the script.
I generate this error with PHP v5.2.3.3, and I try the last 5.2.5.5,
but the result is the same.

Reproduce code:
---


Expected result:

No crash at the end of the script.

Actual result:
--
Windows crash report with signature error.
---
AppName: php.exe  AppVer: 5.2.5.5  ModName: php5ts.dll
ModVer: 5.2.5.5  Offset: 0009a10a
--





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

#44299 [Asn]: PCRE security issue

2008-03-03 Thread nlopess

 ID:   44299
 Updated by:   [EMAIL PROTECTED]
 Reported By:  test_junk at hotmail dot it
 Status:   Assigned
 Bug Type: PCRE related
 Operating System: All
 PHP Version:  4.4.8
-Assigned To:  nlopess
+Assigned To:  derick
 New Comment:

Yes, that's true. This is only a problem if the program uses
user-supplied regexes.
I think that the most problematic thing was the pcre 7.0 BC break, that
was later fixed in 7.2 (we still bundle 7.0).
Anyway, Derick please reassign the bug report to me again if you want
me to upgrade pcre or close it otherwise. I can always upgrade PCRE
later if you decide to make a new release for some other reason.


Previous Comments:


[2008-03-03 08:17:02] [EMAIL PROTECTED]

>From what I can see from their ChangeLog:

1.  A character class containing a very large number of characters
with
codepoints greater than 255 (in UTF-8 mode, of course) caused a
buffer overflow.

Which is only an issue for the expression, and not "input" - so this
should only be an issue if you use user-supplied input. Otherwise it's
just a local-developer issue only. Which IMO doesn't warrant a new
release.



[2008-03-01 22:52:54] [EMAIL PROTECTED]

I can upgrade it in CVS, but I'm not sure there will be any further PHP
4 release. Derick can you comment on this?



[2008-02-29 23:58:05] test_junk at hotmail dot it

Description:

Hello,

PCRE versions prior to 7.6 are affected by a vulnerability:
http://www.securityfocus.com/bid/27786

Unfortunately php 4.4.8 compiled against version 7.6 is unstable, are
you going to fix this issue?

Thanks






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

#44208 [Opn->Bgs]: preg_* UTF-8 support breaks w/ external PCRE

2008-03-02 Thread nlopess

 ID:   44208
 Updated by:   [EMAIL PROTECTED]
 Reported By:  martin dot adolfsson at movel dot se
-Status:   Open
+Status:   Bogus
 Bug Type: PCRE related
 Operating System: Debian GNU/Linux 4.0
 PHP Version:  5.2.5
 New Comment:

You've something broken on your end. I've compiled pcre with the same
options as you did and it worked correctly.


Previous Comments:


[2008-02-22 08:26:37] martin dot adolfsson at movel dot se

Might add some details from pcre-7.6:

pcre-7.6 configuration summary:
...
Enable UTF-8 support  : yes
Unicode properties .. : yes
...

[src/pcre_tables.c]--
#ifdef SUPPORT_UTF8

const int _pcre_utf8_table1[] =...
.
[src/pcre_tables.c]--

$ strings lib/libpcre.a | grep pcre_utf8_table1
_pcre_utf8_table1
...

So AFAIK, PCRE has been built successfully w/ UTF-8 support.



[2008-02-22 08:03:39] martin dot adolfsson at movel dot se

Description:

Attempting to use external PCRE library (7.6), configured with

  --enable-static 
  --disable-shared 
  --enable-utf8 
  --enable-unicode-properties
  --disable-cpp 

in PHP 5.2.5, configured with (among other options):

--with-pcre-regex={PATH_TO_PCRE_INSTALLATION}

Results in calls to preg_match() with /u modifier triggering an error
and stating that "this version of PCRE is not compiled with PCRE_UTF8
support".

Reproduce code:
---
preg_match('//u', '' );

Expected result:



Actual result:
--
preg_match() [function.preg-match]:
Compilation failed: this version of PCRE is not compiled with PCRE_UTF8
support at offset 0 in ...





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

#44299 [Opn]: PCRE security issue

2008-03-01 Thread nlopess

 ID:   44299
 Updated by:   [EMAIL PROTECTED]
 Reported By:  test_junk at hotmail dot it
 Status:   Open
 Bug Type: PCRE related
 Operating System: All
 PHP Version:  4.4.8
 New Comment:

I can upgrade it in CVS, but I'm not sure there will be any further PHP
4 release. Derick can you comment on this?


Previous Comments:


[2008-02-29 23:58:05] test_junk at hotmail dot it

Description:

Hello,

PCRE versions prior to 7.6 are affected by a vulnerability:
http://www.securityfocus.com/bid/27786

Unfortunately php 4.4.8 compiled against version 7.6 is unstable, are
you going to fix this issue?

Thanks






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

#43567 [Opn->Bgs]: PCRE: compilation failure when using UTF-8

2008-01-13 Thread nlopess

 ID:   43567
 Updated by:   [EMAIL PROTECTED]
 Reported By:  brito_victor at yahoo dot fr
-Status:   Open
+Status:   Bogus
 Bug Type: PCRE related
 Operating System: Windows XP SP2
 PHP Version:  5.2.5
 New Comment:

In PHP 5.2.5 we upgraded PCRE to version 7.3. This version has stricter
UTF-8 string validation, and thats why the string is now rejected.
For the record this bug has nothing to do with the mbstring extension.


Previous Comments:


[2007-12-13 12:54:50] brito_victor at yahoo dot fr

I think it is a bug because, when the script is tested within version
5.2.4, it returns true.



[2007-12-13 12:48:17] confins_de_l_univers at yahoo dot fr

I've got the same error on linux (Debian Etch).

But your pattern (and your subject) is not a valid utf-8 string.
I've checked that with : mb_check_encoding("\xf8\xa1\xa1\xa1\xa1",
'UTF-8')
and it returns false.

So, I think it's not a bug.



[2007-12-11 17:08:55] brito_victor at yahoo dot fr

Bug seen on Windows XP SP2.



[2007-12-11 17:02:04] brito_victor at yahoo dot fr

Description:

In a test script, I call preg_match() function, using the flag u, in
order to test an UTF-8 regular expression with hexadecimal characters.
Of course, the mbstring extension is loaded and active.

Reproduce code:
---
$mb = function_exists('mb_detect_encoding');
$pregutf8 = preg_match("/\xf8\xa1\xa1\xa1\xa1/u",
"\xf8\xa1\xa1\xa1\xa1");

Expected result:

Returns true for both variables.

Actual result:
--
Returns true for $mb.
Returns the following warning message for $pregutf8: "Warning: 
preg_match() [function.preg-match]: Compilation failed: invalid UTF-8
string at offset 0"





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

#43104 [Opn->WFx]: preg_* not capturing regex optional last parenthesis value if empty

2008-01-13 Thread nlopess

 ID:   43104
 Updated by:   [EMAIL PROTECTED]
 Reported By:  ch+php at -internet dot com
-Status:   Open
+Status:   Wont fix
 Bug Type: PCRE related
 Operating System: n/a
 PHP Version:  4.4.7
 New Comment:

Yeah, it has been like this for ages, so we can't "fix" it. It will
only add the optional captures if they are in the middle. In that case
we add some empty padding values.


Previous Comments:


[2007-11-23 01:32:21] [EMAIL PROTECTED]

This is expected for flag different of default. (PREG_PATTERN_ORDER)



[2007-10-24 23:53:26] ch+php at -internet dot com

Description:

The code and results attached show two examples of preg_* demonstrating
how an optional parenthesis match at the end of a regular expression is
not being captured if the optional condition is not matched.

I think this is a bug, because if the optional parenthesis is not the
last one in the regex, the empty value IS captured - which suggests that
it should not be omitted just because it happens to be the last one.


Reproduce code:
---
preg_match_all("/(1)(23)?/", "12314123", $match, PREG_SET_ORDER);
print_r($match);
print_r(preg_split("/(1)(23)?/", "12314123", -1,
PREG_SPLIT_DELIM_CAPTURE));


Expected result:

Array
(
[0] => Array
(
[0] => 123
[1] => 1
[2] => 23
)

[1] => Array
(
[0] => 1
[1] => 1
[2] => 
)

[2] => Array
(
[0] => 123
[1] => 1
[2] => 23
)

)
Array
(
[0] => 
[1] => 1
[2] => 23
[3] => 
[4] => 1
[5] => 
[6] => 4
[7] => 1
[8] => 23
[9] => 
)


Actual result:
--
Array
(
[0] => Array
(
[0] => 123
[1] => 1
[2] => 23
)

[1] => Array
(
[0] => 1
[1] => 1
)

[2] => Array
(
[0] => 123
[1] => 1
[2] => 23
)

)
Array
(
[0] => 
[1] => 1
[2] => 23
[3] => 
[4] => 1
[5] => 4
[6] => 1
[7] => 23
[8] => 
)






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

#42945 [Ver->Csd]: preg_split() swallows part of the string

2008-01-13 Thread nlopess

 ID:   42945
 Updated by:   [EMAIL PROTECTED]
 Reported By:  Arne dot Heizmann at csr dot com
-Status:   Verified
+Status:   Closed
 Bug Type: PCRE related
 Operating System: *
 PHP Version:  5CVS-2007-10-22
 New Comment:

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:


[2008-01-12 02:16:40] [EMAIL PROTECTED]

I tested in PHP 5.3


Index: php_pcre.c
===
RCS file: /repository/php-src/ext/pcre/php_pcre.c,v
retrieving revision 1.168.2.9.2.21.2.8
diff -u -r1.168.2.9.2.21.2.8 php_pcre.c
--- php_pcre.c  31 Dec 2007 07:17:11 -  1.168.2.9.2.21.2.8
+++ php_pcre.c  12 Jan 2008 02:14:13 -
@@ -1562,7 +1562,7 @@
}
 
 
-   if (!no_empty || start_offset != subject_len)
+   if (!no_empty || last_match[0] != '\0')
{
if (offset_capture) {
/* Add the last (match, offset) pair to the
return value */




[2007-10-22 08:52:08] [EMAIL PROTECTED]

Verified using latest CVS snapshot.



[2007-10-12 12:04:43] Arne dot Heizmann at csr dot com

Description:

The following example code shows how preg_split() - when used with
PREG_SPLIT_NO_EMPTY - omits pieces which aren't empty. The returned
array SHOULD contain ALL of the characters from the original string
minus the characters that match the separator. In my example, the
separator is a zero-width match.

I notice that this problem was reported as Bug #15413 before and marked
"Bogus". My example shows that the bug is real.

Reproduce code:
---



Expected result:

array (
  0 => 'a',
  1 => '\'',
)

Actual result:
--
array (
  0 => 'a',
)





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

#42737 [Asn->Csd]: Notice: preg_split(): Unknown error

2007-10-07 Thread nlopess

 ID:   42737
 Updated by:   [EMAIL PROTECTED]
 Reported By:  rm at drgs dot no
-Status:   Assigned
+Status:   Closed
 Bug Type: PCRE related
 Operating System: Mac OS X 10.3.9
 PHP Version:  5.2.4
 Assigned To:  nlopess
 New Comment:

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:


[2007-09-22 20:17:43] rm at drgs dot no

this seems to be the case with all strings which end with "\r\n"


btw, theres an extra obsolete parantesis at the end of the second 
line in reproduce code, sorry



[2007-09-22 20:11:09] rm at drgs dot no

Description:

I'm splitting a string into characters with this:

preg_split('//u', $string, - 1, PREG_SPLIT_NO_EMPTY);


I get a notice on an uknown error which happens when I use the 
unicode suffix u in the pattern and when the input string is 
"\r\n":

$string = chr(13).chr(10);

but not when i drop the unicode option, ie. this works fine:
 
preg_split('//', $string, - 1, PREG_SPLIT_NO_EMPTY);

Reproduce code:
---
$string = chr(13).chr(10);

$array = preg_split('//u', $string, - 1, PREG_SPLIT_NO_EMPTY));

print_r(array_map('ord', $array));

Expected result:

Array
(
[0] => 13
[1] => 10
)


Actual result:
--

Notice:  preg_split() [function.preg-split]: Unknown error in /Users/
myname/Sites/script.php on line 73
Array
(
[0] => 13
[1] => 10
)






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

#37911 [Asn->Csd]: preg_replace_callback ignores named groups

2007-10-07 Thread nlopess

 ID:   37911
 Updated by:   [EMAIL PROTECTED]
 Reported By:  thomas dot kalka at gmail dot com
-Status:   Assigned
+Status:   Closed
 Bug Type: PCRE related
 Operating System: xubuntu
 PHP Version:  5.1.4
 Assigned To:  andrei
 New Comment:

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:


[2006-06-25 21:22:05] thomas dot kalka at gmail dot com

Description:

unfortunately preg_replace_callback does not handle named groups


Reproduce code:
---
blub)|';

function callback($match) { var_dump($match); return '-'; }

preg_replace_callback($regex,'callback',$a);

$m = array(); preg_match($regex,$a,$m); var_dump($m);

?>

Expected result:

array(3) {
  [0]=>
  string(4) "blub"
  ["name"]=>
  string(4) "blub"
  [1]=>
  string(4) "blub"
}
array(3) {
  [0]=>
  string(4) "blub"
  ["name"]=>
  string(4) "blub"
  [1]=>
  string(4) "blub"
}


Actual result:
--
array(2) {
  [0]=>
  string(4) "blub"
  [1]=>
  string(4) "blub"
}
array(3) {
  [0]=>
  string(4) "blub"
  ["name"]=>
  string(4) "blub"
  [1]=>
  string(4) "blub"
}





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

#39016 [Asn->Fbk]: Segfault in preg_replace_impl

2007-10-07 Thread nlopess

 ID:   39016
 Updated by:   [EMAIL PROTECTED]
 Reported By:  jan at horde dot org
-Status:   Assigned
+Status:   Feedback
 Bug Type: PCRE related
 Operating System: Linux
 PHP Version:  5.2.0RC4
 Assigned To:  andrei
 New Comment:

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.

your reproducing script isn't complete (I can't run it..)


Previous Comments:


[2006-10-02 15:58:10] [EMAIL PROTECTED]

Andrei, please take a look at this.
Looks like yet another stack overflow in PCRE..



[2006-10-02 15:51:41] jan at horde dot org

(gdb) p subject
$1 = (zval **) 0xb6f019e0
(gdb) p **subject
Cannot access memory at address 0x1
(gdb) p string_key
$2 = 0x10 
(gdb) p num_key
$3 = 1



[2006-10-02 15:48:34] [EMAIL PROTECTED]

What do you get in GDB with
p subject
p **subject
p string_key
p num_key
?



[2006-10-02 15:41:08] jan at horde dot org

I didn't try a snapshot since this happens with PHP 4, so I guess it's
an older issue that simply hasn't been triggered yet.

Here's the valgrind log:

==32185==  Address 0xBE32 is on thread 1's stack
==32185==
==32185== Invalid read of size 4
==32185==at 0x449FCA7: preg_replace_impl (php_pcre.c:1307)
==32185==by 0x4767B6B: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:200)
==32185==by 0x475AFBC: execute (zend_vm_execute.h:92)
==32185==by 0x47675EA: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)
==32185==by 0x475AFBC: execute (zend_vm_execute.h:92)
==32185==by 0x47675EA: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)
==32185==by 0x475AFBC: execute (zend_vm_execute.h:92)
==32185==by 0x47675EA: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)
==32185==by 0x475AFBC: execute (zend_vm_execute.h:92)
==32185==by 0x47675EA: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)
==32185==by 0x475AFBC: execute (zend_vm_execute.h:92)
==32185==by 0x47675EA: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)
==32185==  Address 0x1 is not stack'd, malloc'd or (recently) free'd
==32185==
==32185== Process terminating with default action of signal 11
(SIGSEGV)
==32185==  Access not within mapped region at address 0x1
==32185==at 0x449FCA7: preg_replace_impl (php_pcre.c:1307)
==32185==by 0x4767B6B: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:200)
==32185==by 0x475AFBC: execute (zend_vm_execute.h:92)
==32185==by 0x47675EA: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)
==32185==by 0x475AFBC: execute (zend_vm_execute.h:92)
==32185==by 0x47675EA: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)
==32185==by 0x475AFBC: execute (zend_vm_execute.h:92)
==32185==by 0x47675EA: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)
==32185==by 0x475AFBC: execute (zend_vm_execute.h:92)
==32185==by 0x47675EA: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)
==32185==by 0x475AFBC: execute (zend_vm_execute.h:92)
==32185==by 0x47675EA: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)



[2006-10-02 15:36:50] jan at horde dot org

I should add the lines of code that caused this, right? :)


$regexp = <

#42847 [Asn->Csd]: gcov support to allow lcov 1.6

2007-10-05 Thread nlopess

 ID:   42847
 Updated by:   [EMAIL PROTECTED]
 Reported By:  philip at roshambo dot org
-Status:   Assigned
+Status:   Closed
 Bug Type: Unknown/Other Function
 Operating System: Mac
 PHP Version:  5.2.4
 Assigned To:  nlopess
 New Comment:

it works now in php 5.2, 5.3 & 6.


Previous Comments:


[2007-10-03 23:22:44] philip at roshambo dot org

Description:

Compiling PHP with gcov support requires lcov from the LTP (Linux Test
Project) installed. Version 1.6 was released 2007-08-22 and PHP says it
won't work (requires 1.5 not 1.6) so this report requests PHP to allow
1.6.

http://sourceforge.net/project/showfiles.php?group_id=3382&package_id=80148


Reproduce code:
---
./configure --enable-gcov

Expected result:

Success

Actual result:
--
...
checking whether to include gcov symbols... yes
checking for lcov... lcov
checking for genhtml... genhtml
checking for ltp version... invalid
configure: error: You must have one of the following versions of LTP:
1.5 (found: 1.6).





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

#42776 [Opn->Fbk]: zend_mm_handler corrupted using mysqli, longtext

2007-09-30 Thread nlopess

 ID:   42776
 Updated by:   [EMAIL PROTECTED]
 Reported By:  asmith at arcstone dot com
-Status:   Open
+Status:   Feedback
 Bug Type: MySQLi related
 Operating System: CentOS 5
 PHP Version:  5.2.4
 New Comment:

you didn't provide the full backtrace. Please read the URL mentioned in
order to provide a useful backtrace. In addition, it would be great if
you could provide a sample script to allow us to reproduce the problem.


Previous Comments:


[2007-09-27 17:10:50] asmith at arcstone dot com

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1213928640 (LWP 24349)]
0xb77b6019 in zend_hash_find (ht=0x1c, arKey=0xbf959700 "closecursor",
nKeyLength=12, pData=0xb251f619)
at /home/brewbuilder/rpms/BUILD/php-5.2.4/Zend/zend_hash.c:878
878 /home/brewbuilder/rpms/BUILD/php-5.2.4/Zend/zend_hash.c: No
such file or directory.
in /home/brewbuilder/rpms/BUILD/php-5.2.4/Zend/zend_hash.c



[2007-09-27 09:45:08] [EMAIL PROTECTED]

Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.





[2007-09-27 07:38:41] asmith at arcstone dot com

Description:

Running with Zend Framework, MySQLi, connecting to database on seperate
dedicated server, CentOS 5, PHP 5.2.4 build from utterramblings
repository. I thought it was my problem or Zend Framework's problem
until I changed the field type from longtext to text.

Reproduce code:
---
create mysql table with longtext field full of anything
connect to table using mysqli
select from that table

Expected result:

the text from the database

Actual result:
--
script execution stops, and the following appears in the apache error
log

[Thu Sep 27 03:04:56 2007] [error] [client 209.98.251.245] PHP Warning:
 Invalid argument supplied for foreach() in
/www/wonderfile/lib/vendor/Zend/Db/Statement/Mysqli.php on line 221,
referer: http://library.wonderfile.net/library/files/upload
zend_mm_heap corrupted
[Thu Sep 27 03:14:26 2007] [notice] child pid 7554 exit signal
Segmentation fault (11)





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

#42787 [Opn->Bgs]: max_execution_time not working

2007-09-30 Thread nlopess

 ID:   42787
 Updated by:   [EMAIL PROTECTED]
 Reported By:  th at domainbox dot de
-Status:   Open
+Status:   Bogus
 Bug Type: Performance problem
 Operating System: Debian Etch
 PHP Version:  4.4.7
 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.

'max_execution_time' really means cpu execution time. sleep() doesnt
consume cpu, so it isn't counted. Anyway, the script won't run forever,
although it may run for a while..


Previous Comments:


[2007-09-28 11:05:59] th at domainbox dot de

Description:

If i start the attached code via .so module in Apache or with "php -f"
it will run forever.


Reproduce code:
---


Expected result:

max_execution_time exceeded

Actual result:
--
Script runs longer than max_excution_time and does not get killed.





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

#39651 [Asn->Csd]: proc_open() descriptor spec for STDOUT append starts writing from beginning

2007-09-12 Thread nlopess

 ID:   39651
 Updated by:   [EMAIL PROTECTED]
 Reported By:  rherror404 at gmail dot com
-Status:   Assigned
+Status:   Closed
 Bug Type: Program Execution
 Operating System: win32 only
-PHP Version:  5? 4? 6?
+PHP Version:  5
 Assigned To:  nlopess
 New Comment:

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.

the append mode is now emulated using a fseek().


Previous Comments:


[2007-09-05 13:53:35] [EMAIL PROTECTED]

Nuno, please check the version field here. It must never be '*' like it
was before I set it to something meaningful. If you can reproduce this
with PHP 5.2.4, set the version to it.



[2007-01-01 15:25:19] [EMAIL PROTECTED]

I do verify the bug, but I wasn't able to fix it.
The problem is that I think windows doesn't support the append mode
when using HANDLEs. So, when we call _get_osfhandle() to convert the fd
to an HANDLE, windows loose this information. (yes, we need to convert
to an handle because CreateProcess() requires it).
I'm leacing open as someone might have some idea (no, I don't know how
to emulate it, as after "forking" we loose the control over the new
process..)



[2006-11-27 23:09:11] [EMAIL PROTECTED]

Not reproducible on Linux.



[2006-11-27 22:49:38] rherror404 at gmail dot com

Description:

Defining the descriptor spec for STDOUT for a call to proc_open() to
append to a file instead starts writing from beginning (not at the end
as one would expect).

C:\WINDOWS\Temp>php launch1.php

Reproduce code:
---
C:\WINDOWS\Temp>type launch1.php
 array("pipe", "r")
, 1 => array("file", 'C:\WINDOWS\TEMP\launch_stdout.txt', "a")
, 2 => array("file", 'C:\WINDOWS\TEMP\launch_stderr.txt', "a")
);
$i = 5; $inputpackage = serialize($i);
$proc = proc_open('php C:\WINDOWS\TEMP\launch2.php', $dspec, $pipes);
if ( is_resource($proc) ) {fwrite($pipes[0], $inputpackage);
fclose($pipes[0]);
proc_close($proc);}
$i = 2; $inputpackage = serialize($i);
$proc = proc_open('php C:\WINDOWS\TEMP\launch2.php', $dspec, $pipes);
if ( is_resource($proc) ) {fwrite($pipes[0], $inputpackage);
fclose($pipes[0]);
proc_close($proc);}
exit();
?>
C:\WINDOWS\Temp>type launch2.php
 $x\r\n";}
$inbuffer = fgets(STDIN, 8192);
$i = unserialize($inbuffer);
for ( $j = 0; $j < $i; $j++ ) {tostdout("$j : $i"); sleep(1);}
exit();
?>
C:\WINDOWS\Temp>

Expected result:

C:\WINDOWS\Temp>type launch_stdout.txt
[2006-11-27 16:33:53 (CST -06:00)]  0 : 5
[2006-11-27 16:33:54 (CST -06:00)]  1 : 5
[2006-11-27 16:33:55 (CST -06:00)]  2 : 5
[2006-11-27 16:33:56 (CST -06:00)]  3 : 5
[2006-11-27 16:33:57 (CST -06:00)]  4 : 5
[2006-11-27 16:33:58 (CST -06:00)]  0 : 2
[2006-11-27 16:33:59 (CST -06:00)]  1 : 2

/*
I would expect the second process to append its output
to (the end of) the output of the first process.
*/

Actual result:
--
C:\WINDOWS\Temp>type launch_stdout.txt
[2006-11-27 16:33:58 (CST -06:00)]  0 : 2
[2006-11-27 16:33:59 (CST -06:00)]  1 : 2
[2006-11-27 16:33:55 (CST -06:00)]  2 : 5
[2006-11-27 16:33:56 (CST -06:00)]  3 : 5
[2006-11-27 16:33:57 (CST -06:00)]  4 : 5

/*
The second process has over-written lines one and two
of the output of the first process.
*/





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

#42586 [Opn->Bgs]: HTML format can't run !

2007-09-07 Thread nlopess

 ID:   42586
 Updated by:   [EMAIL PROTECTED]
 Reported By:  catchybread at hotmail dot com
-Status:   Open
+Status:   Bogus
 Bug Type: Scripting Engine problem
 Operating System: WINDOWS XP PRO
 PHP Version:  5.2.4
 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:


[2007-09-07 13:20:47] catchybread at hotmail dot com

Description:


  WEB SERVER 
  Bug with the directory 
  CLICK 


save as name.php --> Won't work
   but work for
save as name.html








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

#42576 [Opn->Fbk]: stack smashing attack in function php_pcre_compile2

2007-09-07 Thread nlopess

 ID:   42576
 Updated by:   [EMAIL PROTECTED]
 Reported By:  nivedg at gmail dot com
-Status:   Open
+Status:   Feedback
 Bug Type: Apache2 related
 Operating System: Linux 2.4.32
 PHP Version:  4.4.7
 New Comment:

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.

without further info there's little we can do about this.
anyway I would say this is a typical pcre out-of-stack recursion.
#this reminds me I have to upgrade pcre in the php 4 branch..


Previous Comments:


[2007-09-06 12:49:26] nivedg at gmail dot com

Description:

I keep getting this error message in /var/log/httpd/error_log : 

httpd: stack smashing attack in function php_pcre_compile2[Thu Sep 06
04:26:53 2007] [notice] child pid 20857 exit signal A
borted (6)
httpd: stack smashing attack in function php_pcre_compile2[Thu Sep 06
04:26:56 2007] [notice] child pid 20799 exit signal A
borted (6)

Apache version: 2.0.59
Php version: 4.4.7
Extensions used: gd and mysql

I'm using Mambo CMS on this server. Don't know what is causing this
error. 
 







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

#42509 [Asn]: GMP without gmp_init eats memory

2007-09-03 Thread nlopess

 ID:   42509
 Updated by:   [EMAIL PROTECTED]
 Reported By:  thomas dot hebinck at digionline dot de
 Status:   Assigned
 Bug Type: Math related
 Operating System: Linux
 PHP Version:  5.2.4
 Assigned To:  stas
 New Comment:

Stas: what do you think about this patch:
http://web.ist.utl.pt/nuno.lopes/php_gmp_bug42509.txt


Previous Comments:


[2007-09-03 10:47:10] [EMAIL PROTECTED]

[EMAIL PROTECTED] php_5_2]$ sapi/cli/php t.php 
79768
99792024
[EMAIL PROTECTED] php_5_2]$ USE_ZEND_ALLOC=0 sapi/cli/php t.php 
8236
8236




[2007-09-01 17:02:26] thomas dot hebinck at digionline dot de

Description:

Various GMP Functions eat memory, when not called directly with
integers or strings instead of gmp resources.

Reproduce code:
---
$a='1234';
for($i=0;$i<20;$i++) {
  $c=gmp_add(gmp_init($a),gmp_init($a));
}
echo memory_get_usage() . "¶\n";
for($i=0;$i<20;$i++) {
  $c=gmp_add($a,$a);
}
echo memory_get_usage() . "¶\n";


Expected result:

Both memory_get_usage() should show nearly the same values.

Actual result:
--
1732656¶// ~ 2 MB
43809696¶   // ~ 43 MB






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

#42298 [Asn->Csd]: preg_match with /u gives different results for \S\S and \S{2}

2007-09-01 Thread nlopess

 ID:   42298
 Updated by:   [EMAIL PROTECTED]
 Reported By:  matthew-php at dracos dot co dot uk
-Status:   Assigned
+Status:   Closed
 Bug Type: PCRE related
 Operating System: Windows XP
 PHP Version:  5CVS-2007-08-14 (snap)
 Assigned To:  nlopess
 New Comment:

bug fixed in PCRE 7.3.
I've upgraded the bundled PCRE package in php 5.2 and 6 branches.


Previous Comments:


[2007-08-15 09:02:22] [EMAIL PROTECTED]

submited upstream: http://bugs.exim.org/580
I will provide more feedback when I end my vacations.



[2007-08-15 08:43:03] [EMAIL PROTECTED]

Assigned to PCRE maintainer.



[2007-08-14 16:46:48] matthew-php at dracos dot co dot uk

Description:

When using the /u modifier, preg_match, preg_match_all, and
preg_replace all give incorrect results using /\S{2}/u but work fine
with /\S\S/u which should be equivalent.

Reproduce code:
---
$s = "A\xc2\xa3BC";
preg_match_all('/\S\S/u', $s, $m);
print_r($m[0]);
preg_match_all('/\S{2}/u', $s, $m);
print_r($m[0]);


Expected result:

Array
(
[0] => AÂ£
[1] => BC
)
Array
(
[0] => AÂ£
[1] => BC
)


Actual result:
--
Array
(
[0] => AÂ£
[1] => BC
)
Array
(
[0] => A
[1] => 
)






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

#42298 [Asn]: preg_match with /u gives different results for \S\S and \S{2}

2007-08-15 Thread nlopess

 ID:   42298
 Updated by:   [EMAIL PROTECTED]
 Reported By:  matthew-php at dracos dot co dot uk
 Status:   Assigned
 Bug Type: PCRE related
 Operating System: Windows XP
 PHP Version:  5CVS-2007-08-14 (snap)
 Assigned To:  nlopess
 New Comment:

submited upstream: http://bugs.exim.org/580
I will provide more feedback when I end my vacations.


Previous Comments:


[2007-08-15 08:43:03] [EMAIL PROTECTED]

Assigned to PCRE maintainer.



[2007-08-14 16:46:48] matthew-php at dracos dot co dot uk

Description:

When using the /u modifier, preg_match, preg_match_all, and
preg_replace all give incorrect results using /\S{2}/u but work fine
with /\S\S/u which should be equivalent.

Reproduce code:
---
$s = "A\xc2\xa3BC";
preg_match_all('/\S\S/u', $s, $m);
print_r($m[0]);
preg_match_all('/\S{2}/u', $s, $m);
print_r($m[0]);


Expected result:

Array
(
[0] => AÂ£
[1] => BC
)
Array
(
[0] => AÂ£
[1] => BC
)


Actual result:
--
Array
(
[0] => AÂ£
[1] => BC
)
Array
(
[0] => A
[1] => 
)






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

#29521 [Fbk->Asn]: compress.bzip2 wrapper

2007-08-10 Thread nlopess

 ID:   29521
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Assigned
 Bug Type: Bzip2 Related
 Operating System: win32 only
 PHP Version:  5.2CVS-2007-01-10
 Assigned To:  iliaa
 New Comment:

I don't think this has anything to do with that bug. I checked both
filter and wrapper sources and they are too different.


Previous Comments:


[2007-08-05 18:17:43] phofstetter at sensational dot ch

Hi,

being the reporter of bug #42117, I think this really is the same thing
and I actually reported a duplicate (terribly sorry for this), though
"my" bug is about the bzip2.compress *filter* where this is about the
stream *wrapper*, but the bug really feels like being the same problem.

Also, the warning is consistent to what I have seen in my case and to
what the incorrect checking of that error code (see #42117) would
cause.

I'm really having my hopes up that this is going to be fixed now :-)

Philip



[2007-08-04 21:03:19] [EMAIL PROTECTED]

See bug #42117 which might be the same issue. Nuno, can you try the
patch?




[2007-01-12 22:10:27] [EMAIL PROTECTED]

yep, it still issue the same warning.



[2007-01-12 16:45:32] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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





[2005-11-17 19:18:23] [EMAIL PROTECTED]

Warning:
fopen(compress.bzip2://http://pt.php.net/backend/notes/all.bz2): failed
to open stream: Invalid argument in C:\Documents and Settings\Nuno\- on
line 3



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

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

#41973 [Asn->Csd]: Configure fails with LDFLAGS="-Wl,--as-needed"

2007-08-08 Thread nlopess

 ID:   41973
 Updated by:   [EMAIL PROTECTED]
 Reported By:  steffen at hauihau dot de
-Status:   Assigned
+Status:   Closed
 Bug Type: Compile Failure
 Operating System: Gentoo Linux
 PHP Version:  5.2CVS-2007-07-23
 Assigned To:  nlopess
 New Comment:

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:


[2007-07-30 00:01:58] [EMAIL PROTECTED]

Nuno, just commit the patch. I'm too busy. (both HEAD and PHP_5_2)




[2007-07-28 02:40:49] steffen at hauihau dot de

Thanks a lot. configure succeeded with your patch. The following make
also succeeds.

So, do you plan to integrate this patch in the next release of php, or
should I tell the gentoo people maintaining the php ebuild, that they
should integrate this patch in their ebuilds for php?

Regards,
Steffen



[2007-07-25 13:44:39] [EMAIL PROTECTED]

Can you please try this patch:
http://gcov.php.net/~nlopess/ldap_ldflags_patch.txt



[2007-07-24 15:51:08] steffen at hauihau dot de

Thanks a lot for your answer.

I'm wondering, why configure works fine with this flag set when I
invoke it with '--without-ldap'. Every check works, except ldap. When I
manually edit configure and add LIBS="$LIBS -ldap" before the checks for
the first ldap related tests are done (before 'for ac_func in
ldap_parse_result ldap_parse_reference ldap_start_tls_s') it works, and
the following make succeeds.

My knowledge about compiler and linker is not that big. Would it be the
wrong way, to permanently add '-ldap' to $LIBS before the tests for the
ldap related functions are done? You could for example backup $LIBS in
$ac_check_lib_save_LIBS before. This is only an idea, if it's definitely
not possible, to workaround this issue, I will have to file a bug for
this gentoo ebuild and they should discuss about this topic.

Regards,
Steffen



[2007-07-24 15:26:21] [EMAIL PROTECTED]

Of course that flag will cause problems. And it's not something we're
likely to "fix" as we link only with libs that are needed anyways and it
would break every check we do in configure, as you noticed.

Feel free to provide a patch, otherwise: Don't use that flag when
building PHP.



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

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

#41973 [WFx->Fbk]: Configure fails with LDFLAGS="-Wl,--as-needed"

2007-07-25 Thread nlopess

 ID:   41973
 Updated by:   [EMAIL PROTECTED]
 Reported By:  steffen at hauihau dot de
-Status:   Wont fix
+Status:   Feedback
 Bug Type: Compile Failure
 Operating System: Gentoo Linux
 PHP Version:  5.2CVS-2007-07-23
 Assigned To:  jani
 New Comment:

Can you please try this patch:
http://gcov.php.net/~nlopess/ldap_ldflags_patch.txt


Previous Comments:


[2007-07-24 15:51:08] steffen at hauihau dot de

Thanks a lot for your answer.

I'm wondering, why configure works fine with this flag set when I
invoke it with '--without-ldap'. Every check works, except ldap. When I
manually edit configure and add LIBS="$LIBS -ldap" before the checks for
the first ldap related tests are done (before 'for ac_func in
ldap_parse_result ldap_parse_reference ldap_start_tls_s') it works, and
the following make succeeds.

My knowledge about compiler and linker is not that big. Would it be the
wrong way, to permanently add '-ldap' to $LIBS before the tests for the
ldap related functions are done? You could for example backup $LIBS in
$ac_check_lib_save_LIBS before. This is only an idea, if it's definitely
not possible, to workaround this issue, I will have to file a bug for
this gentoo ebuild and they should discuss about this topic.

Regards,
Steffen



[2007-07-24 15:26:21] [EMAIL PROTECTED]

Of course that flag will cause problems. And it's not something we're
likely to "fix" as we link only with libs that are needed anyways and it
would break every check we do in configure, as you noticed.

Feel free to provide a patch, otherwise: Don't use that flag when
building PHP.



[2007-07-16 13:26:13] steffen at hauihau dot de

Sorry for the late answer.

I tried to configure PHP_5_2 CVS (200707161230) and it does also
complain about missing 'ldap_bind_s'.

LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,-znow -Wl,--sort-common -s"
CFLAGS="-march=pentium-m -O2 -msse3 -pipe -fomit-frame-pointer"
CPPFLAGS="-march=pentium-m -O2 -msse3 -pipe -fomit-frame-pointer"

I invoked configure the same way as in my first post. The result is the
same.

I found out, that configure works, if I remove '-Wl,as-needed' from my
LDFLAGS. Is this flag not supported?

Regards
Steffen



[2007-07-12 11:41:18] [EMAIL PROTECTED]

I can not reproduce this with latest PHP_5_2 CVS checkout.
We do not support any 3rd party "ports" either. 

Feel free to reopen this IF you can reproduce it using latest 5.2 CVS
snapshot from http://snaps.php.net/




[2007-07-12 11:31:11] steffen at hauihau dot de

Gentoo has no ebuild for php  5.2.3, so I have to wait, until they
release one. Yes, configure works, if I remove '=shared' from
--with-ldap, but as I think, this is, because '-lldap' is added to $LIBS
in configure when $ext_shared is not true. Removing the '=shared'  is
not pratical because the change will be overriden when the next portage
sync is done.

I searched for the mysql related stuff in configure to see how this is
done, and there, $LIBS is expanded by '-lmysqlclient' before conftest.c
gets compiled (e.g. Checking for mysql_close in -lmysqlclient).

So, I could imagine, that $LIBS should also be expanded with '-lldap'
before the conftests are done. Or am I wrong?

Regards
Steffen



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

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

#38245 [Bgs->Opn]: File Upload Problem When magic_quotes_gpc = On

2007-06-21 Thread nlopess

 ID:   38245
 Updated by:   [EMAIL PROTECTED]
 Reported By:  david at orangegateos dot com
-Status:   Bogus
+Status:   Open
 Bug Type: *General Issues
 Operating System: Windows 2003 and IIS6.0
 PHP Version:  5CVS-2006-07-31 (snap)
 New Comment:

Uhm, I think the filename should only escaped after applying
basename(). I didn't look to the sources to check if that is possible,
though.


Previous Comments:


[2006-08-04 16:07:48] [EMAIL PROTECTED]

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

Actually upon further review it seems that this behavior is 
intended. The filename is supposed to contain just the 
filename, however on Win32 backslash (\) is considered to be a 
directory separator, at it foo\'bar.txt would actually be 
treated as directory foo containing file 'bar.txt.



[2006-07-31 21:51:17] david at orangegateos dot com

I did some rather extensive testing today with many different versions
of PHP.  I used Windows versions of PHP for my testing.  Utilized
versions of PHP 5 were from 5.0.0 to 5.1.4 and versions of PHP 4 from
4.1.0 to 4.4.2.

The result I was looking for was a full, escaped filename to be output
on the page (e.g. David\'s Image.jpg).

Versions that gave the *desired* results were:  4.1.0, 4.1.1, 4.1.2,
4.2.0, 4.2.1, 4.2.3, 4.3.0, 4.3.1, 4.3.2, 4.3.3, 4.3.4, 4.3.5, 4.3.6,
4.3.7, 4.3.8, 4.3.9, 5.0.0, 5.0.1, and 5.0.2.

Versions 4.3.10+ and 5.0.3+ all gave incorrect results.  It is noted in
the ChangeLog that this bug was fixed in PHP versions 4.3.11 and 5.0.4,
but these versions still produce incorrect results.

In the "Handling File Uploads" documentation notes section, some users
report that there are some problems with this feature.  The first
occurrence of this is at
http://us2.php.net/manual/en/features.file-upload.php#60024, and another
appears at http://us2.php.net/manual/en/features.file-upload.php#64087.

The documentation states that $_FILES['userfile']['name'] is "the
original name of the file on the client machine".  Are Windows versions
of PHP supposed to be chopping off the filename if magic_quotes_gpc is
on, or is it supposed to return the full, escaped filename?



[2006-07-28 21:42:14] david at orangegateos dot com

I have just tried the linked version for Windows, and I continue to
receive the same problem.  I used the included php.ini-dist file,
unmodified from the zip file.

However, I do receive the full, escaped filename with 5.0.2, similiar
to what you say you receive with the linked 5.2.

This is on a Windows Server 2003 box with IIS6.0.



[2006-07-28 21:05:46] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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

I've tried it on latest version of PHP 5.2 from CVS and it 
works fine, the full, escaped file name is returned.



[2006-07-28 20:39:45] david at orangegateos dot com

Description:

This problem seems to be related to an older occurrence of the bug
found at http://bugs.php.net/bug.php?id=31398.

The full filename is not passed to the $_FILES[] array when submitting
a file with an apostrophe in the name.

For example:  David's Image.jpg

When uploading this file, everything before and including the
apostrophe is removed so that the following will only show:  s
Image.jpg.

The problem occurs when I am using $_FILES['userfile']['name'] to
retrieve the original filename.

I tried todays CVS, upgrading from 5.1.4.  Also, I have tried PHP
4.4.2 on Windows, and the problem occurs there as well, but not on a
Linux system.  As was suggested in the previous bug report, I tried
5.0.2 and this bug is not reproducible.

Reproduce code:
---
' . $_FILES['userfile']['name'] . ''; ?>








Expected result:

The full name of the file, including the apostrophe:  David's
Image.jpg.

Actual result:
--
The first part of the filename is removed, including the apostrophe. 
Displays:  s Image.jpg.





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

#40419 [NoF->Asn]: Trailing Slash in CGI request don't work

2007-06-21 Thread nlopess

 ID:   40419
 Updated by:   [EMAIL PROTECTED]
 Reported By:  samuele dot diella at gmail dot com
-Status:   No Feedback
+Status:   Assigned
 Bug Type: CGI related
 Operating System: Slackware 10.2
 PHP Version:  5.2.1
 Assigned To:  dmitry
 New Comment:

feedback given.


Previous Comments:


[2007-06-21 10:21:40] bugs at spuetz dot ath dot cx

I tried 5.2.3 and it doesn't work without patch. 

I just created a vhost with unpatched 5.2.3:
http://bug40419.screenwork-dev.de/info.php => works
http://bug40419.screenwork-dev.de/info.php/ => no input...

With patch:
http://www1.screenwork.de/mas/phpinfo.php
http://www1.screenwork.de/mas/phpinfo.php/

Patched with: http://www1.screenwork.de/mas/40419.patch

Do you need anything else?



[2007-05-29 01:00:01] php-bugs at lists dot php dot net

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



[2007-05-21 11:51:49] jankorichter at yahoo dot de

Yes, cgi.fix_pathinfo is set to 1. I have checked it with phpinfo().
But it doesn't work without patch.



[2007-05-21 11:31:04] [EMAIL PROTECTED]

Check that cgi.fix_pathinfo in php.ini is set to 1.

I cannot reproduce the behavior and cannot understand how patch can fix
it.



[2007-05-21 10:45:08] jankorichter at yahoo dot de

SCRIPT_FILENAME fixed.


--- php-5.2.2/sapi/cgi/cgi_main.c   2007-04-17 22:00:53.0
+0200
+++ php-5.2.2.new/sapi/cgi/cgi_main.c   2007-05-21 12:24:31.0
+0200
@@ -961,7 +961,15 @@
/* some server configurations allow '..' to slip
through in the
   translated path.   We'll just refuse to handle such
a path. */
if (script_path_translated &&
!strstr(script_path_translated, "..")) {
-   SG(request_info).path_translated =
estrdup(script_path_translated);
+   char * real_path =
tsrm_realpath(script_path_translated, NULL TSRMLS_CC);
+   if ( real_path )
+   {
+ SG(request_info).path_translated =
estrdup(real_path);
+ script_path_translated =
_sapi_cgibin_putenv("SCRIPT_FILENAME", real_path TSRMLS_CC);
+ free(real_path);
+   } else {
+ SG(request_info).path_translated =
estrdup(script_path_translated);
+}
}
SG(request_info).content_type = (content_type ?
content_type : "" );
SG(request_info).content_length = (content_length ?
atoi(content_length) : 0);



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

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

#41749 [Opn->Bgs]: Reproducible segfault in PCRE lib

2007-06-20 Thread nlopess

 ID:   41749
 Updated by:   [EMAIL PROTECTED]
 Reported By:  joe at emomentum dot co dot uk
-Status:   Open
+Status:   Bogus
 Bug Type: PCRE related
 Operating System: Debian Etch (Debian 4.0 Stable)
 PHP Version:  5.2.0
 New Comment:

We don't use the pcre_dfa_exec() function. There's something wrong
going there. Still this is not a PHP bug.
libpcre 6.7 is really old and you should consider upgrading to libpcre
7.2.
BTW, I couldn't reproduce the problem, albeith with a newer libpcre
version.


Previous Comments:


[2007-06-20 21:06:58] judas dot iscariote at gmail dot com

your code produces stack overflow in the PCRE library and there is
nothing almost nothing that PHP can do to avoid that.



[2007-06-20 14:40:11] joe at emomentum dot co dot uk

Description:

Couldn't see this anywhere else (similar but not close enough).

Located an apparent bug in the PCRE library, although this might be
relating to the way PHP calls the library (I'll post this to the PCRE
list as well).

Reproducable if slightly random crash occurs when using regex's with
certain hex strings on longish (and random) strings.

Weirdly, the length of the string directly relates to the chance of a
segfault, and the segfault only occurs with certain ranges of hex
strings (specifically, ONLY over x7A and ONLY with text strings of
exactly 4843 bytes or longer).

Note that using the regex /^([\x00-\x7A])*$/ causes a segfault, whereas
/^([\x00-\x71])*$/ or /^([\x00-\x79])*$/ does not.

Running on Debian Etch 64bit (amd64) with latest stable PHP and
libpcre3_6.7-1_amd64 installed.

Regards,

Joe Harris
Senior Developer
eMomentum Limited

Reproduce code:
---



Expected result:

int(0)

(false, never going to match a-z random string)

Actual result:
--
Segmentation fault (core dumped)

-

when running in gdb:

This GDB was configured as "x86_64-linux-gnu"...(no debugging symbols
found)
Using host libthread_db library "/lib/libthread_db.so.1".

(gdb) run test.php
Starting program: /usr/bin/php test.php
(no debugging symbols found)
 [snip - lots of these]
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread 47782002024432 (LWP 11134)]
(no debugging symbols found)
 [snip - lots of these]
(no debugging symbols found)
testing a string of 4846 bytes in length
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 47782002024432 (LWP 11134)]
0x2b751be871a8 in pcre_dfa_exec () from /usr/lib/libpcre.so.3






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

#41726 [Opn->Bgs]: Error on system calls (`, popen)

2007-06-19 Thread nlopess

 ID:   41726
 Updated by:   [EMAIL PROTECTED]
 Reported By:  lburger at hu dot tesco-europe dot com
-Status:   Open
+Status:   Bogus
 Bug Type: Reproducible crash
 Operating System: Windows
 PHP Version:  5.2.3
 New Comment:

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

Thank you for your interest in PHP.

yep, its the same problem (I can reproduce it, too).


Previous Comments:


[2007-06-19 07:24:26] lburger at hu dot tesco-europe dot com

You're right. If MySQL extension is removed from php.ini, everything
works fine. Thank you for the link.



[2007-06-18 15:07:48] [EMAIL PROTECTED]

See also bug #41350 (propably unrelated but who knows, it's Windows..)



[2007-06-18 13:00:27] lburger at hu dot tesco-europe dot com

Description:

I use `` or popen, the script will evaluate the whole script then hang
until script time limit expires.
The error kicks in everytime.
The error didn't exist prior to 5.2.3


Reproduce code:
---
Needed:


But happens even:



Expected result:

For both scripts the evaluation should be last less than a second.

Actual result:
--
Scripts hang until script time limit expires and then die with the
following error (seen only when I used command line, not seen if run
from Apache module):

Error in my_thread_global_end(): 1 threads didn't exit





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

#41582 [Csd->Asn]: SimpleXML crashes.

2007-06-18 Thread nlopess

 ID:   41582
 Updated by:   [EMAIL PROTECTED]
 Reported By:  judas dot iscariote at gmail dot com
-Status:   Closed
+Status:   Assigned
 Bug Type: SimpleXML related
 Operating System: Any
 PHP Version:  5CVS-2007-06-04 (CVS)
-Assigned To:  helly
+Assigned To:  dmitry
 New Comment:

Dmitry: new comment added that may need your attention


Previous Comments:


[2007-06-15 06:32:25] judas dot iscariote at gmail dot com

Dmitry, first thanks for taking care of correcting the leak.. however..
now a funny warning is raised !!

$xml->movie[1]->characters->character[]->name = 'Miss Coder';

causes :

Warning: main(): (main ? x_X) 

Cannot add element movie number 1 when only 0 such elements exist
in...(this part is correct though)

that's not so annoying or critical and we can live with it, however
does not look good.

Addtionally I gave this stuff a better test now.. and Im still able to
find some good as well edge/wrong cases where this stuff needs
improvement.

for example:


$xml->movie[2.5]->characters->character[0]->name = '';

leaks memory as well. this is bad code of course ;) however I think
this raises the real issue.. IMHO the code should check if the element
number is >= 0 and an integer (not a float,maybe cast it to integer? and
or emit warning/notice when the wrong type is used...)


other case, that "looks" valid.

// the string '0';
$xml->movie['0']->characters->character[0]->name = '';

leaks memory and emits...
Notice: Indirect modification of overloaded element of SimpleXMLElement
has no effect in .. but 0 as an integer works fine :-)



[2007-06-13 13:53:02] [EMAIL PROTECTED]

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.





[2007-06-06 11:28:56] [EMAIL PROTECTED]

Well, there are some cases which cannot be fixed at all.
Fortunately they only happen when the code is b0rked, so I don't think
it's critical.
Markus, can you think of any solution for the leak?



[2007-06-06 10:53:13] judas dot iscariote at gmail dot com

fix works. but leaks memory in the above situation.

$xml = new SimpleXMLElement('
');

$xml->movie[1]->characters->character[]->name = 'Miss Coder';


Zend/zend_execute.c(1249) :  Freeing 0x00C97DA0 (24 bytes),
script=simplecrashes.php
=== Total 1 memory leaks detected ===



[2007-06-05 10:03:18] [EMAIL PROTECTED]

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.





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

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

#41660 [Asn->Csd]: New file tests fail

2007-06-18 Thread nlopess

 ID:   41660
 Updated by:   [EMAIL PROTECTED]
 Reported By:  uwe dot pries at digartis dot de
-Status:   Assigned
+Status:   Closed
 Bug Type: *Directory/Filesystem functions
 Operating System: Linux 2.6 (ubuntu feisty-fawn)
 PHP Version:  5CVS-2007-06-11 (CVS)
 Assigned To:  johannes
 New Comment:

closing then.


Previous Comments:


[2007-06-18 12:44:26] uwe dot pries at digartis dot de

hey zoe,

after dmitry updated ext/standard/tests/file/readlink_realpath_basic.*
the test runs through now.

thanks again to all

regards
uwe



[2007-06-15 13:45:08] [EMAIL PROTECTED]

Thanks Uwe.

I don't think that anyone can close the bug till someone fixes or
agrees to fix the defect in the engine :-)

When I fix the test case it will pass for you but will fail for
everyone else until the engine bug is fixed.



[2007-06-15 13:01:33] uwe dot pries at digartis dot de

Hello Zoe,

glad to hear you found the problem :-)
I hope I did not keep you from working on other important issues tho
;)=

Please tell me when you commit the new test. I will run it then and
tell you about the state.

Who will close this issue/bug? 
[ ] The developer (zoe)
[ ] The assigner (chinstrap)
[ ] The reporter (uwe)

Thanks & regards
Uwe



[2007-06-15 11:58:47] [EMAIL PROTECTED]

Hi Uwe

I now understand this as far as it's possible for me, the next step is
to get someone more expert to look at it - so I'm summarising and
assigning back to Johannes.

Summary
===

There are two parts to this defect - first the problem with tests being
run as root. I have fixed those test cases.

The second part is with the failing readlink_realpath_variation.phpt
test. This test is failing on Uwe's sytem because he has used the
configure option --enable-maintainer-zts.

There are two problems with readlink_realpath_variation.phpt. First the
test case has been coded incorrectly, it should *pass* with
--enable-maintainer-zts and should *fail* without it. Secondly, there is
a bug in PHP which needs someone fairly expert to look at it.

I will change the test case so that it fails properly instead of
testing for, and passing, incorrect behaviour.

Here is a simple reproduce test case for the failure:

--TEST--
Dump failure result of trying to create non-existant link followed by
realpath() on non-existant link
--FILE--

--EXPECTF--
Warning: symlink(): No such file or directory in %s on line %d
bool(false)
bool(false)

The two important lines are marked by ***. Both of these work correctly
on their own - but not together.




[2007-06-15 09:43:58] [EMAIL PROTECTED]

Hi - don't worry about rebuilding, it's one of 4 options on the
configure command that is making the difference. I can reproduce your
failure.
Zoe



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

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

#41609 [Opn]: file_put_contents() injects \r

2007-06-11 Thread nlopess

 ID:   41609
 Updated by:   [EMAIL PROTECTED]
 Reported By:  zoe at uk dot ibm dot com
 Status:   Open
-Bug Type: Documentation problem
+Bug Type: Filesystem function related
 Operating System: Windows XP
 PHP Version:  6CVS-2007-06-06 (snap)
 New Comment:

"I'm pretty sure that FILE_BINARY solves your issue. It may use it
automatically when a binary string is given, but I would find that
trickier (magic++)"

I don't see that as magical.. If a binary string is given, you want it
writen as-is, IMHO. I'm classifying back to a PHP bug, because I feel
this needs more discussion.


Previous Comments:


[2007-06-11 12:15:56] [EMAIL PROTECTED]

"*IF* there is some work needed on the docs is the right process to
open another defect?"

Good point, there is a lot of work to be done regarding php6 behaviors
of each function. I'm not sure what the phpdoc team decided but I will
let them comment here, if required.

changed to open + documentation problem.





[2007-06-11 11:30:25] zoe at uk dot ibm dot com

Fair enough - I was wondering if it should also be either RTFM or
WTFM?
Just had a quick look at what I hope are the PHP6 docs and I can't see
the new put_file_contents() flags documented yet. *IF* there is some
work needed on the docs is the right process to open another defect?



[2007-06-11 10:58:07] [EMAIL PROTECTED]

Not a bug > bogus (I don't like this word but well :)



[2007-06-11 09:56:24] zoe at uk dot ibm dot com

Yes - you are right. The FILE_BINARY flag does fix the problem. I'm
closing this.



[2007-06-09 21:17:40] [EMAIL PROTECTED]

"when files are not opened with the binary flag, windows automatically
converts \n to \r\n. I don't have time until mid-July to investigate
this problem though."

As far as I remember, it is the documented behavior (windows file
functions).

It is especially important to take care of text contents in the unicode
mode, it is not a good idea to blindly save everything as binary. That's
why php6 has two new flags which can be used in file_put_contents: 
- FILE_TEXT, opens with "wt" (or "at" if FILE_APPEND is used)
- FILE_BINARY, opens with "wb" (or "ab"

the default mode is "w", which is a text mode on windows.

I do not have a windows at hand to test but I'm pretty sure that
FILE_BINARY solves your issue. It may use it automatically when a binary
string is given, but I would find that trickier (magic++).



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

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

#41638 [Opn->Bgs]: Stack overflow in pcre

2007-06-10 Thread nlopess

 ID:   41638
 Updated by:   [EMAIL PROTECTED]
 Reported By:  hirainchen at gmail dot com
-Status:   Open
+Status:   Bogus
 Bug Type: PCRE related
 Operating System: ALL
 PHP Version:  5.2.3
 New Comment:

Sorry, I misread your original regex, but still this isn't a PHP bug.
The problem here is that pcre is hitting the recursion limit with your
regex (while I understand why - nesting of * - I don't think it was
supposed to happen).

Please forward your bug report to the PCRE dev team at:
[EMAIL PROTECTED]


Previous Comments:


[2007-06-10 06:09:18] hirainchen at gmail dot com

to nlopess:

the result of your regex is:
Array
(
[0] => Array
(
[0] => 'loopt'
)

[1] => Array
(
[0] => '
)

[2] => Array
(
[0] => loopt
)

[3] => Array
(
[0] => t
)

[4] => Array
(
[0] =>
)

)

not totally equal the expected result, and my regex is working well
with PHP5.2.1+PCRE 6.7. I google this problem,found many people met the
same kind issue.



[2007-06-09 21:09:18] [EMAIL PROTECTED]

your regex is wrong.
try e.g. this:
preg_match_all('/([\'"])((.*(\1)*)*)\1/sU',$str,$str_instead);



[2007-06-08 18:41:07] hirainchen at gmail dot com

had tried to set as 5000,1000,500 but not helpful



[2007-06-08 18:34:03] [EMAIL PROTECTED]

Looks like stack overflow to me. Happens also on Linux. 
Try setting your limits lower.



[2007-06-08 17:57:22] hirainchen at gmail dot com

Description:

PCRE Library Version => 7.0 18-Dec-2006
this version PCRE seems doesn't work well with PHP.
I met same problem with php5.2.1+PCRE 7.0 in FreeBSD, resolved by
downgrading to PCRE 6.7(blog detail:
http://translate.google.com/translate?u=http%3A%2F%2Fhi.baidu.com%2Frainchen%2Fblog%2Fitem%2Fb6321038cf289bf3b211c7bf.html&langpair=zh%7Cen&hl=en&newwindow=1&ie=UTF-8&oe=UTF-8&prev=%2Flanguage_tools)

I had tried to set php.ini as :
[Pcre]
pcre.backtrack_limit=10
pcre.recursion_limit=10

but not helping

Reproduce code:
---
";
print_r($str_instead);
?>

Expected result:

Array
(
[0] => Array
(
[0] => 'loopt'
)

[1] => Array
(
[0] => '
)

[2] => Array
(
[0] => loopt
)

[3] => Array
(
[0] => loopt
)

[4] => Array
(
[0] =>
)

)

Actual result:
--
Array
(
[0] => Array
(
)

[1] => Array
(
)

[2] => Array
(
)

[3] => Array
(
)

[4] => Array
(
)

)





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

#41626 [Opn->Bgs]: child pid exit signal Illegal instruction

2007-06-09 Thread nlopess

 ID:   41626
 Updated by:   [EMAIL PROTECTED]
 Reported By:  ilya at qubis dot org
-Status:   Open
+Status:   Bogus
 Bug Type: PCRE related
 Operating System: FreeBSD 6.2
 PHP Version:  5.2.3
 New Comment:

that seems to be a problem in stack Operating System limit (which PHP
can't do anything about).
Anyway this bug has nothing to do with PHP. If you feel this is a bug
(at first sight I would say it's not), please contact the PCRE dev team
at: [EMAIL PROTECTED]


Previous Comments:


[2007-06-08 18:29:37] [EMAIL PROTECTED]

I'm using whatever is bundled with PHP - looks like it's 7.0. 
PCRE Library Version => 7.0 18-Dec-2006




[2007-06-08 05:52:07] ilya at qubis dot org

Stas! Are you using PCRE 7.0?



[2007-06-08 01:26:13] [EMAIL PROTECTED]

FWIW, works for me fine on Linux Fedora 6. 



[2007-06-07 21:16:41] ilya at qubis dot org

ok, I've compiled GNU gdb 6.5


backtrace is something like:
===
#0  0x295a9710 in match () /from
usr/local/lib/php/20060613-debug/pcre.so
#1  0x295a98ca in match () from
/usr/local/lib/php/20060613-debug/pcre.so
#2  0x295ab649 in match () from
/usr/local/lib/php/20060613-debug/pcre.so
===
...
after that lines 1 and 2 repeat infinitely.



[2007-06-07 14:38:11] [EMAIL PROTECTED]

>GNU gdb 6.1.1 [FreeBSD]

Try updating GDB.



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

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

#41638 [Opn->Bgs]: Stack overflow in pcre

2007-06-09 Thread nlopess

 ID:   41638
 Updated by:   [EMAIL PROTECTED]
 Reported By:  hirainchen at gmail dot com
-Status:   Open
+Status:   Bogus
 Bug Type: PCRE related
 Operating System: ALL
 PHP Version:  5.2.3
 New Comment:

your regex is wrong.
try e.g. this:
preg_match_all('/([\'"])((.*(\1)*)*)\1/sU',$str,$str_instead);


Previous Comments:


[2007-06-08 18:41:07] hirainchen at gmail dot com

had tried to set as 5000,1000,500 but not helpful



[2007-06-08 18:34:03] [EMAIL PROTECTED]

Looks like stack overflow to me. Happens also on Linux. 
Try setting your limits lower.



[2007-06-08 17:57:22] hirainchen at gmail dot com

Description:

PCRE Library Version => 7.0 18-Dec-2006
this version PCRE seems doesn't work well with PHP.
I met same problem with php5.2.1+PCRE 7.0 in FreeBSD, resolved by
downgrading to PCRE 6.7(blog detail:
http://translate.google.com/translate?u=http%3A%2F%2Fhi.baidu.com%2Frainchen%2Fblog%2Fitem%2Fb6321038cf289bf3b211c7bf.html&langpair=zh%7Cen&hl=en&newwindow=1&ie=UTF-8&oe=UTF-8&prev=%2Flanguage_tools)

I had tried to set php.ini as :
[Pcre]
pcre.backtrack_limit=10
pcre.recursion_limit=10

but not helping

Reproduce code:
---
";
print_r($str_instead);
?>

Expected result:

Array
(
[0] => Array
(
[0] => 'loopt'
)

[1] => Array
(
[0] => '
)

[2] => Array
(
[0] => loopt
)

[3] => Array
(
[0] => loopt
)

[4] => Array
(
[0] =>
)

)

Actual result:
--
Array
(
[0] => Array
(
)

[1] => Array
(
)

[2] => Array
(
)

[3] => Array
(
)

[4] => Array
(
)

)





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

#41609 [Opn]: file_put_contents() injects \r

2007-06-09 Thread nlopess

 ID:   41609
 Updated by:   [EMAIL PROTECTED]
 Reported By:  zoe at uk dot ibm dot com
 Status:   Open
 Bug Type: Filesystem function related
 Operating System: Windows XP
 PHP Version:  6CVS-2007-06-06 (snap)
 New Comment:

when files are not opened with the binary flag, windows automatically
converts \n to \r\n. I don't have time until mid-July to investigate
this problem though.


Previous Comments:


[2007-06-06 10:48:09] zoe at uk dot ibm dot com

Hi Johannes

No, it doesn't:

E:\zoe\TESTS\slashr>e:\zoe\buildsystem\php6exe\php.exe -d
unicode.semantics=0 johannes.php
string(7) "foo
bar"

E:\zoe\TESTS\slashr>e:\zoe\buildsystem\php6exe\php.exe -d
unicode.semantics=1 johannes.php
string(7) "foo
bar"



[2007-06-06 10:26:31] [EMAIL PROTECTED]

I'd assume this is some ICU feature when converting a text with
newlines from UTF-8 to UTF-16 and then back to UTF-8.

Does something like

also show the \r?



[2007-06-06 09:35:57] [EMAIL PROTECTED]

No, thanks. This should be enough for somebody who knows how to debug
it on Windows. 
Unfortunately, I don't.



[2007-06-06 08:56:30] zoe at uk dot ibm dot com

Hi - sorry - I should have mentioned that the behaviour is not
reproducible on Linux. It's Windows specific. Would you like the copies
of the data.tmp files that are created in each case? - if so I'll attach
them to this.



[2007-06-06 08:38:47] [EMAIL PROTECTED]

Could you plz try the same on Linux?
I can't replicate it there.



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

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

#41496 [Asn->Bgs]: Preg_Split returns 3 matches with offset -1

2007-05-28 Thread nlopess

1 2 3 4 5 >

1 - 100 of 410 matches

Mail list logo