php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #34790 preg_match_all(), named capturing groups, variable assignment/return => crash
Submitted: 2005-10-08 19:27 UTC Modified: 2005-10-11 08:53 UTC
From: savzen at gmail dot com Assigned: dmitry (profile)
Status: Closed Package: PCRE related
PHP Version: 5CVS, 4CVS (2005-10-08) (snap) OS: Linux
Private report: No CVE-ID: None
 [2005-10-08 19:27 UTC] savzen at gmail dot com
Description:
------------
I used the function preg_match_all () WITHIN a function being called by another function, with a named capturing group and assigned the match to a variable using the named group as a key (name or number).

The variable assigned the value of the return becomes NULL

This happens in both the latest snapshots of PHP-4 and PHP-5 with PHP-5 giving a segmentation fault after NULL when "error_reporting (E_ALL)" is at the top of the script

When the configure option --enable-debug is used PHP-5 gives UNKNOWN:0 instead of NULL and no segmentation fault

When NOT using a Named capturing group name and instead use a normal capturing group the behaviour seems to stop. Assigning the matched value by reference also seems to stop the behaviour. ie var2=&var['named_key']

Reproduce code:
---------------
error_reporting(E_ALL);
function func1(){
        $words = func2();
        var_dump($words);
        $this_words = $words;
        return $this_words;
}
function func2(){
        $pattern = '(?P<word>(?:the))';
        $string = 'what the word and the other word the';
        preg_match_all('/'.$pattern.'/i', $string, $matches);
        $words = $matches['word'];
        $this_words = $words;
        var_dump($this_words);
        return $words;
}
func1();

Expected result:
----------------
array(4) {
  [0]=>
  string(3) "the"
  [1]=>
  string(3) "the"
  [2]=>
  string(3) "the"
  [3]=>
  string(3) "the"
}
array(4) {
  [0]=>
  string(3) "the"
  [1]=>
  string(3) "the"
  [2]=>
  string(3) "the"
  [3]=>
  string(3) "the"
}


Actual result:
--------------
array(4) {
  [0]=>
  string(3) "the"
  [1]=>
  string(3) "the"
  [2]=>
  string(3) "the"
  [3]=>
  string(3) "the"
}
NULL{php -4} UNKNOWN:0 {php-5 --enable-debug}
segmentation fault {php-5 without --enable-debug}

Backtrace (PHP-5 latest without enable-debug because it doesn't crash when it is used)
---------------------------------------
(gdb) bt
#0  0x402429f2 in malloc () from /lib/i686/libc.so.6
Cannot access memory at address 0x18
(gdb)

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-10-09 00:17 UTC] nlopess@php.net
Ouch... 193 valgrind errors :)
 [2005-10-09 01:42 UTC] nlopess@php.net
I've tried to fix the bug, but I couldn't find a clue.
The problem is triggered when destroying a hash table (in zend_hash.c), but I don't know which hash table is. This should be much easier to a Engine expert.
Anyway, I've made a simpler reproduce script, which is enough to trigger valgrind errors.

<? preg_match_all('/(?P<word>the)/', '', $matches); ?>
 [2005-10-09 20:48 UTC] iliaa@php.net
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

Tried latest CVS, works fine and no valgrind errors.
 [2005-10-10 01:14 UTC] savzen at gmail dot com
I get errors in output and a segmentation fault.

Reproduce code:
-----------------------------
<?php
function func1(){
        $string = 'what the word and the other word the';
        preg_match_all('/(?P<word>the)/', $string, $matches);
        return $matches['word'];
}
$words = func1();
var_dump($words);

?>

Expected result:
----------------------------
array(4) {
  [0]=>
  string(3) "the"
  [1]=>
  string(3) "the"
  [2]=>
  string(3) "the"
  [3]=>
  string(3) "the"
}

Actual result:
---------------------------
array(4) {
  [0]=>
  string(3) "the"
  [1]=>
  string(3) "the"
  [2]=>
  string(3) "the"
  [3]=>
  string(3) "q9"
}
Segmentation fault

This is the backtrace without --enable-debug, because it doesn't crash with it enabled. Only output is UNKNOWN:0
--------------------------------------------------
(gdb) bt
#0  0x402429fc in malloc () from /lib/i686/libc.so.6
#1  0x083047f8 in ?? ()
#2  0x402ec6a0 in __check_rhosts_file () from /lib/i686/libc.so.6
Cannot access memory at address 0x10000
 [2005-10-10 23:26 UTC] nlopess@php.net
I've reproduced it with PHP 5.1. I haven't tried anything else.
Dmitry probably is the best guy to look at this, as it seems an engine problem.
 [2005-10-10 23:33 UTC] tony2001@php.net
This is what I get with Zend MM disabled:
http://tony2001.phpclub.net/dev/tmp/pcre_valgrind.txt
 [2005-10-11 08:53 UTC] dmitry@php.net
Fixed in CVS HEAD, PHP_5_1, PHP_5_0 and PHP_4_4.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Mar 19 05:01:29 2024 UTC