Bug #51248 [Com]: Segmentation fault in mysql_fetch_array
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: 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. Previous Comments: [2010-12-02 03:54:35] php at group dot apple dot com 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. [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 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. The remainder of the comments for this report a
Bug #51248 [Com]: Segmentation fault in mysql_fetch_array
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 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' \ '--disa
Bug #51248 [Com]: Segmentation fault in mysql_fetch_array
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: The multi-architecture problem, while valid and now correct, did not address the crash. I continue to investigate. Previous Comments: [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 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
Bug #51248 [Com]: Segmentation fault in mysql_fetch_array
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 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
Bug #51248 [Com]: Segmentation fault in mysql_fetch_array
Edit report at http://bugs.php.net/bug.php?id=51248&edit=1 ID: 51248 Comment by: johizzle at gmail 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 New Comment: 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 Previous Comments: [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 [2010-10-06 13:54:59] and...@php.net forgot to mention that I used the -g -fstack-protector-all 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
Bug #51248 [Com]: Segmentation fault in mysql_fetch_array
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 New Comment: 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. Previous Comments: [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 [2010-10-06 13:54:59] and...@php.net forgot to mention that I used the -g -fstack-protector-all [2010-10-06 13:52:59] and...@php.net 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 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
Bug #51248 [Com]: Segmentation fault in mysql_fetch_array
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: 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: 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 ... Previous Comments: [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 [2010-10-06 13:54:59] and...@php.net forgot to mention that I used the -g -fstack-protector-all [2010-10-06 13:52:59] and...@php.net 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 [2010-09-30 11:53:28] aaphp at mailinator dot com 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 0001 rip 00405dae rsp 007fb250 error 4 Sep 29 21:36:28 hostname kernel: php[20444]: segfault at 002a0014 rip 00741da3 rsp 007fbfffabb0 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. [2010-09-24 20:38:23] janinemueller26 at gmail dot com 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. 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
Bug #51248 [Com]: Segmentation fault in mysql_fetch_array
Edit report at http://bugs.php.net/bug.php?id=51248&edit=1 ID: 51248 Comment by: aaphp at mailinator 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: 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 0001 rip 00405dae rsp 007fb250 error 4 Sep 29 21:36:28 hostname kernel: php[20444]: segfault at 002a0014 rip 00741da3 rsp 007fbfffabb0 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. Previous Comments: [2010-09-24 20:38:23] janinemueller26 at gmail dot com 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. [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! 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
Bug #51248 [Com]: Segmentation fault in mysql_fetch_array
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: 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
Bug #51248 [Com]: Segmentation fault in mysql_fetch_array
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: 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: 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. Previous Comments: [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: [2010-08-26 13:27:05] u...@php.net Please try to provide a short test script, like its good style with every other bug report. 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
Bug #51248 [Com]: Segmentation fault in mysql_fetch_array
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: 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: Does the request for valgrind mean you are unable to reproduce the behavior with - fstack-protector-all? Previous Comments: [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: [2010-08-26 13:27:05] u...@php.net Please try to provide a short test script, like its good style with every other bug report. [2010-08-25 10:32:16] paj...@php.net Latest drupal (6+) versions work with 5.3 smoothly. [2010-08-25 10:22:29] mbecc...@php.net @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? 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
Bug #51248 [Com]: Segmentation fault in mysql_fetch_array
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: 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: 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: Previous Comments: [2010-08-26 13:27:05] u...@php.net Please try to provide a short test script, like its good style with every other bug report. [2010-08-25 10:32:16] paj...@php.net Latest drupal (6+) versions work with 5.3 smoothly. [2010-08-25 10:22:29] mbecc...@php.net @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? [2010-08-24 20:14:29] chris at chrischarlton dot us 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. [2010-04-09 09:27:41] mbecc...@php.net 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] 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
Bug #51248 [Com]: Segmentation fault in mysql_fetch_array
Edit report at http://bugs.php.net/bug.php?id=51248&edit=1 ID: 51248 Comment by: chris at chrischarlton dot us 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 New Comment: 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. Previous Comments: [2010-04-09 09:27:41] mbecc...@php.net 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] [2010-04-08 16:57:29] mbecc...@php.net 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. [2010-04-08 16:50:54] and...@php.net 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 [2010-03-29 21:03:43] mgarrison at alienz dot net 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 0x7fdcc37cdac3 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 0x7fdcc3651846 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 0x7fdcc3651dcb in zif_mysql_fetch_array (ht=-729487712, return_value=0x, 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 0x7fdcc37e2c62 in zend_do_fcall_common_helper_SPEC (execute_data=0x7fdcc2b34310) at /usr/src/php-5.3.2/Zend/zend_vm_execute.h:313 #4 0x7fdcc37e2089 in execute (op_array=0x7fdcbf4841c8) at /usr/src/php- 5.3.2/Zend/zend_vm_execute.h:104 #5 0x7fdcc37c0345 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/src/php-5.3.2/Zend/zend.c:1194 #6 0x7fdcc376e67d in php_execute_script (primary_file=0x7fffd4850da0) at /usr/src/php-5.3.2/main/main.c:2260 #7 0x7fdcc3845d12 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 0x7fdcc38468ce 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 0x7fdcc3846ac3 in send_parsed_php (r=0x7fffd484e6a0) at /usr/src/php- 5.3.2/sapi/apache/mod_php5.c:697 #10 0x004428e4 in ap_invoke_handler () #11 0x0045a74e in process_request_internal () #12 0x0045ac19 in ap_internal_redirect () #13 0x7fdcc3ee7f7c in mod_gzip_redir1_handler () from /var/www/libexec/mod_gzip.so #14 0x7fdcc3ee61eb in mod_gzip_handler () from /var/www/libexec/mod_gzip.so #15 0x004428e4 in ap_invoke_handler () #16 0x0045a74e in process_request_internal () #17 0x0045a7a3 in ap_process_request () #18 0x00450a06 in child_main () #19 0x00450cf1 in make_child () #20 0x0045109e in perform_idle_server_maintenance () #21 0x004516c3 in standalone_main () #22 0x00451cb7 in main () [2010-03-09 20:20:13] mbecc...@php.net Description: I've been asked to publish a Drupal based website on my 5.3.2 box, but every page call triggers a segmentation fault. Replicated with 5.3.1 as
Bug #51248 [Com]: Segmentation fault in mysql_fetch_array
Edit report at http://bugs.php.net/bug.php?id=51248&edit=1 ID: 51248 Comment by: mbecc...@php.net 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 New Comment: 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] Previous Comments: [2010-04-08 16:57:29] mbecc...@php.net 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. [2010-04-08 16:50:54] and...@php.net 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 [2010-03-29 21:03:43] mgarrison at alienz dot net 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 0x7fdcc37cdac3 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 0x7fdcc3651846 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 0x7fdcc3651dcb in zif_mysql_fetch_array (ht=-729487712, return_value=0x, 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 0x7fdcc37e2c62 in zend_do_fcall_common_helper_SPEC (execute_data=0x7fdcc2b34310) at /usr/src/php-5.3.2/Zend/zend_vm_execute.h:313 #4 0x7fdcc37e2089 in execute (op_array=0x7fdcbf4841c8) at /usr/src/php- 5.3.2/Zend/zend_vm_execute.h:104 #5 0x7fdcc37c0345 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/src/php-5.3.2/Zend/zend.c:1194 #6 0x7fdcc376e67d in php_execute_script (primary_file=0x7fffd4850da0) at /usr/src/php-5.3.2/main/main.c:2260 #7 0x7fdcc3845d12 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 0x7fdcc38468ce 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 0x7fdcc3846ac3 in send_parsed_php (r=0x7fffd484e6a0) at /usr/src/php- 5.3.2/sapi/apache/mod_php5.c:697 #10 0x004428e4 in ap_invoke_handler () #11 0x0045a74e in process_request_internal () #12 0x0045ac19 in ap_internal_redirect () #13 0x7fdcc3ee7f7c in mod_gzip_redir1_handler () from /var/www/libexec/mod_gzip.so #14 0x7fdcc3ee61eb in mod_gzip_handler () from /var/www/libexec/mod_gzip.so #15 0x004428e4 in ap_invoke_handler () #16 0x0045a74e in process_request_internal () #17 0x0045a7a3 in ap_process_request () #18 0x00450a06 in child_main () #19 0x00450cf1 in make_child () #20 0x0045109e in perform_idle_server_maintenance () #21 0x004516c3 in standalone_main () #22 0x00451cb7 in main () [2010-03-09 20:20:13] mbecc...@php.net Description: I've been asked to publish a Drupal based website on my 5.3.2 box, but every page call triggers a segmentation fault. Replicated with 5.3.1 as well. I've been able to test an old 5.2.8 and the issue is gone. I can't attach a reproduce code, but I will try to gather more information in the next few days. For now I'm attaching the backtrace. Actual result: -- Program received signal SIGSEGV, Segmentation fault. 0x8518a7c3 in zend_fetch_resource (passed_id=0x7fffcc50, default_id=-1, resource_type_name=0x855c3d6f "MySQL
Bug #51248 [Com]: Segmentation fault in mysql_fetch_array
Edit report at http://bugs.php.net/bug.php?id=51248&edit=1
ID: 51248
Comment by: mgarrison at alienz dot net
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
New Comment:
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 0x7fdcc37cdac3 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 0x7fdcc3651846 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 0x7fdcc3651dcb in zif_mysql_fetch_array (ht=-729487712,
return_value=0x, 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 0x7fdcc37e2c62 in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fdcc2b34310) at
/usr/src/php-5.3.2/Zend/zend_vm_execute.h:313
#4 0x7fdcc37e2089 in execute (op_array=0x7fdcbf4841c8) at
/usr/src/php-
5.3.2/Zend/zend_vm_execute.h:104
#5 0x7fdcc37c0345 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/src/php-5.3.2/Zend/zend.c:1194
#6 0x7fdcc376e67d in php_execute_script
(primary_file=0x7fffd4850da0) at
/usr/src/php-5.3.2/main/main.c:2260
#7 0x7fdcc3845d12 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 0x7fdcc38468ce 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 0x7fdcc3846ac3 in send_parsed_php (r=0x7fffd484e6a0) at
/usr/src/php-
5.3.2/sapi/apache/mod_php5.c:697
#10 0x004428e4 in ap_invoke_handler ()
#11 0x0045a74e in process_request_internal ()
#12 0x0045ac19 in ap_internal_redirect ()
#13 0x7fdcc3ee7f7c in mod_gzip_redir1_handler () from
/var/www/libexec/mod_gzip.so
#14 0x7fdcc3ee61eb in mod_gzip_handler () from
/var/www/libexec/mod_gzip.so
#15 0x004428e4 in ap_invoke_handler ()
#16 0x0045a74e in process_request_internal ()
#17 0x0045a7a3 in ap_process_request ()
#18 0x00450a06 in child_main ()
#19 0x00450cf1 in make_child ()
#20 0x0045109e in perform_idle_server_maintenance ()
#21 0x004516c3 in standalone_main ()
#22 0x00451cb7 in main ()
Previous Comments:
[2010-03-09 20:20:13] mbecc...@php.net
Description:
I've been asked to publish a Drupal based website on my 5.3.2 box, but
every page call triggers a segmentation fault. Replicated with 5.3.1 as
well.
I've been able to test an old 5.2.8 and the issue is gone.
I can't attach a reproduce code, but I will try to gather more
information in the next few days. For now I'm attaching the backtrace.
Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
0x8518a7c3 in zend_fetch_resource (passed_id=0x7fffcc50,
default_id=-1, resource_type_name=0x855c3d6f "MySQL result",
found_resource_type=0x0, num_resource_types=1) at
/root/compile/php-5.3.2-apache/Zend/zend_list.c:127
127 } else if ((*passed_id)->type != IS_RESOURCE) {
(gdb) bt full
#0 0x8518a7c3 in zend_fetch_resource (passed_id=0x7fffcc50,
default_id=-1, resource_type_name=0x855c3d6f "MySQL result",
found_resource_type=0x0, num_resource_types=1) at
/root/compile/php-5.3.2-apache/Zend/zend_list.c:127
id = -1
actual_resource_type = 0
resource = (void *) 0x10
resource_types = {{gp_offset = 5, fp_offset = 0,
overflow_arg_area = 0x861c775b, reg_save_area = 0x300020}}
i = -1
space = 0x85185062 "H\201Ãè"
class_name = 0x1
#1 0x84fabcc6 in php_mysql_fetch_hash (ht=2,
return_value=0xb04ae0, return_value_ptr=0x8518a6cf, this_ptr=0x0,
return_value_used=1, result_type=1, expected_args=2, into_object=0)
at /root/compile/php-5.3.2-apache/ext/mysql/php_mysql.c:1944
class_name = 0x7fffcd40 "Ãî©"
class_name_len = 32767
mysql_result = (MYSQL_RES *) 0x2
res = (zval *) 0x0
ctor_params = (zval *) 0x0
ce = (zend_class_entry *) 0x0
i = 17
mysql_field = (MYSQL_FIELD *) 0x0
mysql_row = (MYSQL_ROW) 0xa9eed0
mysql_row_lengths = (long unsigned int *) 0x1
#2 0x84fac24b in zif_mysql_fetch_array (ht=-13232,
return_value=0x, return_value_ptr=0x8518a6c
