from:"tigr at mail15 dot com"

#40846 [Com]: pcre.backtrack_limit too restrictive

2007-05-20 Thread tigr at mail15 dot com

 ID:   40846
 Comment by:   tigr at mail15 dot com
 Reported By:  crisp at xs4all dot nl
 Status:   Open
 Bug Type: Feature/Change Request
 Operating System: all
 PHP Version:  5.2.1
 New Comment:

It is kinda strange: previous versions work pretty nice, swiftly
executing all patterns. And in some situations (as I mentioned before)
increasing recursion and backtrack limits just won't help. I suppose
it's wrong behaviour.

Also, note that examples are pretty short and simple. Increasing both
limits to 1 000 000 does not help - just why?


Previous Comments:


[2007-05-20 10:49:37] [EMAIL PROTECTED]

we simply can't increase recursion limit or we risk segfaulting php.
increase the backtrack limit is also risky, but is much safer (although
regexes with much backtracking are usually not well written). I'll think
more about this..



[2007-05-19 08:32:44] tigr at mail15 dot com

Sorry, little mistake: expected result not 'replaced replaced
replaced', but 'replaced replaced'.

--------

[2007-05-19 06:49:43] tigr at mail15 dot com

For me this new behaviour have broken my templates system. While some
of regexpes where simplified, others could not be done so. In some
situations increasing these numbers of little help. For instance(the
regexp was simplified greatly, in real-life application it is much more
complex):



Expected result - 'replaced replaced replaced'. Actual result -
nothing, NULL returned, preg_last_error() shows that there is
PREG_BACKTRACK_LIMIT_ERROR error. Also increasing backtrack limit leads
to another error, PREG_RECURSION_LIMIT_ERROR. Increasing recursion limit
leads to php hanging up.

Changing first or second asterisk in pattern to plus sign immediately
fixes the problem, but I need it in this way. Also, do you think that
this is a correct behaviour? I thing there is a bug somewhere that way.

However, this works pretty well on php 4.x, 5.x and even at 5.2.1 (at
one of the hosts), but it does not work on my local php5.2.2 on
WinXPsp2.



[2007-03-17 20:16:03] crisp at xs4all dot nl

>Changing the limit doesn't mean removing the limit.
But if you change the default limits to match the defaults limits set
in PCRE internally you won't affect it's behavior compared to previous
versions of PHP where the internal settings in PCRE were not
overridden.

Either that or don't override PCRE's internal settings unless these
directives are explicitly set and enabled in php.ini (at the moment
these directives are commented in the php.ini samples).



[2007-03-17 19:26:36] [EMAIL PROTECTED]

>that way there won't be a compatibility problem with previous
>versions of PHP as we have now.
Changing the limit doesn't mean removing the limit.



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

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

#40846 [Com]: pcre.backtrack_limit too restrictive

2007-05-19 Thread tigr at mail15 dot com

 ID:   40846
 Comment by:   tigr at mail15 dot com
 Reported By:  crisp at xs4all dot nl
 Status:   Open
 Bug Type: Feature/Change Request
 Operating System: all
 PHP Version:  5.2.1
 New Comment:

Sorry, little mistake: expected result not 'replaced replaced
replaced', but 'replaced replaced'.


Previous Comments:


[2007-05-19 06:49:43] tigr at mail15 dot com

For me this new behaviour have broken my templates system. While some
of regexpes where simplified, others could not be done so. In some
situations increasing these numbers of little help. For instance(the
regexp was simplified greatly, in real-life application it is much more
complex):



Expected result - 'replaced replaced replaced'. Actual result -
nothing, NULL returned, preg_last_error() shows that there is
PREG_BACKTRACK_LIMIT_ERROR error. Also increasing backtrack limit leads
to another error, PREG_RECURSION_LIMIT_ERROR. Increasing recursion limit
leads to php hanging up.

Changing first or second asterisk in pattern to plus sign immediately
fixes the problem, but I need it in this way. Also, do you think that
this is a correct behaviour? I thing there is a bug somewhere that way.

However, this works pretty well on php 4.x, 5.x and even at 5.2.1 (at
one of the hosts), but it does not work on my local php5.2.2 on
WinXPsp2.



[2007-03-17 20:16:03] crisp at xs4all dot nl

>Changing the limit doesn't mean removing the limit.
But if you change the default limits to match the defaults limits set
in PCRE internally you won't affect it's behavior compared to previous
versions of PHP where the internal settings in PCRE were not
overridden.

Either that or don't override PCRE's internal settings unless these
directives are explicitly set and enabled in php.ini (at the moment
these directives are commented in the php.ini samples).



[2007-03-17 19:26:36] [EMAIL PROTECTED]

>that way there won't be a compatibility problem with previous
>versions of PHP as we have now.
Changing the limit doesn't mean removing the limit.



[2007-03-17 19:19:57] crisp at xs4all dot nl

Description:

The new pcre.backtrack_limit configuration directive is by default too
restrictive (100.000) which results in failure of many - often quite
simple - regular expressions.

I take it that this directive overrules the default setting for
MATCH_LIMIT in PCRE which will also imply that the naming of this
directive is wrong since MATCH_LIMIT is for every match() call in PCRE,
not only those for backtracking.

It would make more sense to change the default of both
pcre.backtrack_limit and pcre.recursion_limit to the ones that PCRE
itself also supplies (10.000.000 for both) - that way there won't be a
compatibility problem with previous versions of PHP as we have now.

Reproduce code:
---
$a = 'baab' . str_repeat('a', 100024);
$b = preg_replace('/b.*b/', '', $a);

Expected result:

I would expect $b to contain 100024 times 'a'

Actual result:
--
$b is a nullpointer, preg_last_error() reports '2' which is
PREG_BACKTRACK_LIMIT_ERROR





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

#40846 [Com]: pcre.backtrack_limit too restrictive

2007-05-18 Thread tigr at mail15 dot com

 ID:   40846
 Comment by:   tigr at mail15 dot com
 Reported By:  crisp at xs4all dot nl
 Status:   Open
 Bug Type: Feature/Change Request
 Operating System: all
 PHP Version:  5.2.1
 New Comment:

For me this new behaviour have broken my templates system. While some
of regexpes where simplified, others could not be done so. In some
situations increasing these numbers of little help. For instance(the
regexp was simplified greatly, in real-life application it is much more
complex):



Expected result - 'replaced replaced replaced'. Actual result -
nothing, NULL returned, preg_last_error() shows that there is
PREG_BACKTRACK_LIMIT_ERROR error. Also increasing backtrack limit leads
to another error, PREG_RECURSION_LIMIT_ERROR. Increasing recursion limit
leads to php hanging up.

Changing first or second asterisk in pattern to plus sign immediately
fixes the problem, but I need it in this way. Also, do you think that
this is a correct behaviour? I thing there is a bug somewhere that way.

However, this works pretty well on php 4.x, 5.x and even at 5.2.1 (at
one of the hosts), but it does not work on my local php5.2.2 on
WinXPsp2.


Previous Comments:


[2007-03-17 20:16:03] crisp at xs4all dot nl

>Changing the limit doesn't mean removing the limit.
But if you change the default limits to match the defaults limits set
in PCRE internally you won't affect it's behavior compared to previous
versions of PHP where the internal settings in PCRE were not
overridden.

Either that or don't override PCRE's internal settings unless these
directives are explicitly set and enabled in php.ini (at the moment
these directives are commented in the php.ini samples).



[2007-03-17 19:26:36] [EMAIL PROTECTED]

>that way there won't be a compatibility problem with previous
>versions of PHP as we have now.
Changing the limit doesn't mean removing the limit.



[2007-03-17 19:19:57] crisp at xs4all dot nl

Description:

The new pcre.backtrack_limit configuration directive is by default too
restrictive (100.000) which results in failure of many - often quite
simple - regular expressions.

I take it that this directive overrules the default setting for
MATCH_LIMIT in PCRE which will also imply that the naming of this
directive is wrong since MATCH_LIMIT is for every match() call in PCRE,
not only those for backtracking.

It would make more sense to change the default of both
pcre.backtrack_limit and pcre.recursion_limit to the ones that PCRE
itself also supplies (10.000.000 for both) - that way there won't be a
compatibility problem with previous versions of PHP as we have now.

Reproduce code:
---
$a = 'baab' . str_repeat('a', 100024);
$b = preg_replace('/b.*b/', '', $a);

Expected result:

I would expect $b to contain 100024 times 'a'

Actual result:
--
$b is a nullpointer, preg_last_error() reports '2' which is
PREG_BACKTRACK_LIMIT_ERROR





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

#32137 [Fbk->Opn]: Objects are not being passed by reference

2005-04-12 Thread tigr at mail15 dot com

 ID:   32137
 User updated by:  tigr at mail15 dot com
 Reported By:  tigr at mail15 dot com
-Status:   Feedback
+Status:   Open
 Bug Type: Zend Engine 2 problem
 Operating System: Windows 98
 PHP Version:  5.0.3
 New Comment:

Checked on these snaps, no changes.

Well, maybe this is due to incorrect understanding of what object
passing by reference means? Maybe this is a documentation problem?

I've added detailed explanation here:
http://www.php.net/manual/en/language.oop5.basic.php


Previous Comments:


[2005-02-28 20:42:40] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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





[2005-02-28 20:39:29] tigr at mail15 dot com

Description:

I make one object instance. Then, pass it to another object. Then,
change original instance. Now I have two different objects.

Reproduce code:
---
id = $id;
}
}
class classB {
public $reference = null;
public function __construct($ref) {
$this->reference = $ref;
}
}
$a = new classA("object 1");
$test = new classB($a);
$a = new classA("object 2");
echo $a->id, "", $test->reference->id;
?>

Expected result:

object 2
object 2

Actual result:
--
object 2
object 1

However, adding references solves the problem:

class classB {
public $reference = null;
public function __construct(&$ref) {
$this->reference =& $ref;
}
}

This works as expected.

So, the question is are objects being passed by reference or what?





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

#32137 [NEW]: Objects are not being passed by reference

2005-02-28 Thread tigr at mail15 dot com

From: tigr at mail15 dot com
Operating system: Windows 98
PHP version:  5.0.3
PHP Bug Type: Zend Engine 2 problem
Bug description:  Objects are not being passed by reference

Description:

I make one object instance. Then, pass it to another object. Then, change
original instance. Now I have two different objects.

Reproduce code:
---
id = $id;
}
}
class classB {
public $reference = null;
public function __construct($ref) {
$this->reference = $ref;
}
}
$a = new classA("object 1");
$test = new classB($a);
$a = new classA("object 2");
echo $a->id, "", $test->reference->id;
?>

Expected result:

object 2
object 2

Actual result:
--
object 2
object 1

However, adding references solves the problem:

class classB {
public $reference = null;
public function __construct(&$ref) {
$this->reference =& $ref;
}
}

This works as expected.

So, the question is are objects being passed by reference or what?

-- 
Edit bug report at http://bugs.php.net/?id=32137&edit=1
-- 
Try a CVS snapshot (php4):   http://bugs.php.net/fix.php?id=32137&r=trysnapshot4
Try a CVS snapshot (php5.0): 
http://bugs.php.net/fix.php?id=32137&r=trysnapshot50
Try a CVS snapshot (php5.1): 
http://bugs.php.net/fix.php?id=32137&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=32137&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=32137&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=32137&r=needtrace
Need Reproduce Script:   http://bugs.php.net/fix.php?id=32137&r=needscript
Try newer version:   http://bugs.php.net/fix.php?id=32137&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=32137&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=32137&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=32137&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=32137&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=32137&r=globals
PHP 3 support discontinued:  http://bugs.php.net/fix.php?id=32137&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=32137&r=dst
IIS Stability:   http://bugs.php.net/fix.php?id=32137&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=32137&r=gnused
Floating point limitations:  http://bugs.php.net/fix.php?id=32137&r=float
No Zend Extensions:  http://bugs.php.net/fix.php?id=32137&r=nozend
MySQL Configuration Error:   http://bugs.php.net/fix.php?id=32137&r=mysqlcfg

#30535 [Com]: Array union (+) doesn't handle array properly

2005-01-29 Thread tigr at mail15 dot com

 ID:   30535
 Comment by:   tigr at mail15 dot com
 Reported By:  smadeira at zoominternet dot net
 Status:   No Feedback
 Bug Type: Arrays related
 Operating System: Linux 2.4.20-8
 PHP Version:  4.3.9
 New Comment:

FreeBSD 4.8-STABLE/php4.3.10/Zend Optimizer v2.5.7 (optimization passes
1 through 4 enabled)
The same here.


Previous Comments:


[2004-12-23 16:28:40] garak at studenti dot it

I experience the same problem, with both PHP 4.3.9 and 4.3.10 and Zend
Optimizer 2.5.6 (under Linux)



[2004-10-31 01:00:12] 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".



[2004-10-23 13:12:58] [EMAIL PROTECTED]

I bet it's a zend optimizer related problem, you could try to install
that on your windows machine and see if the problem occurs then?



[2004-10-23 13:08:42] smadeira at zoominternet dot net

I don't have the ability to run a Linux snapshot since the account is
hosted.  I loaded the code here:
http://kidsportsoftware.com/datebug.php so you can see it in action. 
You can also run phpinfo from here as:
http://kidsportsoftware.com/phpinfo.php to see how the hosting account
is configured.

I tried a Windows snapshot (4.3.10-dev) and it does work properly on
Windows.



[2004-10-23 08:22:44] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip

Can't reproduce - your code produces the very expected result (tried
all dev versions).



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

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

#40846 [Com]: pcre.backtrack_limit too restrictive

#40846 [Com]: pcre.backtrack_limit too restrictive

#40846 [Com]: pcre.backtrack_limit too restrictive

#32137 [Fbk->Opn]: Objects are not being passed by reference

#32137 [NEW]: Objects are not being passed by reference

#30535 [Com]: Array union (+) doesn't handle array properly

6 matches

Site Navigation

Mail list logo

Footer information