|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #12748 changing allow_url_fopen from "off" to "on" crashes fopen()
Submitted: 2001-08-14 20:24 UTC Modified: 2002-06-19 06:45 UTC
Avg. Score:4.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: phpman at toowards dot com Assigned:
Status: Closed Package: Reproducible crash
PHP Version: 4.2.x OS: redhat-7.1b
Private report: No CVE-ID:
 [2001-08-14 20:24 UTC] phpman at toowards dot com

PHP compiled as DSO, no other options
./configure  --with-apxs=/usr/local/apache/bin/apxs

Note, this is not the same as bug #9672
Updating glibc does solve that problem see

engine = On
allow_url_fopen = Off

My httpd.conf contains (in a VirtualHost),
  php_admin_flag allow_url_fopen On

A test script
$fp = fopen( "", "r" );
if( $fp )
        print "fopen() success\n";

#0  __strtol_internal (nptr=0x403adba0 "", endptr=0x81128bc,
    group=-1073748792) at eval.c:36
#1  0x402bee14 in zend_hash_find (ht=0x403adba0,
    arKey=0x81128bc "", nKeyLength=4,
    at zend_hash.c:850
#2  0x402cd259 in php_fopen_url_wrapper (path=0x81128bc
    mode=0x810d5c4 "r", options=4, issock=0xbfffe508,
    opened_path=0x0) at fopen_wrappers.c:445
#3  0x4031f2fb in php_if_fopen (ht=2,
return_value=0x810d5a4, this_ptr=0x0,
    return_value_used=1) at file.c:639
#4  0x402acd5c in execute (op_array=0x8109efc) at
#5  0x402bae95 in zend_execute_scripts (type=8,
file_count=3) at zend.c:752
#6  0x402cc30b in php_execute_script
(primary_file=0xbffff890) at main.c:1206
#7  0x402c8bae in apache_php_module_main (r=0x8107644,
    at sapi_apache.c:89
#8  0x402c9541 in send_php (r=0x8107644,
display_source_mode=0, filename=0x0)
    at mod_php4.c:536
#9  0x402c956a in send_parsed_php (r=0x8107644) at
#10 0x080558d3 in ap_invoke_handler () at eval.c:41
#11 0x08069667 in process_request_internal () at eval.c:41
#12 0x080696c8 in ap_process_request () at eval.c:41
#13 0x08060b69 in child_main () at eval.c:41
#14 0x08060d14 in make_child () at eval.c:41
#15 0x08060e88 in startup_children () at eval.c:41
#16 0x080614d7 in standalone_main () at eval.c:41
#17 0x08061cf3 in main () at eval.c:41
#18 0x400ca6b7 in __libc_start_main (main=0x806195c <main>,
    ubp_av=0xbffffb64, init=0x804ead0 <_init>,
fini=0x80969bc <_fini>,
    rtld_fini=0x4000db64 <_dl_fini>, stack_end=0xbffffb5c)
    at ../sysdeps/generic/libc-start.c:129


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2001-08-15 02:17 UTC]
Could you please try latest CVS snapshot from to verify if this still exists..

Also, what is redhat-7.1b ? (the b there..?)


 [2001-08-18 05:23 UTC] phpman at toowards dot com
Todays snapshot - php4-200108180135.tar.bz2 - still shows 
the problem. Same config, same test script. 

redhat-7.1b == redhat 7.1 Beta (Fisher)

Backtrace from today:

Program received signal SIGSEGV, Segmentation fault.
0x402c0ad1 in zend_hash_find (ht=0x40395ae0, 
arKey=0x810c8dc "",
    nKeyLength=4, pData=0xbfffe208) at zend_hash.c:861
861             p = ht->arBuckets[nIndex];

#0  0x402c0ad1 in zend_hash_find (ht=0x40395ae0,
    arKey=0x810c8dc "", nKeyLength=4, 
    at zend_hash.c:861
#1  0x402ca732 in php_fopen_url_wrapper (path=0x810c8dc 
    mode=0x81075cc "r", options=4, issock=0xbfffe248, 
    opened_path=0x0) at fopen_wrappers.c:533
#2  0x4030aa87 in php_if_fopen (ht=2, 
return_value=0x81075ac, this_ptr=0x0,
    return_value_used=1) at file.c:661
#3  0x402adaf8 in execute (op_array=0x810750c) at 
#4  0x402bbd05 in zend_execute_scripts (type=8, 
file_count=3) at zend.c:806
#5  0x402c945f in php_execute_script 
(primary_file=0xbffff740) at main.c:1310
#6  0x402c562e in apache_php_module_main (r=0x8101264, 
    at sapi_apache.c:90
#7  0x402c6112 in send_php (r=0x8101264, 
display_source_mode=0, filename=0x0)
    at mod_php4.c:575
#8  0x402c6166 in send_parsed_php (r=0x8101264) at 
#9  0x08055823 in ap_invoke_handler () at eval.c:41
#10 0x080695b3 in process_request_internal () at eval.c:41
#11 0x08069614 in ap_process_request () at eval.c:41
#12 0x08060ab9 in child_main () at eval.c:41
#13 0x08060c64 in make_child () at eval.c:41
#14 0x08060dd8 in startup_children () at eval.c:41
#15 0x08061427 in standalone_main () at eval.c:41
#16 0x08061c43 in main () at eval.c:41
#17 0x400ca6b7 in __libc_start_main (main=0x80618ac 
<main>, argc=2,
    ubp_av=0xbffffb84, init=0x804ea24 <_init>, 
fini=0x80968fc <_fini>,
    rtld_fini=0x4000db64 <_dl_fini>, stack_end=0xbffffb7c)
    at ../sysdeps/generic/libc-start.c:129

(gdb) print *ht
$7 = {nTableSize = 0, nTableMask = 0, nNumOfElements = 0, 
nNextFreeElement = 0,
  pInternalPointer = 0x0, pListHead = 0x0, pListTail = 
0x0, arBuckets = 0x0,
  pDestructor = 0, persistent = 0 '\000', nApplyCount = 0 
  bApplyProtection = 0 '\000'}

Looks like 'fopen_url_wrappers_hash' in fopen_wrappers.c 
isn't being setup right? I'm lost though - I don't see how 
the apache directives work.

 [2001-08-18 05:56 UTC] phpman at toowards dot com
Also, phpinfo() shows a blank cell for the 'Master Value' 
and "1" for the 'Local Value' of 'allow_url_fopen' when 

in php.ini:
allow_url_fopen = Off

& in httpd.conf
php_admin_flag allow_url_fopen On

I tried using "allow_url_fopen = 0" (Master Value becomes 
"0", fopen() still crashes).

I also tried "php_admin_value allow_url_fopen 1" (Local 
Value still "1", fopen() still crashes).

When I leave out the setting in httpd.conf, and just have 
"allow_url_fopen = Off" in the php.ini file, phpinfo() has 
"no value" written for the Master Value and Local Value.

Maybe this helps?

 [2001-10-10 19:01 UTC] phpman at toowards dot com
See #13633 which describes a similar problem - I am not 
alone :-)

 [2002-02-04 02:15 UTC]
The version of PHP that this bug was reported in is too old. Please
try to reproduce this bug in the latest version of PHP (available

If you are still able to reproduce the bug with one of the latest
versions of PHP, please change the PHP version on this bug report
to the version you tested and change the status back to "Open".
 [2002-02-04 03:44 UTC] phpman at toowards dot com
I haven't got the latest snapshot handy - or a machine to test on just at the moment, but I did a quick test on 4.1.0 and segmentation faults appear in my log, so it looks like the bug still exists. I'll try a proper test when I get a chance.

I don't seem to be able to change it the status to Open using this bug reporter however.

 [2002-02-04 16:09 UTC]
This one is still not fixed.
 [2002-03-31 21:18 UTC] phpman at toowards dot com
I tested today on the 4.2.0 branch and I'm still getting the same problem.
Program received signal SIGSEGV, Segmentation fault.
0x402c4b6d in zend_hash_find (ht=0x4039e1e0, arKey=0x811288c "", nKeyLength=4,
    pData=0xbfffe1e8) at zend_hash.c:861
861             p = ht->arBuckets[nIndex];

I think Bug #15854 ( is related to this.
 [2002-06-18 18:55 UTC]
This bug has been fixed in CVS. You can grab a snapshot of the
CVS version at In case this was a documentation 
problem, the fix will show up soon at
In case this was a website problem, the change will show
up on the site and on the mirror sites.
Thank you for the report, and for helping us make PHP better.

I can't reproduce this..

 [2002-06-18 23:13 UTC] phpman at toowards dot com
I still get the same crash.


Apache configure
./configure --enable-shared=max --enable-module=most

PHP configure
./configure --with-apxs=/usr/local/apache/bin/apxs

php.ini same as previously noted.
test script same as previously noted.

Program received signal SIGSEGV, Segmentation fault.
0x402e3721 in zend_hash_find (ht=0x403ba5e0, arKey=0x80e6e14 "", nKeyLength=4,
    pData=0xbfffe1e8) at zend_hash.c:878
878             p = ht->arBuckets[nIndex];
 [2002-06-18 23:21 UTC]
It's not fixed in the 4.2.x branch but in the 4.3.0-dev.
(the snapshot NOT having word STABLE in them)

There was one more fix needed just after I closed this,
but now it definately is fixed. Try this snapshot:

(it might not yet have the fix though, check that main/streams.c has revision 1.57)

 [2002-06-19 06:45 UTC] phpman at toowards dot com
I agree, this is fixed in 4.3.0-dev.

I look forward to the 4.3.0 release :-)

PHP Copyright © 2001-2017 The PHP Group
All rights reserved.
Last updated: Tue Aug 29 15:01:52 2017 UTC