php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #24008 segmentation fault in preg_match()
Submitted: 2003-06-04 02:26 UTC Modified: 2003-06-29 19:01 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:0 of 0 (0.0%)
From: imacat at mail dot imacat dot idv dot tw Assigned:
Status: Not a bug Package: PCRE related
PHP Version: 4.3.2 OS: Debian 3.0r1/Linux 2.4.20
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: imacat at mail dot imacat dot idv dot tw
New email:
PHP Version: OS:

 

 [2003-06-04 02:26 UTC] imacat at mail dot imacat dot idv dot tw
The following simple test script caused a segmentation fault:

imacat@rinse ~ % cat test.php
<?php
$a = "";
for ($i = 0; $i < 10000; $i++) {
    $a .= "\x5F ";
}
preg_match("/(..)+(\x5Fa|\x5F@)/", $a);
?>
imacat@rinse ~ % php test.php
zsh: segmentation fault  php test.php
imacat@rinse ~ %

No core dump.  This piece of code was part of a complex regular expression to match against URLs in a piece of DBCS plain text.  This is a most-simplified scratch that can illustrate the segmentation fault, so please don't ask me what this non-sense scratch is for.  It first crashed under apache/mod_php4 4.3.1, and I found it crashes under php 4.3.2, too, both as apache/mod_php4 and php client binary.

I have rewritten my subroutine to avoid this problem.  It required rewriting anyway.

This happens on my Debian 3.0r1x2 and Red Hat 9, all using gcc 3.3 and glibc 2.3.2.  On my other 2 Red Hat 9, it enters an infinite loop and used up all the CPU time.

Please tell me if you need more infomation on this.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-06-04 14:12 UTC] elmicha@php.net
Apparently preg_match() eats the whole stack (endless recursion).
You can get a core dump if you use "ulimit -c unlimited". If your stack size is very high, you have to wait a long time; with "ulimit -s 5000" it's a lot better.

(gdb) bt -10
#16814 0x08128cb4 in match (
    eptr=0x855a706 "_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ "..., ecode=0x8559e94 "=", 
    offset_top=4, md=0xbfffe260, ims=0, eptrb=0xbfffe0a0, flags=2)
    at /usr/local/src/php-4.3.2/ext/pcre/pcrelib/pcre.c:4730
#16815 0x08127e15 in match (
    eptr=0x855a704 "_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ "..., ecode=0x8559e8f "K", 
    offset_top=2, md=0xbfffe260, ims=0, eptrb=0xbfffe0a0, flags=2)
    at /usr/local/src/php-4.3.2/ext/pcre/pcrelib/pcre.c:4206
#16816 0x08128035 in match (
    eptr=0x855a704 "_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ "..., ecode=0x8559e8c "J", 
    offset_top=2, md=0xbfffe260, ims=0, eptrb=0xbfffe1d0, flags=2)
    at /usr/local/src/php-4.3.2/ext/pcre/pcrelib/pcre.c:4235
#16817 0x0812b39a in php_pcre_exec (external_re=0x8559e70, external_extra=0x0, 
    subject=0x855a704 "_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ "..., length=20000, start_offset=0, 
    options=0, offsets=0x8559eec, offsetcount=9)
    at /usr/local/src/php-4.3.2/ext/pcre/pcrelib/pcre.c:5943
#16818 0x0812c506 in php_pcre_match (ht=2, return_value=0x85599cc, this_ptr=0x0, 
    return_value_used=0, global=0) at /usr/local/src/php-4.3.2/ext/pcre/php_pcre.c:440
#16819 0x0812ca9c in zif_preg_match (ht=2, return_value=0x85599cc, this_ptr=0x0, 
    return_value_used=0) at /usr/local/src/php-4.3.2/ext/pcre/php_pcre.c:564
#16820 0x08253eb2 in execute (op_array=0x85591dc)
    at /usr/local/src/php-4.3.2/Zend/zend_execute.c:1606
#16821 0x08235717 in zend_eval_string (
    str=0xbfffea80 "$a = \"\";\n\nfor ($i = 0; $i < 10000; $i++) {\n\n    $a .= \"\\x5F \";\n\n}\necho \"hi\\n\";\npreg_match(\"/(..)+(\\x5Fa|\\x5F@)/\", $a);\n\n", 
    retval_ptr=0x0, string_name=0x836d7b4 "Command line code")
    at /usr/local/src/php-4.3.2/Zend/zend_execute_API.c:636
#16822 0x0825c5e0 in main (argc=3, argv=0xbfffe824)
    at /usr/local/src/php-4.3.2/sapi/cli/php_cli.c:847
#16823 0x4075f8c1 in __libc_start_main (main=0x825b7c4 <main>, argc=3, 
    argv=0xbfffe824, init=0x8092478 <_init>, fini=0x832e614 <_fini>, 
    rtld_fini=0x4000a914 <_dl_fini>, stack_end=0xbfffe81c)
    at ../sysdeps/generic/libc-start.c:92

 [2003-06-29 19:01 UTC] iliaa@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. 

Thank you for your interest in PHP.

This is actually a PCRE library bug, fortunately in the updated pcrelib now bundled with php this no longer results in a crash but rather an unterminated loop until maximum execution time is reached.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Apr 19 05:01:29 2024 UTC