php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #26025 segfault when glob() is called with GLOB_BRACE and there are no matches
Submitted: 2003-10-29 01:41 UTC Modified: 2003-11-06 19:23 UTC
From: ryan at wonko dot com Assigned:
Status: Closed Package: Filesystem function related
PHP Version: 4.3.4RC2 OS: FreeBSD 4.7-RELEASE
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: ryan at wonko dot com
New email:
PHP Version: OS:

 

 [2003-10-29 01:41 UTC] ryan at wonko dot com
Description:
------------
When you call glob() with the GLOB_BRACE flag set, PHP segfaults if there are no files or directories matching the pattern.

I'm running Apache 2.0.47 and PHP was built with the following configure line:

'./configure' '--enable-versioning' '--enable-memory-limit' '--with-layout=GNU' '--with-zlib-dir=/usr' '--disable-all' '--with-regex=php' '--disable-cli' '--with-bz2=/usr' '--enable-ctype' '--with-dom=/usr/local' '--enable-exif' '--enable-ftp' '--with-gd' '--enable-gd-native-ttf' '--enable-gd-jis-conv' '--with-freetype-dir=/usr/local' '--with-jpeg-dir=/usr/local' '--with-png-dir=/usr/local' '--with-xpm-dir=/usr/local' '--with-gettext=/usr/local' '--with-mysql=/usr/local' '--with-openssl-dir=/usr/local' '--with-openssl=/usr/local' '--enable-overload' '--with-pcre-regex=yes' '--enable-posix' '--with-pspell=/usr/local' '--enable-session' '--enable-sockets' '--enable-tokenizer' '--with-expat-dir=/usr/local' '--enable-xml' '--with-zip=/usr/local' '--with-zlib=yes' '--with-apxs2=/usr/local/sbin/apxs' '--with-imap=/usr/local' '--with-imap-ssl=/usr/local' '--prefix=/usr/local' 'i386-portbld-freebsd4.7'

Reproduce code:
---------------
<?
glob("{*.foo,*.bar}", GLOB_BRACE);
?>

Expected result:
----------------
glob() should return FALSE, indicating that there were no files or directories matching the pattern.

Actual result:
--------------
PHP exits on signal 11 (segmentation fault), as illustrated by these entries in my Apache error log:

[Tue Oct 28 22:38:02 2003] [notice] child pid 68645 exit signal Segmentation fault (11)
[Tue Oct 28 22:38:03 2003] [notice] child pid 68670 exit signal Segmentation fault (11)
[Tue Oct 28 22:38:12 2003] [notice] child pid 68800 exit signal Segmentation fault (11)


Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-10-29 02:06 UTC] ryan at wonko dot com
Here's the backtrace:

#0  0x80b0906 in zif_glob (ht=2, return_value=0x81fb224, this_ptr=0x0, return_value_used=0)
    at /usr/home/ryan/testphp/php-4.3.4RC2/ext/standard/dir.c:409
#1  0x8166a93 in execute (op_array=0x81fa8a4) at /usr/home/ryan/testphp/php-4.3.4RC2/Zend/zend_execute.c:1616
#2  0x8155d49 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/home/ryan/testphp/php-4.3.4RC2/Zend/zend.c:885
#3  0x81231a3 in php_execute_script (primary_file=0xbfbffb40) at /usr/home/ryan/testphp/php-4.3.4RC2/main/main.c:1729
#4  0x816caf7 in main (argc=2, argv=0xbfbffbb0) at /usr/home/ryan/testphp/php-4.3.4RC2/sapi/cli/php_cli.c:819
#5  0x806035d in _start ()
 [2003-10-29 16:52 UTC] moriyoshi@php.net
This bug has been fixed in CVS.

In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.


 [2003-11-06 19:23 UTC] moriyoshi@php.net
> On October 29, you fixed bug #26025 in CVS. At that time,
> I verified that the bug was fixed in the stable 4.3.x
> snapshot from snaps.php.net.
> However, on November 3, PHP 4.3.4 was released with the
> bug still present.
> 
> Should I reopen the bug, since it is still present in the
> latest stable release? I'm not sure what the protocol is
> for this.

Although the bug was fixed in time 4.3.4 was released, the release master (Ilia Alshanetsky) decided the actual fix to go into the next release. This case you don't have to reopen it.

p.s. please use this bug database system instead if the subject is still relevant to the bug you reported, don't send us a mail directly.

 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Nov 21 15:01:30 2024 UTC