php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #23490 mysql_fetch_field causes segfault
Submitted: 2003-05-05 07:52 UTC Modified: 2004-06-05 19:03 UTC
Votes:6
Avg. Score:3.8 ± 0.9
Reproduced:6 of 6 (100.0%)
Same Version:2 (33.3%)
Same OS:2 (33.3%)
From: michi102 at gmx dot de Assigned:
Status: Not a bug Package: MySQL related
PHP Version: 4.3.1 OS: SuSE 7.3
Private report: No CVE-ID: None
 [2003-05-05 07:52 UTC] michi102 at gmx dot de
Server conf: apache 1.3.27, php 4.3.1, MySQL 4.0.12, phpMyAdmin 2.4.0

Whenever I try to use mysql_fetch_field, I'll get a segmentation fault. I recognized this first when using phpMyAdmin to query the database via "Browse". Then I tried using mysql_fetch_field in own scripts - same result.
Example:
$result = mysql_query("select * from admin";$db);
while ($field = mysql_fetch_field($result)) {
                $fields_meta[] = $field;
            }

It doesn't matter what I do inside the while loop - the result is always the same: segfault.

My php config string:
'./configure' '--with-apxs=/usr/local/httpd/bin/apxs' '--bindir=/usr/bin' '--libdir=/usr/lib' '--with-config-file-path=/etc' '--with-exec-dir=%{libdir}/php/bin' '--with-open-ssl' '--enable-sockets' '--with-mysql=/usr' '--enable-bcmath' '--enable-calendar' '--with-ftp' '--enable-wddx' '--with-zlib' '--with-zlib-dir=/usr' '--with-jpeg-dir=/usr' '--with-png-dir=/usr' '--with-gd' '--with-freetype-dir=/usr' '--enable-gd-native-ttf' '--with-imap=/usr' '--with-imap-ssl=/usr' '--with-xpm-dir=/usr/X11R6' '--with-tiff-dir=/usr' '--enable-exif' '--enable-ctype' '--enable-dba' '--with-mcrypt' '--disable-rpath' '--enable-shmop' '--enable-sysvsem' '--enable-sysvshm' '--enable-track-vars' '--enable-sysvmsg' '--enable-track-vars' '--enable-magic-quotes' '--enable-versioning' '--enable-sigchild' '--disable-debug' '--enable-trans-sid' '--enable-pcntl' '--enable-memory-limit' '--enable-force-cgi-redirect' '--enable-discard-path' '--enable-sigchild'

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-05-05 08:10 UTC] derick@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.
 [2003-05-14 11:02 UTC] sniper@php.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.


 [2003-12-08 16:48 UTC] gavin at vess dot com
I am running 4.3.4 with MySQL 4.0.11 and have experienced exactly the same problem using phpMyAdmin 2.5.1.  I also experienced the same problem with 4.3.3.  I'm using Red Hat Linux 7.x with FastCGI and a slew of other options enabled and many enhancements, but none directly related to this bug.

I have a backtrace, and I've tracked the problem down to bad data returned by a MySQL call.  On line 2154 the mysql_fetch_field returns the a MYSQL_FIELD structure with two suprising values (not element values for db and def below).  Since def is supposed to be a string, on line 2163, PHP's check fails to catch the bad value 0x4 resulting in a later attempt to access this memory address.

Now .. why is mysql_fetch_field() returning 0x4 as a value for def .. I'll see what I can find, but if the answer doesn't come easy, then I'm just going to upgrade MySQL to the current version and see if that fixes this problem.  MySQL's documentation for MYSQL_FIELD isn't exactly complete: http://www.mysql.com/doc/en/C_API_datatypes.html

(gdb) print *mysql_field
$1 = {name = 0x83080f0 "ID_CAT", table = 0x83080e0 "yse_boards", org_table = 0x0,
  db = 0x1 <Address 0x1 out of bounds>, def = 0x4 <Address 0x4 out of bounds>, length = 1, max_length = 49161,
  flags = 0, decimals = 137396488, type = 137396472}


My backtrace:

#0  zif_mysql_fetch_field (ht=1, return_value=0x846d60c, this_ptr=0x0, return_value_used=1)
    at /admin/admin/php/php-4.3.4debug/ext/mysql/php_mysql.c:2157
#1  0x081d2071 in execute (op_array=0x83a1e70) at /admin/admin/php/php-4.3.4debug/Zend/zend_execute.c:1616
#2  0x081d2276 in execute (op_array=0x83b44b4) at /admin/admin/php/php-4.3.4debug/Zend/zend_execute.c:1660
#3  0x081c0c4e in zend_execute_scripts (type=8, retval=0x0, file_count=3)
    at /admin/admin/php/php-4.3.4debug/Zend/zend.c:884
#4  0x0818c551 in php_execute_script (primary_file=0xbfffe6d0) at /admin/admin/php/php-4.3.4debug/main/main.c:1729
#5  0x081df532 in main (argc=5, argv=0xbfffe774) at /admin/admin/php/php-4.3.4debug/sapi/cgi/cgi_main.c:2007
#6  0x401ea657 in __libc_start_main (main=0x81de030 <main>, argc=5, ubp_av=0xbfffe774, init=0x806c9d0 <_init>,
    fini=0x81e0040 <_fini>, rtld_fini=0x4000dcd4 <_dl_fini>, stack_end=0xbfffe76c)
    at ../sysdeps/generic/libc-start.c:129


2154            if ((mysql_field=mysql_fetch_field(mysql_result))==NULL) {
2155                    RETURN_FALSE;
2156            }
2157            if (object_init(return_value)==FAILURE) {
2158                    RETURN_FALSE;
2159            }
2160
2161            add_property_string(return_value, "name",(mysql_field->name?mysql_field->name:empty_string), 1);
2162            add_property_string(return_value, "table",(mysql_field->table?mysql_field->table:empty_string), 1);
2163            add_property_string(return_value, "def",(mysql_field->def?mysql_field->def:empty_string), 1);
 [2003-12-08 18:30 UTC] gavin at vess dot com
Bingo!  Upgrading to mysql-standard-4.0.16-pc-linux-i686.tar.gz and recompiling PHP 4.3.4 linked against the new mysql libs fixed it .. much simpler than debugging MySQL to figure out exactly why mysql_fetch_field returned a string pointer with a value of 0x4.
 [2004-06-01 14:10 UTC] bool at boolsite dot net
I have the same problem too, but with PHP 4.3.6 and MySQL 4.0.20 (binary and compiled version) under a Debian Sarge.

Should I give a backtrace too ?
 [2004-06-02 03:12 UTC] bool at boolsite dot net
So the backtrace :

#0  0x40428c0f in strlen () from /lib/libc.so.6
#1  0x08218fb1 in add_property_string_ex (arg=0x844e744, key=0x82d5e53 "def", key_len=4,
    str=0xa <Address 0xa out of bounds>, duplicate=1) at /usr/local/src/php-4.3.6/Zend/zend_API.c:978
#2  0x081040ed in zif_mysql_fetch_field (ht=2, return_value=0x844e744, this_ptr=0x0, return_value_used=1)
    at /usr/local/src/php-4.3.6/ext/mysql/php_mysql.c:2163
#3  0x0822980f in execute (op_array=0x8449694) at /usr/local/src/php-4.3.6/Zend/zend_execute.c:1635
#4  0x0821600c in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/local/src/php-4.3.6/Zend/zend.c:886
#5  0x081daf0c in php_execute_script (primary_file=0xbffffa60) at /usr/local/src/php-4.3.6/main/main.c:1731
#6  0x0823066d in main (argc=2, argv=0xbffffb04) at /usr/local/src/php-4.3.6/sapi/cli/php_cli.c:822


I don't I it can help you, but this is the "frames" :
(gdb) frame 0
#0  0x40428c0f in strlen () from /lib/libc.so.6
(gdb) frame 1
#1  0x08218fb1 in add_property_string_ex (arg=0x844e744, key=0x82d5e53 "def", key_len=4,
    str=0xa <Address 0xa out of bounds>, duplicate=1) at /usr/local/src/php-4.3.6/Zend/zend_API.c:978
978             ZVAL_STRING(tmp, str, duplicate);
(gdb) frame 2
#2  0x081040ed in zif_mysql_fetch_field (ht=2, return_value=0x844e744, this_ptr=0x0, return_value_used=1)
    at /usr/local/src/php-4.3.6/ext/mysql/php_mysql.c:2163
2163            add_property_string(return_value, "def",(mysql_field->def?mysql_field->def:empty_string), 1);
(gdb) frame 3
#3  0x0822980f in execute (op_array=0x8449694) at /usr/local/src/php-4.3.6/Zend/zend_execute.c:1635
1635                                                            ((zend_internal_function *) EX(function_state).function)->handler(EX(opline)->extended_value, EX(Ts)[EX(opline)->result.u.var].var.ptr, EX(object).ptr, return_value_used TSRMLS_CC);


I tried to reinstall the binary version of MySQL 4.0.20, and I have always the same bug. I tried PHP 4.3.7RC1 too, and it's the same.
 [2004-06-05 19:03 UTC] georg@php.net
When using MySQL 4.0.x you also have to compile PHP with 4.0.20 client library.

There are incompatibilities with MYSQL_FIELD structure between 3.23.x and 4.0.x.
 [2004-06-07 00:13 UTC] bool at boolsite dot net
So... I found old mysql client lib in /usr/lib (because of the libmysqlclient10 of the debian) and remove it... All works fine now. Thanks.

But, with the "configure" script, the argument "--with-mysql=/usr/local/mysql" was given but myclient never been token in "/usr/local/mysql/lib/". Strange no ?
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue May 07 23:01:35 2024 UTC