Edit report at http://bugs.php.net/bug.php?id=51248&edit=1
ID: 51248
Comment by: janinemueller26 at gmail dot com
Reported by: mbeccati@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] 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-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] andrey@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