Edit report at http://bugs.php.net/bug.php?id=51248&edit=1
ID: 51248
Comment by: php at group dot apple dot com
Reported by: mbecc...@php.net
Summary: Segmentation fault in mysql_fetch_array
Status: Feedback
Type: Bug
Package: MySQL related
Operating System: FreeBSD 6.2
PHP Version: 5.3.2
Assigned To: mysql
Block user comment: N
Private report: N
New Comment:
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.
Previous Comments:
------------------------------------------------------------------------
[2010-10-27 16:11:47] 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-10-15 00:57:38] 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-13 12:33:21] and...@php.net
Again, no crash
and...@vihren:~/dev/php5.3-201010130830> $ ./php a.php
mysql version: 5.1.44
and...@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' \
"$@"
and...@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-07 04:33:41] 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-06 14:17:47] and...@php.net
No crash on 64bit MacOS X 10.6.4 , with or without the flags, libmysql.
MySQL is 5.5.2
------------------------------------------------------------------------
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
