Configure Command =>  './configure'  '--prefix=/usr/lib/php5' '--host=i686-pc-linux-gnu' '--mandir=/usr/lib/php5/man' '--infodir=/usr/lib/php5/info' '--sysconfdir=/etc' '--cache-file=./config.cache' '--enable-cli' '--disable-cgi' '--with-config-file-path=/etc/php/cli-php5' '--with-config-file-scan-dir=/etc/php/cli-php5/ext-active' '--without-pear' '--disable-bcmath' '--with-bz2' '--disable-calendar' '--without-curl' '--without-curlwrappers' '--disable-dbase' '--enable-exif' '--without-fbsql' '--without-fdftk' '--disable-filter' '--enable-ftp' '--with-gettext' '--without-gmp' '--disable-hash' '--disable-json' '--without-kerberos' '--enable-mbstring' '--without-mcrypt' '--with-mhash' '--without-msql' '--without-mssql' '--with-ncurses' '--with-openssl' '--with-openssl-dir=/usr' '--disable-pcntl' '--disable-pdo' '--with-pgsql' '--disable-posix' '--without-pspell' '--without-recode' '--disable-simplexml' '--disable-shmop' '--with-snmp' '--disable-soap' '--enable-sockets' '--without-sybase' '--without-sybase-ct' '--disable-sysvmsg' '--disable-sysvsem' '--disable-sysvshm' '--without-tidy' '--disable-tokenizer' '--disable-wddx' '--disable-xmlreader' '--disable-xmlwriter' '--without-xmlrpc' '--without-xsl' '--enable-zip' '--with-zlib' '--disable-debug' '--enable-dba' '--without-cdb' '--with-db4' '--without-flatfile' '--with-gdbm' '--without-inifile' '--without-qdbm' '--with-freetype-dir=/usr' '--with-t1lib=/usr' '--disable-gd-jis-conv' '--with-jpeg-dir=/usr' '--with-png-dir=/usr' '--without-xpm-dir' '--with-gd' '--with-imap' '--with-imap-ssl' '--with-ldap' '--without-ldap-sasl' '--with-mysql=/usr' '--with-mysql-sock=/var/run/mysqld/mysqld.sock' '--without-mysqli' '--with-readline' '--without-libedit' '--without-mm' '--without-sqlite' '--with-pic'

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with <?php and ends with ?>,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.

Narrowed it down. This test triggers the segfault :

php -r 'echo mysql_connect('localhost', 'root', 'password', true, 128);'

Ok, I narrowed it down further. The problem only occurs
  * on x86 machines (not reproducible on amd64)
  * when using gcc optimizations (-O2 for example)
  * --with-pic

So, reproduce case:
unpack a recent 5.2 snapshot (I used php5.2-200802112130)
(on x86):
export CFLAGS=-O2
./configure --disable-all --with-mysql --with-pic && make
./sapi/cli/php -r 'mysql_connect("host", "user", "pass", true);'

Omitting the forth parameter (`true') does not trigger the problem. The values of the first three parameters doesn't matter, it segfaults even if mysql fails to connect.

Backtrace for that concrete code snippet:
Starting program: /tmp/php5.2-200802112130/sapi/cli/php -r mysql_connect\(\"host\",\ \"user\",\ \"pass\",\ true\)\;

Warning: mysql_connect(): Unknown MySQL server host 'host' (1) in Command line code on line 1

Program received signal SIGSEGV, Segmentation fault.
zend_do_fcall_common_helper_SPEC (execute_data=0xbfd98bec)
    at /tmp/php5.2-200802112130/Zend/zend_vm_execute.h:205
205                     EG(current_execute_data) = execute_data;
(gdb) bt
#0  zend_do_fcall_common_helper_SPEC (execute_data=0xbfd98bec)
    at /tmp/php5.2-200802112130/Zend/zend_vm_execute.h:205
#1  0x0817fb48 in execute (op_array=0x82d3070) at /tmp/php5.2-200802112130/Zend/zend_vm_execute.h:92
#2  0x081525b4 in zend_eval_string (
    str=0xbfd9a3d0 "mysql_connect(\"host\", \"user\", \"pass\", true);", retval_ptr=0x0, 
    string_name=0x825a72f "Command line code")
    at /tmp/php5.2-200802112130/Zend/zend_execute_API.c:1171
#3  0x0815270b in zend_eval_string_ex (
    str=0xbfd9a3d0 "mysql_connect(\"host\", \"user\", \"pass\", true);", retval_ptr=0x0, 
    string_name=0x825a72f "Command line code", handle_exceptions=1)
    at /tmp/php5.2-200802112130/Zend/zend_execute_API.c:1205
#4  0x081e7051 in main (argc=3, argv=0xbfd98fd4) at /tmp/php5.2-200802112130/sapi/cli/php_cli.c:1179


Full backtrace: http://home.hoffie.info/php-5.2-snap-pic-segfault.txt

I suspect that mysql is not the cause of the problem here, it rather seems like one way to trigger that bug. We have reports from sparc/sparc64 users for whom recent php-5.2 snapshots simply crash, independent of the code used. Might be the same bug in the background, who knows.

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.