From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050524 Fedora/1.0.4-4 Firefox/1.0.4 Description of problem: Whenever I run a php script via httpd that calls the function mysql_connect(), apache will seg-fault and quit. However, running the script at the command line (CLI) works as expected Version-Release number of selected component (if applicable): php-5.0.4-10, httpd-2.0.54-10 How reproducible: Always Steps to Reproduce: 1.create a php script that calls the function mysql_connect 2.load the page created in step 1 in any web browser 3.apache seg-faults, page is not executed Actual Results: Script did not execute. No error message is displayed or logged by php. The only error appears in /var/log/httpd/error_log: [Thu Jun 16 10:20:09 2005] [notice] child pid 6100 exit signal Segmentation fault (11), possible coredump in /tmp Expected Results: Script should have executed, returned a resource link that php can use to run database queries, etc. Additional info: Though this affects all my scripts that use the mysql_connect() call, here's a quick little script I wrote to test: <?php $link = mysql_connect("localhost", "session", "session") or die ("could not connect"); mysql_select_db("session", $link); var_dump($link); echo "Hello World\n"; ?> When run at the command line (# php ./test.php), you get the expected output: resource(7) of type (mysql link) Hello World But when run through apache via a web browser, httpd crashed as described above.
Created attachment 115556 [details] backtrace for this bug Obtained by: # echo "CoreDumpDirectory /tmp" > /etc/httpd/conf.d/coredump.conf # service httpd reload ... trigger segfault... # gdb /usr/sbin/httpd /tmp/core.<pid> ... (gdb) bt full
Is this a fresh install, or an upgrade from FC3? I can't reproduce any problems here with a script that simple (nor more complex MySQL-based PHP applications). What's the output of: # rpm -qa php\* mysql\* # rpm -Va php\* mysql\*
Mark you mentioned on fedora-list that this was fixed after with a fresh install; can you answer one question: - were non-official-Fedora packages of MySQL 4.x installed on the system which was upgraded from FC3? e.g. those downloaded from www.mysql.com
Hi, Joe, sorry I haven't been more responsive :( In any event, both installs were fresh installs, but slightly different. Let me explain: The first fresh install I formatted /, but left both the /home and /var (including /var/mysql, of course) partitions untouched from my previous install. The second install, I backed up /var, installed fresh and formatted everything (except for my /home partition). Then, after the install I restored my databases from my backup, except mysql - to avoid any conflicts, I just recreated all of my users and permissions (fortunately, I didn't have many to restore). At that point, everything worked great. To the best of my knowledge, this workstation has always used the official Fedora MySQL packages. Therefore, this "bug" probably had more to do with my strange install than an actual problem with the packages. Once again, since my second install, everything's been working perfectly. If you wanted to close this bug, I wouldn't take it personally :)
(In reply to comment #3) > Mark you mentioned on fedora-list that this was fixed after with a fresh > install; can you answer one question: > - were non-official-Fedora packages of MySQL 4.x installed on the system which > was upgraded from FC3? e.g. those downloaded from www.mysql.com I am encountering this exact problem now after upgrading from FC3 to FC4. I used the 'yum -y upgrade' approach after upgrading the kernel. After working through a couple of config file changes for httpd and php, I noticed that somehow mysql-server was no longer installed. I installed mysql-server with 'yum install mysql-server' and the database operates normally using the mysql console. However when php accesses the database it always results in a segmentation fault for certain pages. My previous MySQL installation was installed from the following RPMs. I am unsure whether these were FC specific or not. MySQL-server-4.0.24-0.i386.rpm MySQL-devel-4.0.24-0.i386.rpm MySQL-client-4.0.24-0.i386.rpm MySQL-shared-4.0.24-0.i386.rpm MySQL-shared-compat-4.0.24-0.i386.rpm Here is some rpm output: [root@server ~]# rpm -qa php\* mysql\* mysqlclient10-3.23.58-6 mysql-server-4.1.14-1.FC4.1 mysql-devel-4.1.14-1.FC4.1 php-pear-5.0.4-10.4 php-pgsql-5.0.4-10.4 php-ldap-5.0.4-10.4 mysql-4.1.14-1.FC4.1 php-5.0.4-10.4 mysql-debuginfo-4.1.14-1.FC4.1 php-gd-5.0.4-10.4 mysql-bench-4.1.14-1.FC4.1 php-mysql-5.0.4-10.4 You have new mail in /var/spool/mail/root [root@server ~]# rpm -Va php\* mysql\* ..?..... /usr/share/pear/.lock S.5....T c /etc/my.cnf S.5....T c /etc/httpd/conf.d/php.conf S.5....T c /etc/pear.conf .......T c /etc/php.ini Here is the end of an strace on httpd: [pid 3926] stat64("prefixes.php", 0xbf7fc4bc) = -1 ENOENT (No such file or directory) [pid 3926] stat64("prefixes.php", 0xbf7feaec) = -1 ENOENT (No such file or directory) [pid 3926] gettimeofday({1131254251, 689173}, NULL) = 0 [pid 3926] fcntl64(18, F_SETFL, O_RDWR|O_NONBLOCK) = 0 [pid 3926] read(18, 0x94258c8, 8192) = -1 EAGAIN (Resource temporarily unavailable) [pid 3926] fcntl64(18, F_SETFL, O_RDWR) = 0 [pid 3926] write(18, "q\0\0\0\3UPDATE logd_module_userpref"..., 117) = 117 [pid 3926] read(18, "0\0\0\1", 4) = 4 [pid 3926] read(18, "\0\1\0\2\0\0\0(Rows matched: 1 Changed"..., 48) = 48 [pid 3926] gettimeofday({1131254251, 702426}, NULL) = 0 [pid 3926] --- SIGSEGV (Segmentation fault) @ 0 (0) --- [pid 3926] chdir("/etc/httpd") = 0 [pid 3926] rt_sigaction(SIGSEGV, {SIG_DFL}, {SIG_DFL}, 8) = 0 [pid 3926] kill(3926, SIGSEGV) = 0 [pid 3926] sigreturn() = ? (mask now []) [pid 3926] --- SIGSEGV (Segmentation fault) @ 0 (0) --- Process 3926 detached Please help me to get this problem resolved... I really don't want to have to reinstall. Thanks.
I was able to work around this problem by going back to php version 4.3. After downloading the FC3 RPMs this is what I did: yum remove php rpm -ivh --nodeps php-4.3.11-2.7.i386.rpm rpm -ivh php-pear-4.3.11-2.7.i386.rpm rpm -ivh php-devel-4.3.11-2.7.i386.rpm rpm -ivh php-gd-4.3.11-2.7.i386.rpm rpm -ivh php-mysql-4.3.11-2.7.i386.rpm I can always upgrade to 5.0.4-10 again if further testing is needed to resolve the problem.
I suffered the same problem. I found, that crashing script start with <? instead of full tag <?php. When I fix it to <?php everything go right. In my opinion this is php bug.
Do the php cgi version crashes? Look at the mysql-client version at phpinfo in both phpcgi and mod_php.
I am seeing the same problem using FC4 on x86_64. My php related packages: php-5.0.5-2.2 php-bcmath-5.0.5-2.2 php-dba-5.0.5-2.2 php-devel-5.0.5-2.2 php-gd-5.0.5-2.2 php-imap-5.0.5-2.2 php-ldap-5.0.5-2.2 php-mbstring-5.0.5-2.2 php-mysql-5.0.5-2.2 php-ncurses-5.0.5-2.2 php-odbc-5.0.5-2.2 php-pear-5.0.5-2.2 php-pgsql-5.0.5-2.2 php-snmp-5.0.5-2.2 php-soap-5.0.5-2.2 php-xml-5.0.5-2.2 php-xmlrpc-5.0.5-2.2
This report targets the FC3 or FC4 products, which have now been EOL'd. Could you please check that it still applies to a current Fedora release, and either update the target product or close it ? Thanks.
Closing because bug has remained in NEEDINFO state without reply for a long period of time. Note that FC3 and FC4 are supported by Fedora Legacy for security fixes only. Please install a still supported version and retest. If it still occurs on FC5 or FC6, please reopen and assign to the correct version. Otherwise, if this a security issue, please change the product to Fedora Legacy. Thanks, and we are sorry that we did not get to this bug earlier. This bug was originally filed against a much earlier version of Fedora Core, and significant changes have taken place since the last version for which this bug is confirmed. It is very likely that a more recent release of PHP, such as included in current Fedora releases, have fixed the problem.