#31965 [NEW]: PREG_SPLIT_NO_EMPTY strips non-empty pieces in some cases
From: mikael at SPAMMENOTchl dot chalmers dot se
Operating system: Linux
PHP version: 4.3.8
PHP Bug Type: *Regular Expressions
Bug description: PREG_SPLIT_NO_EMPTY strips non-empty pieces in some cases
Description:
In some cases the preg_split strips non-empty pieces when the
PREG_SPLIT_NO_EMPTY flag i set. Specifically when using assertions only to
split on, eg. the string to split on itself is actually empty (but not the
pieces)
Reproduce code:
---
$terms = preg_split('/(?=\d)(?=[a-zåäö])/', 'ser1ia456l', 0,
PREG_SPLIT_NO_EMPTY);
print_r($terms);
Expected result:
Array
(
[0] = ser1
[1] = ia456
[2] = l
)
Actual result:
--
Array
(
[0] = ser1
[1] = ia456
)
--
Edit bug report at http://bugs.php.net/?id=31965edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31965r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=31965r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=31965r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=31965r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=31965r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=31965r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=31965r=needscript
Try newer version: http://bugs.php.net/fix.php?id=31965r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=31965r=support
Expected behavior: http://bugs.php.net/fix.php?id=31965r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=31965r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=31965r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=31965r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31965r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=31965r=dst
IIS Stability: http://bugs.php.net/fix.php?id=31965r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=31965r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=31965r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=31965r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=31965r=mysqlcfg
#30074 [Com]: apparent symbol table error with extract($blah, EXTR_REFS)
ID: 30074
Comment by: mikael at SPAMMENOTchl dot chalmers dot se
Reported By: owen dot beresford at murphx dot com
Status: Open
Bug Type: Scripting Engine problem
Operating System: linux
PHP Version: 5.0.1
New Comment:
I belive this bug was introduced in PHP 4.3.10, it would seem that when
doing EXTR_REFS $a in the example below isn't
SEPARATE_ZVAL_TO_MAKE_IS_REF or something when being extracted from the
array.
Reproduce code:
$a = 1; $b = 1;
$arr = array('acopy' = $a, 'bref' = $b);
extract($arr, EXTR_REFS);
$acopy++;
$bref++;
debug_zval_dump($a, $b, $arr, $acopy, $bref);
Expected result (As seen on PHP 4.3.10):
$a: long(1) refcount(2)
$b: long(2) refcount(1)
$arr: array(2) refcount(2){
[acopy]=
long(2) refcount(2)
[bref]=
long(2) refcount(3)
}
$acopy: long(2) refcount(1)
$bref: long(2) refcount(1)
Actual result:
--
$a: long(2) refcount(1)
$b: long(2) refcount(1)
$arr: array(2) refcount(2){
[acopy]=
long(2) refcount(3)
[bref]=
long(2) refcount(3)
}
$acopy: long(2) refcount(1)
$bref: long(2) refcount(1)
Previous Comments:
[2004-11-28 16:34:08] [EMAIL PROTECTED]
Reduced reproduce code looks like this:
?php
$result = extract(array('a'=1, 'b'=$foo), EXTR_REFS);
//extract(array('a'=1, 'b'=$foo), EXTR_REFS); // they are not the
same
var_dump(array($b));
?
[2004-09-14 11:10:56] owen dot beresford at murphx dot com
I have noticed my code output has the wrong indexes.
the expected out put should read index 0 and index 1 not index 'a',
index 'b'
bug still present
[2004-09-13 15:47:40] owen dot beresford at murphx dot com
Description:
PHP 5.0.1 (cli) (built: Aug 16 2004 23:07:06),
linux, rh7.3, kernel2.4, libc-2.2.5
The extract function seems incomplete/ broken.
I have a code base which uses arguments arrays, like perl.
Inorder to alter varaibles inside the parameter array in a convient
fashion, I extract the variables at the top of the methods.
Some of the boundary cases don't perform correctly. I have NOT
experienced this under other releases of php, so assume the problem is
induced by the new zend engine.
I am assuming that php 5.0.1 includes prevous fixes for errors reported
against php 4.3.8 and php 5.0.0 (there are closed cases with similar
problems).
This is a small simple case, there are other failures, but this would
exceed the twenty line limit. will post an URL with full senario
The described output ommited some of the english statements for
brevity.
I have not tested this under other operating systems, but this is not a
platform dependant function (well it shouldn't be), and I don't have any
to hand.
in the interests of thoroughness:
Configure Command = './configure' '--prefix=/usr'
'--with-config-file-path=/etc' '--enable-cli' '--disable-cgi'
'--without-pear' '--enable-force-cgi-redirect'
'--with-exec-dir=/usr/bin' '--with-mysql' '--with-curl=/usr/local/lib'
'--with-zlib' '--enable-sockets' '--with-openssl' '--enable-pcntl'
'--enable-libxml' '--enable-shared'
Reproduce code:
---
function x($args) {
$count =extract($args, EXTR_REFS);
echo(inside function x()\n$count items\n);
$count+=10;
echo(altered count to $count\n);
var_dump(array($a, $b));
}
echo(before function x() (second is a null)\n);
$a=array('a'=1, 'b'=NULL);
var_dump($a);
x($a);
echo(before function x() (second is undefined variable)\n);
$d=array('a'=1, 'b'=NULL);
$e=array('a'=1, 'b'=$d['d']);
var_dump($e);
x($e);
Expected result:
array(2) {
[a]=
int(1)
[b]=
NULL
}
array(2) {
[a]=
int(1)
[b]=
NULL
}
Actual result:
--
array(2) {
[0]=
int(1)
[1]=
NULL
}
array(2) {
[0]=
int(1)
[1]=
int(12)
}
--
Edit this bug report at http://bugs.php.net/?id=30074edit=1
#30074 [Com]: apparent symbol table error with extract($blah, EXTR_REFS)
ID: 30074
Comment by: mikael at SPAMMENOTchl dot chalmers dot se
Reported By: owen dot beresford at murphx dot com
Status: Open
Bug Type: Scripting Engine problem
Operating System: linux
PHP Version: 5.0.1
New Comment:
My bad, seems it was actually introduced in 4.3.9 by the fix for bug
#29493. Then the question is; if it is a feature or a bug, it certainly
breaks a lot of old unit tests/code for me.
Previous Comments:
[2004-12-20 22:09:23] mikael at SPAMMENOTchl dot chalmers dot se
That should read I belive this bug was backported into PHP 4.3.10, it
seems to be present in the newly released 4.3.10 but not in 4.3.9
[2004-12-20 22:07:41] mikael at SPAMMENOTchl dot chalmers dot se
I belive this bug was introduced in PHP 4.3.10, it would seem that when
doing EXTR_REFS $a in the example below isn't
SEPARATE_ZVAL_TO_MAKE_IS_REF or something when being extracted from the
array.
Reproduce code:
$a = 1; $b = 1;
$arr = array('acopy' = $a, 'bref' = $b);
extract($arr, EXTR_REFS);
$acopy++;
$bref++;
debug_zval_dump($a, $b, $arr, $acopy, $bref);
Expected result (As seen on PHP 4.3.10):
$a: long(1) refcount(2)
$b: long(2) refcount(1)
$arr: array(2) refcount(2){
[acopy]=
long(2) refcount(2)
[bref]=
long(2) refcount(3)
}
$acopy: long(2) refcount(1)
$bref: long(2) refcount(1)
Actual result:
--
$a: long(2) refcount(1)
$b: long(2) refcount(1)
$arr: array(2) refcount(2){
[acopy]=
long(2) refcount(3)
[bref]=
long(2) refcount(3)
}
$acopy: long(2) refcount(1)
$bref: long(2) refcount(1)
[2004-11-28 16:34:08] [EMAIL PROTECTED]
Reduced reproduce code looks like this:
?php
$result = extract(array('a'=1, 'b'=$foo), EXTR_REFS);
//extract(array('a'=1, 'b'=$foo), EXTR_REFS); // they are not the
same
var_dump(array($b));
?
[2004-09-14 11:10:56] owen dot beresford at murphx dot com
I have noticed my code output has the wrong indexes.
the expected out put should read index 0 and index 1 not index 'a',
index 'b'
bug still present
[2004-09-13 15:47:40] owen dot beresford at murphx dot com
Description:
PHP 5.0.1 (cli) (built: Aug 16 2004 23:07:06),
linux, rh7.3, kernel2.4, libc-2.2.5
The extract function seems incomplete/ broken.
I have a code base which uses arguments arrays, like perl.
Inorder to alter varaibles inside the parameter array in a convient
fashion, I extract the variables at the top of the methods.
Some of the boundary cases don't perform correctly. I have NOT
experienced this under other releases of php, so assume the problem is
induced by the new zend engine.
I am assuming that php 5.0.1 includes prevous fixes for errors reported
against php 4.3.8 and php 5.0.0 (there are closed cases with similar
problems).
This is a small simple case, there are other failures, but this would
exceed the twenty line limit. will post an URL with full senario
The described output ommited some of the english statements for
brevity.
I have not tested this under other operating systems, but this is not a
platform dependant function (well it shouldn't be), and I don't have any
to hand.
in the interests of thoroughness:
Configure Command = './configure' '--prefix=/usr'
'--with-config-file-path=/etc' '--enable-cli' '--disable-cgi'
'--without-pear' '--enable-force-cgi-redirect'
'--with-exec-dir=/usr/bin' '--with-mysql' '--with-curl=/usr/local/lib'
'--with-zlib' '--enable-sockets' '--with-openssl' '--enable-pcntl'
'--enable-libxml' '--enable-shared'
Reproduce code:
---
function x($args) {
$count =extract($args, EXTR_REFS);
echo(inside function x()\n$count items\n);
$count+=10;
echo(altered count to $count\n);
var_dump(array($a, $b));
}
echo(before function x() (second is a null)\n);
$a=array('a'=1, 'b'=NULL);
var_dump($a);
x($a);
echo(before function x() (second is undefined variable)\n);
$d=array('a'=1, 'b'=NULL);
$e=array('a'=1, 'b'=$d['d']);
var_dump($e);
x($e);
Expected result:
array(2) {
[a]=
int(1)
[b]=
NULL
}
array(2) {
[a]=
int(1)
[b]=
NULL
}
Actual result:
--
array(2) {
[0]=
int(1)
[1]=
NULL
}
array(2) {
[0]=
int(1)
[1]=
int(12)
}
--
Edit this bug report at http://bugs.php.net/?id=30074edit=1
#31213 [NEW]: Fix for #29493 seem to have caused other errors
From: mikael at SPAMMENOTchl dot chalmers dot se
Operating system: Linux
PHP version: 4.3.9
PHP Bug Type: Arrays related
Bug description: Fix for #29493 seem to have caused other errors
Description:
In regard to bug #29493 (would have added a comment to it if I could)
--
This fix seems to have been backported to PHP 4.3.9, now we get other
errors.
In the example below $acopy is a reference to $arr['acopy'] and $a is also
a reference to $arr['acopy'], when actually $a should have been separated
from $arr['acopy'] when extract() makes the $acopy reference to
$arr['acopy'] since the array is created with 'acopy' = $a
$b, $arr['bref'] and $bref should and does however all point to the same
value as they should since the array is created with 'bref' = $b
Reproduce code:
Reproduce code:
---
$a = 1; $b = 1;
$arr = array('acopy' = $a, 'bref' = $b);
extract($arr, EXTR_REFS);
$acopy++;
$bref++;
debug_zval_dump($a, $b, $arr, $acopy, $bref);
Expected result:
(As seen on PHP 4.3.9):
$a: long(1) refcount(2)
$b: long(2) refcount(1)
$arr: array(2) refcount(2){
[acopy]=
long(2) refcount(2)
[bref]=
long(2) refcount(3)
}
$acopy: long(2) refcount(1)
$bref: long(2) refcount(1)
Note: Shouldn't the refcount of $a be == 1 instead of 2. $a should be a
separate zval while $arr['acopy'] and $acopy should be references to the
same value as indicated by the refcount of 2
Actual result:
--
$a is now == 2, when it should be == 1. Only $arr['acopy'] should be == 2
$a: long(2) refcount(1)
$b: long(2) refcount(1)
$arr: array(2) refcount(2){
[acopy]=
long(2) refcount(3)
[bref]=
long(2) refcount(3)
}
$acopy: long(2) refcount(1)
$bref: long(2) refcount(1)
--
Edit bug report at http://bugs.php.net/?id=31213edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31213r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=31213r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=31213r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=31213r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=31213r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=31213r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=31213r=needscript
Try newer version: http://bugs.php.net/fix.php?id=31213r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=31213r=support
Expected behavior: http://bugs.php.net/fix.php?id=31213r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=31213r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=31213r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=31213r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31213r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=31213r=dst
IIS Stability: http://bugs.php.net/fix.php?id=31213r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=31213r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=31213r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=31213r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=31213r=mysqlcfg
#30074 [Com]: apparent symbol table error with extract($blah, EXTR_REFS)
ID: 30074
Comment by: mikael at SPAMMENOTchl dot chalmers dot se
Reported By: owen dot beresford at murphx dot com
Status: Open
Bug Type: Scripting Engine problem
Operating System: linux
PHP Version: 5.0.1
New Comment:
That should read I belive this bug was backported into PHP 4.3.10, it
seems to be present in the newly released 4.3.10 but not in 4.3.9
Previous Comments:
[2004-12-20 22:07:41] mikael at SPAMMENOTchl dot chalmers dot se
I belive this bug was introduced in PHP 4.3.10, it would seem that when
doing EXTR_REFS $a in the example below isn't
SEPARATE_ZVAL_TO_MAKE_IS_REF or something when being extracted from the
array.
Reproduce code:
$a = 1; $b = 1;
$arr = array('acopy' = $a, 'bref' = $b);
extract($arr, EXTR_REFS);
$acopy++;
$bref++;
debug_zval_dump($a, $b, $arr, $acopy, $bref);
Expected result (As seen on PHP 4.3.10):
$a: long(1) refcount(2)
$b: long(2) refcount(1)
$arr: array(2) refcount(2){
[acopy]=
long(2) refcount(2)
[bref]=
long(2) refcount(3)
}
$acopy: long(2) refcount(1)
$bref: long(2) refcount(1)
Actual result:
--
$a: long(2) refcount(1)
$b: long(2) refcount(1)
$arr: array(2) refcount(2){
[acopy]=
long(2) refcount(3)
[bref]=
long(2) refcount(3)
}
$acopy: long(2) refcount(1)
$bref: long(2) refcount(1)
[2004-11-28 16:34:08] [EMAIL PROTECTED]
Reduced reproduce code looks like this:
?php
$result = extract(array('a'=1, 'b'=$foo), EXTR_REFS);
//extract(array('a'=1, 'b'=$foo), EXTR_REFS); // they are not the
same
var_dump(array($b));
?
[2004-09-14 11:10:56] owen dot beresford at murphx dot com
I have noticed my code output has the wrong indexes.
the expected out put should read index 0 and index 1 not index 'a',
index 'b'
bug still present
[2004-09-13 15:47:40] owen dot beresford at murphx dot com
Description:
PHP 5.0.1 (cli) (built: Aug 16 2004 23:07:06),
linux, rh7.3, kernel2.4, libc-2.2.5
The extract function seems incomplete/ broken.
I have a code base which uses arguments arrays, like perl.
Inorder to alter varaibles inside the parameter array in a convient
fashion, I extract the variables at the top of the methods.
Some of the boundary cases don't perform correctly. I have NOT
experienced this under other releases of php, so assume the problem is
induced by the new zend engine.
I am assuming that php 5.0.1 includes prevous fixes for errors reported
against php 4.3.8 and php 5.0.0 (there are closed cases with similar
problems).
This is a small simple case, there are other failures, but this would
exceed the twenty line limit. will post an URL with full senario
The described output ommited some of the english statements for
brevity.
I have not tested this under other operating systems, but this is not a
platform dependant function (well it shouldn't be), and I don't have any
to hand.
in the interests of thoroughness:
Configure Command = './configure' '--prefix=/usr'
'--with-config-file-path=/etc' '--enable-cli' '--disable-cgi'
'--without-pear' '--enable-force-cgi-redirect'
'--with-exec-dir=/usr/bin' '--with-mysql' '--with-curl=/usr/local/lib'
'--with-zlib' '--enable-sockets' '--with-openssl' '--enable-pcntl'
'--enable-libxml' '--enable-shared'
Reproduce code:
---
function x($args) {
$count =extract($args, EXTR_REFS);
echo(inside function x()\n$count items\n);
$count+=10;
echo(altered count to $count\n);
var_dump(array($a, $b));
}
echo(before function x() (second is a null)\n);
$a=array('a'=1, 'b'=NULL);
var_dump($a);
x($a);
echo(before function x() (second is undefined variable)\n);
$d=array('a'=1, 'b'=NULL);
$e=array('a'=1, 'b'=$d['d']);
var_dump($e);
x($e);
Expected result:
array(2) {
[a]=
int(1)
[b]=
NULL
}
array(2) {
[a]=
int(1)
[b]=
NULL
}
Actual result:
--
array(2) {
[0]=
int(1)
[1]=
NULL
}
array(2) {
[0]=
int(1)
[1]=
int(12)
}
--
Edit this bug report at http://bugs.php.net/?id=30074edit=1
#25274 [Com]: zvals refcount allways 1 after leavinf __wakeup()-method
ID: 25274
Comment by: mikael at SPAMMENOTchl dot chalmers dot se
Reported By: [EMAIL PROTECTED]
Status: No Feedback
Bug Type: Zend Engine 2 problem
Operating System: linux
PHP Version: 5CVS-2003-11-29
New Comment:
More like bug #29423
This issue popped up in PHP 4.3.10, code that worked fine with previous
releases started segfaulting when doing things like:
function __wakeup() {
global $a;
$a[] = $this;
}
Previous Comments:
[2003-12-04 02:24:21] [EMAIL PROTECTED]
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to Open. Thank you.
[2003-11-28 20:42:36] [EMAIL PROTECTED]
See also bug #25975, isn't this pretty much same issue?
[2003-08-28 09:48:29] [EMAIL PROTECTED]
ZE2 problem, can't reproduce with PHP 4.3.3.
[2003-08-28 08:17:52] [EMAIL PROTECTED]
after commenting out line 2543 of Zend/zend_execute.c the bug seems to
be fixed.. but i have no idea if that solution induces more other
problems...
[2003-08-27 10:12:42] [EMAIL PROTECTED]
Description:
Its mainly an internal problem...
if i use zval_add_ref(getThis()); in the __wakeup() method
it will be ignored at all... after unserializing the refcount of my
object is allways set to 1 :(
its reproduceable even through this php-code:
Reproduce code:
---
?php
$a=array();
class x {
function __wakeup() {
global $a;
$a[]=$this;
}
}
$t=new x();
var_dump($t);
$t=unserialize(serialize($t));
unset($a);
var_dump($t);
?
Expected result:
object(x)#1 (0) {
}
object(x)#1 (0) {
}
Actual result:
--
object(x)#1 (0) {
}
UNKNOWN:0
or:
object(x)#1 (0) { }
Fatal error: Trying to access invalid object in ... on line 15
--
Edit this bug report at http://bugs.php.net/?id=25274edit=1
