Edit report at http://bugs.php.net/bug.php?id=51248&edit=1
ID: 51248 Comment by: janinemueller26 at gmail dot com Reported by: mbecc...@php.net Summary: Segmentation fault in mysql_fetch_array Status: Assigned Type: Bug Package: MySQL related Operating System: FreeBSD 6.2 PHP Version: 5.3.2 Assigned To: mysql Block user comment: N New Comment: 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. Previous Comments: ------------------------------------------------------------------------ [2010-09-04 20:54:38] 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-03 18:16:49] mbecc...@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-02 00:49:49] 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-01 16:05:57] and...@php.net valgrind output would be helpful :) Thanks! ------------------------------------------------------------------------ [2010-08-27 22:00:08] 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); ?> ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=51248 -- Edit this bug report at http://bugs.php.net/bug.php?id=51248&edit=1
