2 php installs - need to make it one

juv123

juv123

Hey everyone, I have an issue I am trying to resolve. I am getting Segmentation fault (11) in my httpd-error.log at random times throughout the day. I have tried several things including commenting out some extensions and reinstalling all extensions, and now I have recompiled php with debug enabled - still getting the faults.
Code: 
[Wed Jan 12 09:00:05 2011] [notice] child pid 97106 exit signal Segmentation fault (11)
I *think* it could be a problem with how I installed PHP. I initially installed the /php52/ port, then deinstalled it and installed /php5/. I ran into problems, as the new PHP install seemed to still see some of the old extensions from the php52 install. So I did a deinstall of all php52 ports then:
# pkg_delete php52*
Not sure if that did anything - as that is when I started noticing the Segmentation faults in my logs. Not knowing what to do, I hired a server management company to help. They reinstalled php. This seemed to stop the segfault.

Now later that week I was doing a:
# portupgrade -a
and it upgraded php from ports. I did a:
# php -v
Which reported 5.2.17 (not 5.3.4 that was installed in ports). A phpinfo() reported 5.3.4. And my segfault had returned! This is when I realized the server management company installed PHP from source and I had 2 installations of php - one in each of the following directories:
5.2:
/usr/bin/php
and 5.3:
/usr/local/bin/php
I asked them to fix it so only the ports versions is installed. They said they did, and I was still getting segmentation faults, so I recompiled php and extensions from ports with debug enabled. This is now what I get:
Code: 
control# php -v
PHP 5.3.4 (cli) (built: Dec 31 2010 03:40:10)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies

control# which php
/usr/bin/php

control# /usr/local/bin/php -v
PHP 5.3.4 (cli) (built: Jan  8 2011 06:51:54) (DEBUG)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies

I am thinking my segfaults could be resulting from cross-mixed dependencies from the installations, but I am not smart enough to try and fix the problem. I was thinking a deinstall and reinstall of apache might be the next step, but is there a way to get all of my PHP to be running from the /usr/local/bin/php directory before I deinstall and reinstall apache?

Any ideas would be of great help at this point.
 
juv123 said:
Hey everyone, I have an issue I am trying to resolve. I am getting Segmentation fault (11) in my httpd-error.log at random times throughout the day. I have tried several things including commenting out some extensions and reinstalling all extensions, and now I have recompiled php with debug enabled - still getting the faults.
Code: 
[Wed Jan 12 09:00:05 2011] [notice] child pid 97106 exit signal Segmentation fault (11)
I *think* it could be a problem with how I installed PHP. I initially installed the /php52/ port, then deinstalled it and installed /php5/. I ran into problems, as the new PHP install seemed to still see some of the old extensions from the php52 install. So I did a deinstall of all php52 ports then:
# pkg_delete php52*
Click to expand...

That will not work. php52* is expanded by the shell--to files in the current directory that match, which is probably none. To pass a star to pkg_delete, it has to be escaped so the shell doesn't mess with it:

# pkg_delete php52\*

I can't help with PHP specifics, sorry.
 
wblock said:
That will not work. php52* is expanded by the shell--to files in the current directory that match, which is probably none.
Click to expand...

Cool - it's been a few weeks and I forgot the exact commands used. I will assume that I did a pkg_delete on each individual php52. pkg_info shows no php52 in it.
 
Rename /usr/bin/php (to e.g. php.old), force-reinstall the port and what depends on it, and restart Apache. See what happens then.

/usr/bin/php is probably used because it appears earlier in the search path.

One way to get rid of all remnants of the 'wrong PHP' is to repeat the source install inside a chroot (chroot(8), chroot(2)), make a list (with full path names minus the chroot prefix) of all the files that are installed by it, and run rm on those (after proper inspection, of course). This should not touch the port install (in /usr/local/).
 
DutchDaemon -

Should I also change
/usr/bin/php-config
/usr/bin/php-cgi
/usr/bin/phpize
to different names?
 
Probably, yes, if those are called (without full path) from the php code.
 
Update - changing names worked great to make sure the correct version is called. Simply changing the name of those folders immediately changed the working version. Thank you.

A portupgrade to PHP 5.3.5 was also performed with a reinstall of apache. Unfortunately, this did not solve my segmentation faults, but I will continue looking for a solution.

Thank you for your help!
 
Now - I've finally figured out how to get a core dump for my Segmentation Fault. Here is where it stops:
Code: 
Reading symbols from /usr/local/lib/php/20090626-debug/ctype.so...done.
Loaded symbols for /usr/local/lib/php/20090626-debug/ctype.so
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
#0  0x28adf4f1 in _zval_ptr_dtor (zval_ptr=0xbfbfd1bc, __zend_filename=0x28c61a48 "/usr/ports/lang/php5/work/php-5.3.5/Zend/zend_execute.h", __zend_lineno=318) at zend.h:385
385     zend.h: No such file or directory.
        in zend.h
then bt:
Code: 
(gdb) bt
#0  0x28adf4f1 in _zval_ptr_dtor (zval_ptr=0xbfbfd1bc, __zend_filename=0x28c61a48 "/usr/ports/lang/php5/work/php-5.3.5/Zend/zend_execute.h", __zend_lineno=318) at zend.h:385
#1  0x28b1d1fd in zend_vm_stack_clear_multiple () at zend_execute.h:318
#2  0x28b1dc33 in zend_do_fcall_common_helper_SPEC (execute_data=0x2995b040) at zend_vm_execute.h:406
#3  0x28b22758 in ZEND_DO_FCALL_SPEC_CONST_HANDLER (execute_data=0x2995b040) at zend_vm_execute.h:1606
#4  0x28b1ca6b in execute (op_array=0x28e96df0) at zend_vm_execute.h:107
#5  0x28af0557 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/ports/lang/php5/work/php-5.3.5/Zend/zend.c:1194
#6  0x28a843ad in php_execute_script (primary_file=0xbfbfe8b4) at /usr/ports/lang/php5/work/php-5.3.5/main/main.c:2265
#7  0x28bbbd73 in php_handler (r=0x29957058) at /usr/ports/lang/php5/work/php-5.3.5/sapi/apache2handler/sapi_apache2.c:669
#8  0x08076a89 in ap_run_handler (r=0x29957058) at config.c:157
#9  0x08079d5e in ap_invoke_handler (r=0x29957058) at config.c:376
#10 0x08084b80 in ap_process_request (r=0x29957058) at http_request.c:282
#11 0x08081cfb in ap_process_http_connection (c=0x299471f0) at http_core.c:190
#12 0x0807dd79 in ap_run_process_connection (c=0x299471f0) at connection.c:43
#13 0x08089461 in child_main (child_num_arg=Variable "child_num_arg" is not available.
) at prefork.c:662
#14 0x08089747 in make_child (s=0x2850ff10, slot=52) at prefork.c:763
#15 0x0808a0f7 in ap_mpm_run (_pconf=0x2850e018, plog=0x2853c018, s=0x2850ff10) at prefork.c:898
#16 0x08064149 in main (argc=676380696, argv=0x290ed018) at main.c:739

If I am analyzing this correctly, zend.h is looking for
/usr/ports/lang/php5/work/php-5.3.5/Zend/zend_execute.h
but cannot find it, so it segfaults. This path does not exist, but that file is located in several places:
Code: 
control# locate zend_execute.h
/usr/include/php/Zend/zend_execute.h
/usr/local/include/php/Zend/zend_execute.h
/usr/local/src/php-5.2.16/Zend/zend_execute.h
I believe the place it should be looking is:
/usr/local/include/php/Zend/zend_execute.h
In fact - there is no "work" directory inside /usr/ports/lang/php5/.

Any ideas on why it would be looking there? Any way to make it look in the right place?
 
Applications should never be looking for a /work/ directory in the ports tree, because that's a mere staging directory to build the port in, and install the port from. It gets deleted by make clean, and it has no 'right to live' outside of a port build/install. I have no idea why anything would be looking for files in that staging directory unless something went terribly wrong during the build process, e.g. in the toolchain (compilers, autoconf/autotools, make settings, compiler flags, that sort of thing).
 
Applications should never be looking for a /work/ directory in the ports tree, because that's a mere staging directory to build the port in, and install the port from.
Click to expand...
I'm glad you said that, because the other error I am getting in httpd-error.log is:
Code: 
/usr/ports/lang/php5/work/php-5.3.5/main/main.c(2331) : Bailed out without a bailout address!
but if I look for main.c
Code: 
control# locate main/main.c
/usr/local/src/php-5.2.16/main/main.c
control#
Of course the only place it is located is in that OLD php src directory. So SOMETHING somewhere is still wanting to use the old non-port PHP, right?

What if I just reinstalled php, but did not # make clean. Do you think these errors would stop (would those missing files now be found?)
 
No, I wouldn't do that. There are several ways in which that /work/ directory may get deleted. This is becoming a nasty, almost inextricable mess. You really need to find a way to get that old source-based (non-port) installation entirely off of your disks, followed by a full reinstall of the port. So long as 'chunks' of that old php installation keep floating around in your (application and library) search path you will keep experiencing segfaults and weird error messages. Other than wiping and starting over or what I propsed in post #4, I don't see a lot of options to untangle this mess.
 
Ok. If I understand the chroot option, this allows me to install the full source-based php in some directory that is somehow removed (so it doesn't touch anything else on the server). Then use that install to find all of the php files that were installed and # rm them from my working directory.

If this is the case, this is a bit over my head. Would you be willing to step me through the process?
 
In that case it's probably better to check whether the source install has a DESTDIR= or INSTALLDIR= option, so that it can be installed under e.g. /tmp/php/.
 
You must log in or register to reply here.
Back
Top