#28461 [Sus]: segmentation fault when using backreferences on a long string
ID: 28461
User updated by: xanthor at xanthor dot tk
Reported By: xanthor at xanthor dot tk
Status: Suspended
Bug Type: PCRE related
Operating System: *
PHP Version: 4.4.1
Assigned To: andrei
New Comment:
It's not really useful since it doesn't exist. Try again..
You should have been a bit faster to look at it, while it was online.
I re-paste it here :
#0 0x080ad99c in match (eptr=0x8358fe4 ' ' repeats 200 times...,
ecode=0x834faf5 I, offset_top=6, md=0xbffaa264, ims=0,
eptrb=0x0, flags=2) at
/home/xanthor/temp/web/php-4.4.1/ext/pcre/pcrelib/pcre_exec.c:357
357 {
(gdb) bt
#0 0x080ad99c in match (eptr=0x8358fe4 ' ' repeats 200 times...,
ecode=0x834faf5 I, offset_top=6, md=0xbffaa264, ims=0,
eptrb=0x0, flags=2) at
/home/xanthor/temp/web/php-4.4.1/ext/pcre/pcrelib/pcre_exec.c:357
#1 0x080adb9b in match (eptr=Variable eptr is not available.
) at /home/xanthor/temp/web/php-4.4.1/ext/pcre/pcrelib/pcre_exec.c:747
#2 0x080b1222 in match (eptr=Variable eptr is not available.
) at /home/xanthor/temp/web/php-4.4.1/ext/pcre/pcrelib/pcre_exec.c:589
#3 0x080b2327 in match (eptr=Variable eptr is not available.
) at
/home/xanthor/temp/web/php-4.4.1/ext/pcre/pcrelib/pcre_exec.c:1123
#4 0x080b1222 in match (eptr=Variable eptr is not available.
) at /home/xanthor/temp/web/php-4.4.1/ext/pcre/pcrelib/pcre_exec.c:589
#5 0x080b2327 in match (eptr=Variable eptr is not available.
) at
/home/xanthor/temp/web/php-4.4.1/ext/pcre/pcrelib/pcre_exec.c:1123
#6 0x080b1222 in match (eptr=Variable eptr is not available.
) at /home/xanthor/temp/web/php-4.4.1/ext/pcre/pcrelib/pcre_exec.c:589
#7 0x080b2327 in match (eptr=Variable eptr is not available.
) at
/home/xanthor/temp/web/php-4.4.1/ext/pcre/pcrelib/pcre_exec.c:1123
#8 0x080b1222 in match (eptr=Variable eptr is not available.
) at /home/xanthor/temp/web/php-4.4.1/ext/pcre/pcrelib/pcre_exec.c:589
#9 0x080b2327 in match (eptr=Variable eptr is not available.
) at
/home/xanthor/temp/web/php-4.4.1/ext/pcre/pcrelib/pcre_exec.c:1123
#10 0x080b1222 in match (eptr=Variable eptr is not available.
) at /home/xanthor/temp/web/php-4.4.1/ext/pcre/pcrelib/pcre_exec.c:589
#11 0x080b2327 in match (eptr=Variable eptr is not available.
) at
/home/xanthor/temp/web/php-4.4.1/ext/pcre/pcrelib/pcre_exec.c:1123
#12 0x080b1222 in match (eptr=Variable eptr is not available.
) at /home/xanthor/temp/web/php-4.4.1/ext/pcre/pcrelib/pcre_exec.c:589
#13 0x080b2327 in match (eptr=Variable eptr is not available.
) at
/home/xanthor/temp/web/php-4.4.1/ext/pcre/pcrelib/pcre_exec.c:1123
And same thing again and again...
Previous Comments:
[2005-11-20 19:34:05] [EMAIL PROTECTED]
Andrei says this is not possible to fix since we can't tell what the
limit for recursion should be.
[2005-11-20 19:22:55] [EMAIL PROTECTED]
It's not really useful since it doesn't exist. Try again..
[2005-11-19 17:07:20] xanthor at xanthor dot tk
Here is the bactrace : http://rafb.net/paste/results/221Dcs52.html
I don't know if this will be usefull :¬/
[2005-11-16 10:21:24] [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
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.
[2005-11-16 04:48:51] xanthor at xanthor dot tk
Still crashes with 4.4.1, increasing the length of the string.
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/28461
--
Edit this bug report at http://bugs.php.net/?id=28461edit=1
#28461 [Fbk-Opn]: segmentation fault when using backreferences on a long string
ID: 28461 User updated by: xanthor at xanthor dot tk Reported By: xanthor at xanthor dot tk -Status: Feedback +Status: Open Bug Type: PCRE related Operating System: * PHP Version: 4.4.1 Assigned To: andrei New Comment: Here is the bactrace : http://rafb.net/paste/results/221Dcs52.html I don't know if this will be usefull :¬/ Previous Comments: [2005-11-16 10:21:24] [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 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. [2005-11-16 04:48:51] xanthor at xanthor dot tk Still crashes with 4.4.1, increasing the length of the string. [2005-06-30 01:00:04] 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. [2005-06-22 21:51:39] [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 Can't reproduce with latest PHP4 and PHP5 snapshots (PCRE was upgraded to 5.0, this might have fixed it). [2004-12-09 14:57:59] [EMAIL PROTECTED] This is the standard PCRE uses on-stack recursion bug which has been filed and closed umpteen times. To reproduce just increase the length of the string until exhausts your stack space. One way PHP could mitigate the issue is to to set the match_limit field in the pcre_extra structure which puts a limit on the depth of the stack recursion. 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/28461 -- Edit this bug report at http://bugs.php.net/?id=28461edit=1
#28461 [NoF-Opn]: segmentation fault when using backreferences on a long string
ID: 28461 User updated by: xanthor at xanthor dot tk Reported By: xanthor at xanthor dot tk -Status: No Feedback +Status: Open Bug Type: PCRE related Operating System: * -PHP Version: 5CVS, 4CVS (2005-05-30) +PHP Version: 4.4.1 Assigned To: andrei New Comment: Still crashes with 4.4.1, increasing the length of the string. Previous Comments: [2005-06-30 01:00:04] 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. [2005-06-22 21:51:39] [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 Can't reproduce with latest PHP4 and PHP5 snapshots (PCRE was upgraded to 5.0, this might have fixed it). [2004-12-09 14:57:59] [EMAIL PROTECTED] This is the standard PCRE uses on-stack recursion bug which has been filed and closed umpteen times. To reproduce just increase the length of the string until exhausts your stack space. One way PHP could mitigate the issue is to to set the match_limit field in the pcre_extra structure which puts a limit on the depth of the stack recursion. [2004-12-09 14:13:26] xanthor at xanthor dot tk Still segfault with PHP 4.3.10RC2 and PCRE Library Version 4.5 01-December-2003 [2004-12-06 16:17:35] [EMAIL PROTECTED] Can't reproduce with any of dev versions (tried latest 4.3.10-dev, 5.1.0-dev 5.0.3-dev under Linux). Please, try latest snapshots and tell me what version of pcre you're using (mine is 3.9) if you're still able to reproduce it. 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/28461 -- Edit this bug report at http://bugs.php.net/?id=28461edit=1
#32312 [Bgs]: Error in PCRE
ID: 32312
User updated by: xanthor at xanthor dot tk
Reported By: xanthor at xanthor dot tk
Status: Bogus
Bug Type: PCRE related
Operating System: *
PHP Version: 4CVS, 5CVS (2005-03-19)
New Comment:
And were are submited PCRElib bugs ?
Previous Comments:
[2005-04-20 09:04:40] [EMAIL PROTECTED]
It's the PCRElib limitation again..
[2005-03-19 00:07:33] [EMAIL PROTECTED]
No, it doesn't return 'bool(true)' as preg_match() returns an integer.
Try with something like 'var_dump(preg_match...'
Also RTFM.
[2005-03-16 21:31:52] xanthor at xanthor dot tk
It works with 4.3.2
[2005-03-15 10:32:34] xanthor at xanthor dot tk
Description:
The following code returns a wrong result with some strings, but when
we reduce them, it swich back to expected behaviour.
Tested on PHP 4.3.10, 4.3.9, 5.0.2, and 5.0.3RC2
PCRE Library Version = 4.5 01-December-2003
Reproduce code:
---
preg_match(/((.*.*.*)*.(.*.+.+..+)*b)?/,''.str_repeat('a',14).''.str_repeat('a',33).'a'.str_repeat('a',92).'a'.str_repeat('a',8).'aa')
Expected result:
This code should return true
Actual result:
--
The code returns false.
Reduce one of the str_repeat, and it'll return true.
--
Edit this bug report at http://bugs.php.net/?id=32312edit=1
#32312 [Fbk-Opn]: Error in PCRE
ID: 32312 User updated by: xanthor at xanthor dot tk Reported By: xanthor at xanthor dot tk -Status: Feedback +Status: Open Bug Type: PCRE related Operating System: GNU/Linux PHP Version: 4.3.10 New Comment: Well, then it's int(0) instead of false, and int(1) instead of true. Does that really make a difference ? (By the way, I tested on 4 different computers, and the bug is verified) Previous Comments: [2005-03-19 00:07:33] [EMAIL PROTECTED] No, it doesn't return 'bool(true)' as preg_match() returns an integer. Try with something like 'var_dump(preg_match...' Also RTFM. [2005-03-18 22:50:07] xanthor at xanthor dot tk As I just said before, it returns true... [2005-03-17 10:02:00] [EMAIL PROTECTED] What DOES it return with PHP 4.3.2 ? [2005-03-16 21:31:52] xanthor at xanthor dot tk It works with 4.3.2 [2005-03-16 00:47:24] [EMAIL PROTECTED] And with what PHP version does this work with? 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/32312 -- Edit this bug report at http://bugs.php.net/?id=32312edit=1
#32312 [Fbk-Opn]: Error in PCRE
ID: 32312
User updated by: xanthor at xanthor dot tk
Reported By: xanthor at xanthor dot tk
-Status: Feedback
+Status: Open
Bug Type: PCRE related
Operating System: GNU/Linux
PHP Version: 4.3.10
New Comment:
It works with 4.3.2
Previous Comments:
[2005-03-16 00:47:24] [EMAIL PROTECTED]
And with what PHP version does this work with?
[2005-03-15 10:32:34] xanthor at xanthor dot tk
Description:
The following code returns a wrong result with some strings, but when
we reduce them, it swich back to expected behaviour.
Tested on PHP 4.3.10, 4.3.9, 5.0.2, and 5.0.3RC2
PCRE Library Version = 4.5 01-December-2003
Reproduce code:
---
preg_match(/((.*.*.*)*.(.*.+.+..+)*b)?/,''.str_repeat('a',14).''.str_repeat('a',33).'a'.str_repeat('a',92).'a'.str_repeat('a',8).'aa')
Expected result:
This code should return true
Actual result:
--
The code returns false.
Reduce one of the str_repeat, and it'll return true.
--
Edit this bug report at http://bugs.php.net/?id=32312edit=1
#32312 [Ver]: Error in PCRE
ID: 32312
User updated by: xanthor at xanthor dot tk
Reported By: xanthor at xanthor dot tk
Status: Verified
Bug Type: PCRE related
Operating System: *
PHP Version: 4CVS, 5CVS (2005-03-19)
New Comment:
Why did you delete my answsers ?
Previous Comments:
[2005-03-19 00:07:33] [EMAIL PROTECTED]
No, it doesn't return 'bool(true)' as preg_match() returns an integer.
Try with something like 'var_dump(preg_match...'
Also RTFM.
[2005-03-16 21:31:52] xanthor at xanthor dot tk
It works with 4.3.2
[2005-03-15 10:32:34] xanthor at xanthor dot tk
Description:
The following code returns a wrong result with some strings, but when
we reduce them, it swich back to expected behaviour.
Tested on PHP 4.3.10, 4.3.9, 5.0.2, and 5.0.3RC2
PCRE Library Version = 4.5 01-December-2003
Reproduce code:
---
preg_match(/((.*.*.*)*.(.*.+.+..+)*b)?/,''.str_repeat('a',14).''.str_repeat('a',33).'a'.str_repeat('a',92).'a'.str_repeat('a',8).'aa')
Expected result:
This code should return true
Actual result:
--
The code returns false.
Reduce one of the str_repeat, and it'll return true.
--
Edit this bug report at http://bugs.php.net/?id=32312edit=1
#32312 [Ver]: Error in PCRE
ID: 32312
User updated by: xanthor at xanthor dot tk
Reported By: xanthor at xanthor dot tk
Status: Verified
Bug Type: PCRE related
Operating System: *
PHP Version: 4CVS, 5CVS (2005-03-19)
New Comment:
Why did you delete my posts ?
I gave other details...
Previous Comments:
[2005-03-19 00:07:33] [EMAIL PROTECTED]
No, it doesn't return 'bool(true)' as preg_match() returns an integer.
Try with something like 'var_dump(preg_match...'
Also RTFM.
[2005-03-16 21:31:52] xanthor at xanthor dot tk
It works with 4.3.2
[2005-03-15 10:32:34] xanthor at xanthor dot tk
Description:
The following code returns a wrong result with some strings, but when
we reduce them, it swich back to expected behaviour.
Tested on PHP 4.3.10, 4.3.9, 5.0.2, and 5.0.3RC2
PCRE Library Version = 4.5 01-December-2003
Reproduce code:
---
preg_match(/((.*.*.*)*.(.*.+.+..+)*b)?/,''.str_repeat('a',14).''.str_repeat('a',33).'a'.str_repeat('a',92).'a'.str_repeat('a',8).'aa')
Expected result:
This code should return true
Actual result:
--
The code returns false.
Reduce one of the str_repeat, and it'll return true.
--
Edit this bug report at http://bugs.php.net/?id=32312edit=1
#32312 [Fbk-Opn]: Error in PCRE
ID: 32312
User updated by: xanthor at xanthor dot tk
Reported By: xanthor at xanthor dot tk
-Status: Feedback
+Status: Open
Bug Type: PCRE related
Operating System: GNU/Linux
PHP Version: 4.3.10
New Comment:
As I just said before, it returns true...
Previous Comments:
[2005-03-17 10:02:00] [EMAIL PROTECTED]
What DOES it return with PHP 4.3.2 ?
[2005-03-16 21:31:52] xanthor at xanthor dot tk
It works with 4.3.2
[2005-03-16 00:47:24] [EMAIL PROTECTED]
And with what PHP version does this work with?
[2005-03-15 10:32:34] xanthor at xanthor dot tk
Description:
The following code returns a wrong result with some strings, but when
we reduce them, it swich back to expected behaviour.
Tested on PHP 4.3.10, 4.3.9, 5.0.2, and 5.0.3RC2
PCRE Library Version = 4.5 01-December-2003
Reproduce code:
---
preg_match(/((.*.*.*)*.(.*.+.+..+)*b)?/,''.str_repeat('a',14).''.str_repeat('a',33).'a'.str_repeat('a',92).'a'.str_repeat('a',8).'aa')
Expected result:
This code should return true
Actual result:
--
The code returns false.
Reduce one of the str_repeat, and it'll return true.
--
Edit this bug report at http://bugs.php.net/?id=32312edit=1
#32312 [Fbk-Opn]: Error in PCRE
ID: 32312 User updated by: xanthor at xanthor dot tk Reported By: xanthor at xanthor dot tk -Status: Feedback +Status: Open Bug Type: PCRE related -Operating System: GNU/Linux +Operating System: GNU/Linux, Windows#8482; PHP Version: 4.3.10 New Comment: Yes. Some other tests : Bug verified on another Linux box with PHP 4.3.10, but also on Windows XP with PHP 5.0.0. And the same regular expression in Perl returns true for both strings, as expected. Previous Comments: [2005-03-19 00:39:57] [EMAIL PROTECTED] Yes, it makes a difference when I add a regression test to this bug. I need to know the exact correct output. So, it returns int(1) with PHP 4.3.2 ? (only 1 match) [2005-03-19 00:32:14] xanthor at xanthor dot tk Well, then it's int(0) instead of false, and int(1) instead of true. Does that really make a difference ? (By the way, I tested on 4 different computers, and the bug is verified) [2005-03-19 00:07:33] [EMAIL PROTECTED] No, it doesn't return 'bool(true)' as preg_match() returns an integer. Try with something like 'var_dump(preg_match...' Also RTFM. [2005-03-18 22:50:07] xanthor at xanthor dot tk As I just said before, it returns true... [2005-03-17 10:02:00] [EMAIL PROTECTED] What DOES it return with PHP 4.3.2 ? 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/32312 -- Edit this bug report at http://bugs.php.net/?id=32312edit=1
#32312 [NEW]: Error in PCRE
From: xanthor at xanthor dot tk
Operating system: GNU/Linux
PHP version: 4.3.10
PHP Bug Type: PCRE related
Bug description: Error in PCRE
Description:
The following code returns a wrong result with some strings, but when we
reduce them, it swich back to expected behaviour.
Tested on PHP 4.3.10, 4.3.9, 5.0.2, and 5.0.3RC2
PCRE Library Version = 4.5 01-December-2003
Reproduce code:
---
preg_match(/((.*.*.*)*.(.*.+.+..+)*b)?/,''.str_repeat('a',14).''.str_repeat('a',33).'a'.str_repeat('a',92).'a'.str_repeat('a',8).'aa')
Expected result:
This code should return true
Actual result:
--
The code returns false.
Reduce one of the str_repeat, and it'll return true.
--
Edit bug report at http://bugs.php.net/?id=32312edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32312r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=32312r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=32312r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=32312r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=32312r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=32312r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=32312r=needscript
Try newer version: http://bugs.php.net/fix.php?id=32312r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=32312r=support
Expected behavior: http://bugs.php.net/fix.php?id=32312r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=32312r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=32312r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=32312r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32312r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=32312r=dst
IIS Stability: http://bugs.php.net/fix.php?id=32312r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=32312r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=32312r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=32312r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=32312r=mysqlcfg
#28461 [Fbk-Opn]: segmentation fault when using backreferences on a long string
ID: 28461
User updated by: xanthor at xanthor dot tk
Reported By: xanthor at xanthor dot tk
-Status: Feedback
+Status: Open
Bug Type: PCRE related
Operating System: Linux, WindowsXP©
-PHP Version: 4.3.9, 5.0.2
+PHP Version: 4.3.9, 4.3.10RC2, 5.0.2
New Comment:
Still segfault with PHP 4.3.10RC2 and PCRE Library Version 4.5
01-December-2003
Previous Comments:
[2004-12-06 16:17:35] [EMAIL PROTECTED]
Can't reproduce with any of dev versions (tried latest 4.3.10-dev,
5.1.0-dev 5.0.3-dev under Linux). Please, try latest snapshots and
tell me what version of pcre you're using (mine is 3.9) if you're still
able to reproduce it.
[2004-09-28 10:41:22] xanthor at xanthor dot tk
The regexs still crash PHP 4.3.9 and PHP 5.0.2
[2004-09-16 15:50:47] [EMAIL PROTECTED]
your last regex crashes PHP 5 also.
The segfault isn't in PHP but in pcre (this is quite normal due to the
NFA nature of pcre).
[2004-09-10 17:01:41] hewei at ied dot org dot cn
preg_match(/(((?!aaa).)*)(?!aaa)aaa/,str_repeat('
',10882).'aaa',$z);
crashes PHP4.3.9RC2
But not on php-4.3.2-11.1.ent (WBEL 3.0), the length
to trigger segmentation fault is about 19230.
The most funny thing is that the more closer to the limit, the more
likely you will get a random segmentation fault.
Not only the above pattern will cause the error,
preg_match(/^( )*$/,str_repeat(' ',19250));
will too.
[2004-09-10 12:49:48] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.0-win32-latest.zip
I couldn't reproduce any of the crashes.
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/28461
--
Edit this bug report at http://bugs.php.net/?id=28461edit=1
#28461 [Opn]: segmentation fault when using backreferences on a long string
ID: 28461
User updated by: xanthor at xanthor dot tk
Reported By: xanthor at xanthor dot tk
Status: Open
Bug Type: PCRE related
Operating System: Linux, WindowsXP©
-PHP Version: 4.3.8; 4.3.9RC1, 5.0.1
+PHP Version: 4.3.9, 5.0.2
New Comment:
The regexs still crash PHP 4.3.9 and PHP 5.0.2
Previous Comments:
[2004-09-16 15:50:47] [EMAIL PROTECTED]
your last regex crashes PHP 5 also.
The segfault isn't in PHP but in pcre (this is quite normal due to the
NFA nature of pcre).
[2004-09-10 17:01:41] hewei at ied dot org dot cn
preg_match(/(((?!aaa).)*)(?!aaa)aaa/,str_repeat('
',10882).'aaa',$z);
crashes PHP4.3.9RC2
But not on php-4.3.2-11.1.ent (WBEL 3.0), the length
to trigger segmentation fault is about 19230.
The most funny thing is that the more closer to the limit, the more
likely you will get a random segmentation fault.
Not only the above pattern will cause the error,
preg_match(/^( )*$/,str_repeat(' ',19250));
will too.
[2004-09-10 12:49:48] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.0-win32-latest.zip
I couldn't reproduce any of the crashes.
[2004-08-23 11:24:50] xanthor at xanthor dot tk
Updating version :
I've found an other expression which segfaults also PHP 5 :
preg_match(/^((?!a).)*/,str_repeat('b',21236),$z);
[2004-07-19 11:11:33] xanthor at xanthor dot tk
The bug is still here with PHP 4.3.8
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/28461
--
Edit this bug report at http://bugs.php.net/?id=28461edit=1
#28461 [Opn]: segmentation fault when using backreferences on a long string
ID: 28461
User updated by: xanthor at xanthor dot tk
Reported By: xanthor at xanthor dot tk
Status: Open
Bug Type: PCRE related
Operating System: Linux, WindowsXP©
-PHP Version: 4.3.8
+PHP Version: 4.3.8; 4.3.9RC1, 5.0.1
New Comment:
Updating version :
I've found an other expression which segfaults also PHP 5 :
preg_match(/^((?!a).)*/,str_repeat('b',21236),$z);
Previous Comments:
[2004-07-19 11:11:33] xanthor at xanthor dot tk
The bug is still here with PHP 4.3.8
[2004-05-21 11:17:44] xanthor at xanthor dot tk
No it isn't fixed :
with 2236+3 chars it works, but when we increase this number we manage
to have an other segmentation fault.
(The new limit seems to be 2247+3)
[2004-05-21 01:13:19] [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
[2004-05-20 22:15:47] xanthor at xanthor dot tk
Description:
This line crash PHP with a segmentation fault.
It use a 3-chars-long back reference, on a 2236+3 chars-long string
If the back references is only 2 chars long, it's ok.
If the long string is less that 2236+3 chars, it's ok too...
Reproduce code:
---
preg_match(/(((?!aaa).)*)(?!aaa)aaa/,str_repeat('
',2236).'aaa',$z);
Expected result:
No crash, and true return by the preg_match
Actual result:
--
segmentation fault
--
Edit this bug report at http://bugs.php.net/?id=28461edit=1
#28461 [Opn]: segmentation fault when using backreferences on a long string
ID: 28461
User updated by: xanthor at xanthor dot tk
Reported By: xanthor at xanthor dot tk
Status: Open
Bug Type: PCRE related
Operating System: Linux, WindowsXP©
-PHP Version: 4.3.6
+PHP Version: 4.3.8
New Comment:
The bug is still here with PHP 4.3.8
Previous Comments:
[2004-05-21 11:17:44] xanthor at xanthor dot tk
No it isn't fixed :
with 2236+3 chars it works, but when we increase this number we manage
to have an other segmentation fault.
(The new limit seems to be 2247+3)
[2004-05-21 01:13:19] [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
[2004-05-20 22:15:47] xanthor at xanthor dot tk
Description:
This line crash PHP with a segmentation fault.
It use a 3-chars-long back reference, on a 2236+3 chars-long string
If the back references is only 2 chars long, it's ok.
If the long string is less that 2236+3 chars, it's ok too...
Reproduce code:
---
preg_match(/(((?!aaa).)*)(?!aaa)aaa/,str_repeat('
',2236).'aaa',$z);
Expected result:
No crash, and true return by the preg_match
Actual result:
--
segmentation fault
--
Edit this bug report at http://bugs.php.net/?id=28461edit=1
#28461 [Fbk-Opn]: segmentation fault when using backreferences on a long string
ID: 28461
User updated by: xanthor at xanthor dot tk
Reported By: xanthor at xanthor dot tk
-Status: Feedback
+Status: Open
Bug Type: PCRE related
Operating System: Linux, WindowsXP©
PHP Version: 4.3.6
New Comment:
No it isn't fixed :
with 2236+3 chars it works, but when we increase this number we manage
to have an other segmentation fault.
(The new limit seems to be 2247+3)
Previous Comments:
[2004-05-21 01:13:19] [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
[2004-05-20 22:15:47] xanthor at xanthor dot tk
Description:
This line crash PHP with a segmentation fault.
It use a 3-chars-long back reference, on a 2236+3 chars-long string
If the back references is only 2 chars long, it's ok.
If the long string is less that 2236+3 chars, it's ok too...
Reproduce code:
---
preg_match(/(((?!aaa).)*)(?!aaa)aaa/,str_repeat('
',2236).'aaa',$z);
Expected result:
No crash, and true return by the preg_match
Actual result:
--
segmentation fault
--
Edit this bug report at http://bugs.php.net/?id=28461edit=1
#28461 [NEW]: segmentation fault when using backreferences on a long string
From: xanthor at xanthor dot tk
Operating system: Linux, WindowsXP©
PHP version: 4.3.6
PHP Bug Type: PCRE related
Bug description: segmentation fault when using backreferences on a long string
Description:
This line crash PHP with a segmentation fault.
It use a 3-chars-long back reference, on a 2236+3 chars-long string
If the back references is only 2 chars long, it's ok.
If the long string is less that 2236+3 chars, it's ok too...
Reproduce code:
---
preg_match(/(((?!aaa).)*)(?!aaa)aaa/,str_repeat(' ',2236).'aaa',$z);
Expected result:
No crash, and true return by the preg_match
Actual result:
--
segmentation fault
--
Edit bug report at http://bugs.php.net/?id=28461edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28461r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28461r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=28461r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=28461r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=28461r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=28461r=needscript
Try newer version: http://bugs.php.net/fix.php?id=28461r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=28461r=support
Expected behavior: http://bugs.php.net/fix.php?id=28461r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=28461r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=28461r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=28461r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28461r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=28461r=dst
IIS Stability: http://bugs.php.net/fix.php?id=28461r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=28461r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=28461r=float
