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


Previous Comments:
------------------------------------------------------------------------
[2010-11-30 06:38:01] php at group dot apple dot com

The multi-architecture problem, while valid and now correct, did not
address the 

crash. I continue to investigate.

------------------------------------------------------------------------
[2010-11-18 08:27:53] php at group dot apple dot com

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.

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

------------------------------------------------------------------------


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

Reply via email to