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 ()

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

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.

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]

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.

@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?

Latest drupal (6+) versions work with 5.3 smoothly.

Please try to provide a short test script, like its good style with every other bug report.

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);

?>

valgrind output would be helpful :)
Thanks!

Does the request for valgrind mean you are unable to reproduce the behavior with -
fstack-protector-all?

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.

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.

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.

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.

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

forgot to mention that I used the -g -fstack-protector-all

No crash on 64bit MacOS X 10.6.4 , with or without the flags, libmysql. MySQL is 5.5.2

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 ...

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

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.

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

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.

The multi-architecture problem, while valid and now correct, did not address the 
crash. I continue to investigate.

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.

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.

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.