php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #51248 Segmentation fault in mysql_fetch_array
Submitted: 2010-03-09 20:20 UTC Modified: 2013-02-18 00:34 UTC
Votes:12
Avg. Score:4.6 ± 0.8
Reproduced:11 of 12 (91.7%)
Same Version:8 (72.7%)
Same OS:6 (54.5%)
From: mbeccati@php.net Assigned: mysql (profile)
Status: No Feedback Package: MySQL related
PHP Version: 5.3.2 OS: FreeBSD 6.2
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: mbeccati@php.net
New email:
PHP Version: OS:

 

 [2010-03-09 20:20 UTC] mbeccati@php.net
Description:
------------
I've been asked to publish a Drupal based website on my 5.3.2 box, but every page call triggers a segmentation fault. Replicated with 5.3.1 as well.

I've been able to test an old 5.2.8 and the issue is gone.

I can't attach a reproduce code, but I will try to gather more information in the next few days. For now I'm attaching the backtrace.

Actual result:
--------------
Program received signal SIGSEGV, Segmentation fault.
0x000000008518a7c3 in zend_fetch_resource (passed_id=0x7fffffffcc50, default_id=-1, resource_type_name=0x855c3d6f "MySQL result", found_resource_type=0x0, num_resource_types=1) at /root/compile/php-5.3.2-apache/Zend/zend_list.c:127
127                   } else if ((*passed_id)->type != IS_RESOURCE) {
(gdb) bt full
#0  0x000000008518a7c3 in zend_fetch_resource (passed_id=0x7fffffffcc50, default_id=-1, resource_type_name=0x855c3d6f "MySQL result", found_resource_type=0x0, num_resource_types=1) at /root/compile/php-5.3.2-apache/Zend/zend_list.c:127
        id = -1
        actual_resource_type = 0
        resource = (void *) 0x10
        resource_types = {{gp_offset = 5, fp_offset = 0, overflow_arg_area = 0x861c775b, reg_save_area = 0x3000000020}}
        i = -1
        space = 0x85185062 "H\201Äè"
        class_name = 0x1 <Address 0x1 out of bounds>
#1  0x0000000084fabcc6 in php_mysql_fetch_hash (ht=2, return_value=0xb04ae0, return_value_ptr=0x8518a6cf, this_ptr=0x0, return_value_used=1, result_type=1, expected_args=2, into_object=0)
    at /root/compile/php-5.3.2-apache/ext/mysql/php_mysql.c:1944
        class_name = 0x7fffffffcd40 "Ðî©"
        class_name_len = 32767
        mysql_result = (MYSQL_RES *) 0x2
        res = (zval *) 0x0
        ctor_params = (zval *) 0x0
        ce = (zend_class_entry *) 0x0
        i = 17
        mysql_field = (MYSQL_FIELD *) 0x0
        mysql_row = (MYSQL_ROW) 0xa9eed0
        mysql_row_lengths = (long unsigned int *) 0x1
#2  0x0000000084fac24b in zif_mysql_fetch_array (ht=-13232, return_value=0xffffffff, return_value_ptr=0x8518a6cf, this_ptr=0x0, return_value_used=1) at /root/compile/php-5.3.2-apache/ext/mysql/php_mysql.c:2105
No locals.
#3  0x000000008519fa82 in zend_do_fcall_common_helper_SPEC (execute_data=0x9cef80) at /root/compile/php-5.3.2-apache/Zend/zend_vm_execute.h:313
        i = 0
        p = (zval **) 0x9cef70
        arg_count = 2
        opline = (zend_op *) 0xa9eed0
        should_change_scope = 0 '\0'
#4  0x000000008519eea9 in execute (op_array=0xa94e00) at /root/compile/php-5.3.2-apache/Zend/zend_vm_execute.h:104
        ret = 0
        execute_data = (zend_execute_data *) 0x9cef80
        nested = 1 '\001'
        original_in_execution = 0 '\0'
#5  0x000000008517d055 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /root/compile/php-5.3.2-apache/Zend/zend.c:1194
        files = {{gp_offset = 40, fp_offset = 48, overflow_arg_area = 0x7fffffffd000, reg_save_area = 0x7fffffffcf10}}
        i = 1
        file_handle = (zend_file_handle *) 0x7fffffffe640
        orig_op_array = (zend_op_array *) 0x0
        orig_retval_ptr_ptr = (zval **) 0x0
#6  0x000000008512a7db in php_execute_script (primary_file=0x7fffffffe640) at /root/compile/php-5.3.2-apache/main/main.c:2260
        realfile = "\000\000\000\000\000\000\000\000Ù\204{\200", '\0' <repeats 16 times>, "ÿ\177\000\000\002\000\000\000\002\000\000\000Ì\217\233\000\000\000\000\000\v\000\000\000\000\000\000\000>\020V\200\000\000\000\000 äW\200\000\000\000\000Àãÿÿÿ\177\000\000\000\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000ÄI<\a\000\000\000\000é\rV\200\000\000\000\000(p\233\000\000\000\000\000\0006X\200\000\000\000\000¸ãÿÿÿ\177", '\0' <repeats 11 times>, "äÿÿÿ\177\000\000{", '\0' <repeats 15 times>, "\001\000\000\000\000\000\000\000ÄI<\a\000\000\000\000\001\fV\200\000\000\000\000\000ðW\200\000\000\000\000\000òW\200\000\000\000\000\000ôW\200"...
        prepend_file_p = (zend_file_handle *) 0x0
        append_file_p = (zend_file_handle *) 0x0
        prepend_file = {type = ZEND_HANDLE_FILENAME, filename = 0x0, opened_path = 0x0, handle = {fd = 0, fp = 0x0, stream = {handle = 0x0, isatty = 0, mmap = {len = 0, pos = 0, map = 0x0, buf = 0x0, old_handle = 0x0, old_closer = 0},
      reader = 0, fsizer = 0, closer = 0}}, free_filename = 0 '\0'}
        append_file = {type = ZEND_HANDLE_FILENAME, filename = 0x0, opened_path = 0x0, handle = {fd = 0, fp = 0x0, stream = {handle = 0x0, isatty = 0, mmap = {len = 0, pos = 0, map = 0x0, buf = 0x0, old_handle = 0x0, old_closer = 0},
      reader = 0, fsizer = 0, closer = 0}}, free_filename = 0 '\0'}
        old_cwd = 0x7fffffffd010 "/array1/compile"
        retval = 0
#7  0x0000000085203a20 in php_handler (r=0x9cb3a0) at /root/compile/php-5.3.2-apache/sapi/apache2handler/sapi_apache2.c:655
        zfd = {type = ZEND_HANDLE_MAPPED, filename = 0x9cc678 "/usr/local/www/vhosts/grusp.org/www/index.php", opened_path = 0x0, handle = {fd = 7419736, fp = 0x713758, stream = {handle = 0x713758, isatty = 0, mmap = {len = 980,
        pos = 0, map = 0x0, buf = 0x80585000 <Address 0x80585000 out of bounds>, old_handle = 0x0, old_closer = 0}, reader = 0x8513cad0 <_php_stream_read>, fsizer = 0x85128cf0 <php_zend_stream_fsizer>,
      closer = 0x85128ce0 <php_zend_stream_mmap_closer>}}, free_filename = 0 '\0'}
        __bailout = {{_sjb = {2233481406, 2239891776, 140737488348616, 7131832, 10269600, 0, 4500992, 4501016, 10224511, 4461031, 10270232, 0}}}
        ctx = (php_struct * volatile) 0x9cca28
        conf = (void *) 0x9cab88
        brigade = (apr_bucket_brigade * volatile) 0x9cd770
        bucket = (apr_bucket *) 0x0
        rv = 0
        parent_req = (request_rec * volatile) 0x0
#8  0x0000000000436c8e in ap_run_handler ()
No symbol table info available.
#9  0x00000000004372ae in ap_invoke_handler ()
No symbol table info available.
#10 0x0000000000444734 in ap_internal_redirect ()
No symbol table info available.
#11 0x0000000084c1486c in handler_redirect () from /usr/local/libexec/apache22/mod_rewrite.so
No symbol table info available.
---Type <return> to continue, or q <return> to quit---
#12 0x0000000000436c8e in ap_run_handler ()
No symbol table info available.
#13 0x00000000004372ae in ap_invoke_handler ()
No symbol table info available.
#14 0x000000000044408c in ap_process_request ()
No symbol table info available.
#15 0x0000000000441a14 in ap_process_http_connection ()
No symbol table info available.
#16 0x000000000043dd1e in ap_run_process_connection ()
No symbol table info available.
#17 0x000000000043e0b8 in ap_process_connection ()
No symbol table info available.
#18 0x0000000000448c9e in child_main ()
No symbol table info available.
#19 0x0000000000448d8a in make_child ()
No symbol table info available.
#20 0x0000000000449266 in ap_mpm_run ()
No symbol table info available.
#21 0x0000000000423754 in main ()
No symbol table info available.


Patches

php_mysql_fetch_hash.patch (last revision 2010-12-02 02:56 UTC by php at group dot apple dot com)
arches.patch (last revision 2010-12-02 02:55 UTC by php at group dot apple dot com)

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2010-03-09 20:20 UTC] mbeccati@php.net
-Assigned To: +Assigned To: mysql
 [2010-03-29 21:03 UTC] mgarrison at alienz dot net
I'm also able to reproduce this but with custom code, replicated with 5.3.2 and 
php5.3-201003291630 on a CentOS 4.8 box. Doesn't happen in php 5.2.12.

(gdb) bt
#0  0x00007fdcc37cdac3 in zend_fetch_resource (passed_id=0x7fffd484e6a0, 
default_id=-1, resource_type_name=0x7fdcc3a8ce08 "MySQL result", 
found_resource_type=0x0, num_resource_types=1)
    at /usr/src/php-5.3.2/Zend/zend_list.c:127
#1  0x00007fdcc3651846 in php_mysql_fetch_hash (ht=2, 
return_value=0x7fdcbf0e2970, return_value_ptr=Variable "return_value_ptr" is not 
available.
) at /usr/src/php-5.3.2/ext/mysql/php_mysql.c:1944
#2  0x00007fdcc3651dcb in zif_mysql_fetch_array (ht=-729487712, 
return_value=0xffffffff, return_value_ptr=0x7fdcc37cd9cf, this_ptr=0x0, 
return_value_used=1)
    at /usr/src/php-5.3.2/ext/mysql/php_mysql.c:2105
#3  0x00007fdcc37e2c62 in zend_do_fcall_common_helper_SPEC 
(execute_data=0x7fdcc2b34310) at /usr/src/php-5.3.2/Zend/zend_vm_execute.h:313
#4  0x00007fdcc37e2089 in execute (op_array=0x7fdcbf4841c8) at /usr/src/php-
5.3.2/Zend/zend_vm_execute.h:104
#5  0x00007fdcc37c0345 in zend_execute_scripts (type=8, retval=0x0, 
file_count=3) at /usr/src/php-5.3.2/Zend/zend.c:1194
#6  0x00007fdcc376e67d in php_execute_script (primary_file=0x7fffd4850da0) at 
/usr/src/php-5.3.2/main/main.c:2260
#7  0x00007fdcc3845d12 in apache_php_module_main (r=Variable "r" is not 
available.
) at /usr/src/php-5.3.2/sapi/apache/sapi_apache.c:53
#8  0x00007fdcc38468ce in send_php (r=0xcec3d0, display_source_mode=0, 
filename=0x0) at /usr/src/php-5.3.2/sapi/apache/mod_php5.c:682
#9  0x00007fdcc3846ac3 in send_parsed_php (r=0x7fffd484e6a0) at /usr/src/php-
5.3.2/sapi/apache/mod_php5.c:697
#10 0x00000000004428e4 in ap_invoke_handler ()
#11 0x000000000045a74e in process_request_internal ()
#12 0x000000000045ac19 in ap_internal_redirect ()
#13 0x00007fdcc3ee7f7c in mod_gzip_redir1_handler () from 
/var/www/libexec/mod_gzip.so
#14 0x00007fdcc3ee61eb in mod_gzip_handler () from /var/www/libexec/mod_gzip.so
#15 0x00000000004428e4 in ap_invoke_handler ()
#16 0x000000000045a74e in process_request_internal ()
#17 0x000000000045a7a3 in ap_process_request ()
#18 0x0000000000450a06 in child_main ()
#19 0x0000000000450cf1 in make_child ()
#20 0x000000000045109e in perform_idle_server_maintenance ()
#21 0x00000000004516c3 in standalone_main ()
#22 0x0000000000451cb7 in main ()
 [2010-04-08 16:50 UTC] andrey@php.net
-Status: Assigned +Status: Feedback
 [2010-04-08 16:50 UTC] andrey@php.net
Do you use libmysql or mysqlnd as the underlying library? if mysqlnd then can you try a debug build and put into your php.ini : mysqlnd.debug="t:o,/tmp/mysqlnd.trace" . Then please mail me the trace file because it won't be small.
Thanks!

Andrey
 [2010-04-08 16:57 UTC] mbeccati@php.net
I've been using libmysql, but IIRC I've also tried mysqlnd and had the same result. As soon as I have time, I'll try to make a test build with mysqlnd and generate the trace file.
 [2010-04-09 09:27 UTC] mbeccati@php.net
I've been able to test the drush script with a newly compiled 5.3.2 w/ mysqlnd and it appears that the segmentation fault is gone. Is there any way I can trace what happens with libmysql?

i.e.

libmysql:
$ /usr/local/bin/php ~/bin/drush/drush.php dis twitter
The following projects will be disabled: twitter
Do you really want to continue? (y/n): y
Segmentation fault: 11 (core dumped)

mysqlnd:
$ /array1/compile/php-5.3.2-apache/sapi/cli/php -d mysqlnd.debug="t:o,/tmp/mysqlnd.trace" ~/bin/drush/drush.php dis twitter
The following projects will be disabled: twitter
Do you really want to continue? (y/n): y
twitter was disabled successfully.                                   [ok]
 [2010-08-24 20:14 UTC] chris at chrischarlton dot us
Drupal 6.14 was the first 6.x to start supporting PHP 5.3, but mileage will vary. 
It is highly recommended to run Drupal on a PHP 5.2.x server. Of course Drupal will 
natively support PHP 5.3, there are just a few kinks being worked out.
 [2010-08-25 10:22 UTC] mbeccati@php.net
-Status: Feedback +Status: Open
 [2010-08-25 10:22 UTC] mbeccati@php.net
@Chris: I understand that Drupal and PHP 5.3 might not live happily together, but I'd expect errors, not segmentation faults.

@Andrey: Is there anything I can do to help understanding what happens on when using libmysql?
 [2010-08-25 10:32 UTC] pajoye@php.net
Latest drupal (6+) versions work with 5.3 smoothly.
 [2010-08-26 13:27 UTC] uw@php.net
Please try to provide a short test script, like its good style with every other bug report.
 [2010-08-27 22:00 UTC] php at group dot apple dot com
This reproduces on Mac OS X, and appears to be a stack overflow issue. I enabled 
stack overflow protection by adding "-g -fstack-protector-all" to the CFLAGS passed 
to configure. (The problem does not reproduce when configured with --enable-debug 
or -O0 instead of -Os.) In running this through gdb, the following line in changes 
execute_data and may be the start of the corruption:
  zend_vm_execute.h:301			EX_T(opline->result.u.var).var.ptr_ptr = 
&EX_T(opline->result.u.var).var.ptr;

With the following sample script, the third pass through 
zend_do_fcall_common_helper_SPEC() demonstrates the crash:

<?php

$db_host = 'localhost';
$db_user = 'mysql_dba';
$db_password = 'admin';
$db_port = '3306';

$db_conn = mysql_connect($db_host.':'.$db_port, $db_user, $db_password);

$db_result = mysql_query('select version() as version;', $db_conn);

$row = mysql_fetch_array($db_result, MYSQL_ASSOC); // this does NOT work
// $row = mysql_fetch_assoc($db_result); // this works

printf("mysql version: %s\n", $row['version']);

mysql_free_result($db_result);

mysql_close($db_conn);

?>
 [2010-09-01 16:05 UTC] andrey@php.net
valgrind output would be helpful :)
Thanks!
 [2010-09-02 00:49 UTC] php at group dot apple dot com
Does the request for valgrind mean you are unable to reproduce the behavior with -
fstack-protector-all?
 [2010-09-03 18:16 UTC] mbeccati@php.net
I've tried to use -fstack-protector-all both on FreeBSD 6.2 amd64 and Ubuntu Linux x64 and I can't see any segfaults, nor valgrind errors (tested on linux only) using the provided script.
 [2010-09-04 20:54 UTC] php at group dot apple dot com
As I noted, the problem disappears when compiled debug, so perhaps that option was 
enabled in your build?

Since valgrind reports heap issues and this appears to be stack corruption, what 
data are you looking for? Mac OS X has a number of great debugging and analysis 
tools (Instruments, Shark, dtrace) I can use to get what you need.
 [2010-09-24 20:38 UTC] janinemueller26 at gmail dot com
I had also a mysql error with drupal and mysql on http://www.sportwettentipp.com, 
but update to the newest version and works fine, thanks for the bug fixing.
 [2010-09-30 11:53 UTC] aaphp at mailinator dot com
Received this using 5.3.3 on Apache 2.2.16 w/ Cpanel; CENTOS 4.8 x86_64 and osCommerce.

Caused segfaults logged to /var/log/messages:
Sep 29 20:23:22 hostname kernel: conftest[30619]: segfault at 0000000000000001 rip 0000000000405dae rsp 0000007fbffff250 error 4
Sep 29 21:36:28 hostname kernel: php[20444]: segfault at 0000002a00000014 rip 0000000000741da3 rsp 0000007fbfffabb0 error 4

And php errors in /var/log/httpd/error_log:
[Wed Sep 29 20:28:02 2010] [error] [client x.x.x.x] Premature end of script headers: php5

The errors are consistent - nothing loads on the site but 500 Internal Server Errors.  Did not go away until PHP was downgraded to 5.2.14 or the following change made to the script:

The Line:
return mysql_fetch_array($db_query, MYSQL_ASSOC);

Once changed to:
return mysql_fetch_assoc($db_query);

The error ceases & site functions as expected.
 [2010-10-06 13:52 UTC] andrey@php.net
I get no crash on Ubuntu 9.10 x86, PHP 5.3.4-dev, MySQL 5.1.51 . Neither with libmysql nor with mysqlnd, but by looking at the stacktrace it should not matter much. Will get it checked on Mac OS
 [2010-10-06 13:54 UTC] andrey@php.net
forgot to mention that I used the -g -fstack-protector-all
 [2010-10-06 14:17 UTC] andrey@php.net
No crash on 64bit MacOS X 10.6.4 , with or without the flags, libmysql. MySQL is 5.5.2
 [2010-10-07 04:33 UTC] php at group dot apple dot com
Thank you for attempting to reproduce on Mac OS X. The issue may be the choice of 
compiler, as the problem more readily reproduces with LLVM, which claims to be 
much more aggressive in its stack protection than GCC. One option would be to try 
to build using LLVM as the compiler, i.e.:
  CC=/usr/bin/llvm-gcc ./configure ...
 [2010-10-13 12:33 UTC] andrey@php.net
-Status: Assigned +Status: Feedback
 [2010-10-13 12:33 UTC] andrey@php.net
Again, no crash

andrey@vihren:~/dev/php5.3-201010130830> $ ./php a.php
mysql version: 5.1.44
andrey@vihren:~/dev/php5.3-201010130830> $ cat config.nice
#! /bin/sh
#
# Created by configure

CC='/usr/bin/llvm-gcc' \
'./configure' \
'--with-mysql=mysqlnd' \
'--with-mysqli=mysqlnd' \
'--disable-libxml' \
'--disable-dom' \
'--disable-simplexml' \
'--disable-xml' \
'--disable-xmlreader' \
'--disable-xmlwriter' \
'--without-pear' \
"$@"


andrey@vihren:~/dev/php5.3-201010130830> $ uname -a
Darwin vihren 10.4.0 Darwin Kernel Version 10.4.0: Fri Apr 23 18:28:53 PDT 2010; root:xnu-1504.7.4~1/RELEASE_I386 i386

The system is a MacOS X 10.6.something
 [2010-10-15 00:57 UTC] php at group dot apple dot com
Here are the configure flags I use:
------
            --with-apxs2=$(USRSBINDIR)/apxs \
            --enable-cli \
            --with-config-file-path=/etc \
            --with-libxml-dir=$(USRDIR) \
            --with-openssl=$(USRDIR) \
            --with-kerberos=$(USRDIR) \
            --with-zlib=$(USRDIR) \
            --enable-bcmath \
            --with-bz2=$(USRDIR) \
            --enable-calendar \
            --with-curl=$(USRDIR) \
            --enable-exif \
            --enable-ftp \
            --with-gd \
                --with-freetype-dir=$(DSTROOT)$(USRDIR)/local \
                --with-jpeg-dir=$(DSTROOT)$(USRDIR)/local \
                --with-png-dir=$(DSTROOT)$(USRDIR)/local \
                --enable-gd-native-ttf \
            --with-ldap=$(USRDIR) \
                --with-ldap-sasl=$(USRDIR) \
            --enable-mbstring \
            --enable-mbregex \
            --with-mysql=mysqlnd \
            --with-mysqli=mysqlnd \
            --with-pdo-mysql=mysqlnd \
                --with-mysql-sock=/var/mysql/mysql.sock \
            --with-iodbc=$(USRDIR) \
            --enable-shmop \
            --with-snmp=$(USRDIR) \
            --enable-soap \
            --enable-sockets \
            --enable-suhosin \
            --enable-sysvmsg --enable-sysvsem --enable-sysvshm \
            --with-xmlrpc \
                --with-iconv-dir=$(USRDIR) \
            --with-xsl=$(USRDIR) \
            --enable-zend-multibyte \
            --enable-zip
------
It may be relevant that I have applied the Suhosin patch to the sources. I will inspect the patch to see if 
it's modifying the crashing code in some way.

In addition, I set CFLAGS="-Os -g -fstack-protector-all" before calling configure.

I will build again and see if I can tease out more information.
 [2010-10-27 16:11 UTC] johizzle at gmail dot com
I found that recompiling it with --enable-debug fixed the issue of the mysql_fetch_array($var,MYSQL_ASSOC); causing a segmentation fault(11).

It's also good to note, that I installed mysql-client-community rpm, as well.

RHEL 4.8 
Apache/2.2.17 (Unix) mod_ssl/2.2.17 OpenSSL/0.9.7a PHP/5.3.3
 [2010-11-18 08:27 UTC] php at group dot apple dot com
I think I may have discovered the culprit: mistaken architecture information! Here are 
sample runs using different architectures:
# arch -i386 /usr/bin/php /build/mysql_fetch_array_8264855.php
mysql version: 5.0.91-log
# arch -x86_64 /usr/bin/php /build/mysql_fetch_array_8264855.php
zsh: segmentation fault  arch -x86_64 /usr/bin/php /build/mysql_fetch_array_8264855.php


Mac OS X builds "fat", i.e. multiple-architectures in a single compilation pass by 
passing "-arch i386 -arch x86_64". The system headers properly handle the data size 
differences, but projects which depend upon configure's evaluation of data sizes 
instead of system headers such as <stdint.h> are often bit by this. The problem is 
exacerbated by configure's test to determine if it is cross-compiling; since Mac OS X 
can build and run both i386 and x86_64, configure ignores the cross-compilation 
directive and determines the results from the runtime.

I will post more once I get a feeling for how pervasive the changes may be.
 [2010-11-30 06:38 UTC] php at group dot apple dot com
The multi-architecture problem, while valid and now correct, did not address the 
crash. I continue to investigate.
 [2010-12-02 03:54 UTC] php at group dot apple dot com
I found the problem and have created two patch files. One (arches.patch) addresses 
the broader architectural problems of multi-architecture builds. The second 
(php_mysql_fetch_hash.patch) addresses the flaw which causes this crash, namely 
that a long is written to an int.
 [2010-12-02 05:45 UTC] php at group dot apple dot com
The second patch is the same patch applied for http://bugs.php.net/bug.php?
id=52636, which is included with 5.3.4RC1.

The first patch does not appear to be in the source tree yet.
 [2013-02-18 00:34 UTC] php-bugs at lists dot php dot net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Dec 03 03:01:29 2024 UTC