Re: php5 segfault
On Thursday 09 October 2008 12:00:47 Jeremy Chadwick wrote: > On Thu, Oct 09, 2008 at 11:53:11AM +0200, Laszlo Nagy wrote: > >>> There are no options to configure in php5-pgsql. > >>> > >>> I tried to change the order or module in extensions.ini, no success so > >>> far. > >> > >> Then my recommendation is to build PHP with DEBUG enabled (see "make > >> config"), reproduce the situation, and provide a backtrace here. > > > > Problem solved. I put pgsql.so on top of all other modules and now there > > is no segfault. Thank you! > > I thought you said you changed the order and it didn't work? *confused* > > > Although I do not understand why it has not been fixed. The same > > problem existed two years ago, right? > > What "problem" are you referring to? The extension ordering issue? > > If so: it should be obvious why it hasn't been fixed. It doesn't appear > to affect everyone -- for example, we have never seen this problem in > the 4-5 years we've been using PHP on FreeBSD -- and the solution > doesn't really make much sense anyway. Just browse the archive of this list to see how many times it came up. Everyone is quite arbitrary. Just cause you never hit it, doesn't mean it's random. I've traced it to zend_module_shutdown, but then hit stuff I don't understand, namely, dlclose(3), specifically _fini() and how the zend engine uses it and why it's not working right. I hit ENOTIME, when trying to unwrap the code there. These two notes are in my extensions.ini: ; NOTE: spl makes php coredump if loaded after pspell ; NOTE 2: simplexml makes php coredump if loaded after pspell I don't have pspell anymore, since I stopped using it, but maybe you can then reproduce it. If not, I can provide you with a full extensions.ini that will coredump on shutdown 100% of the time (for me at least). What I remember from my tracing attempts is that extensions are expected to clean up their recourses (as in php resources, the library context handlers). At the same time, modules are unloaded in reverse order as they are loaded. In the case where Module A needs Module B, module B needs to be loaded first, but is unloaded last. My prime suspect was that Module A frees it's resources, but Module B still has a ref to it in it's own resource. However, I dind't find that criminal. For me it was a matter of "I can spend a few days tracking it down or just re-order my extensions". Where the culprit is is hard to tell, since people report this doesn't happen on other platforms, it can be a FreeBSD specific problem with how it handles dlclose() and/or garbage collection magic, or it's a problem within php that is as you suspect, being worked around on other platforms by package managers. > It smells of a missing symbol > problem (e.g. libxx.so wants a symbol named "hello_bob", but the symbol > is available in libyy.so, which has to be loaded first; however, ld.so > and dlopen(3) have explicit handling for this scenario (see RTLD_NOW vs. > RTLD_LAZY), so I'm at a loss). Missing symbols happen also, but then no segfaults, simply php won't start (obviously). Easily traceable by module dependencies. -- Mel Problem with today's modular software: they start with the modules and never get to the software part. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: php5 segfault
On Thu, Oct 09, 2008 at 01:15:59PM +0200, Laszlo Nagy wrote: > >> I thought you said you changed the order and it didn't work? *confused* >> > I said no success so far. There are more than 20 modules and there is no > description about what the good order should be. I had to keep trying... >> If so: it should be obvious why it hasn't been fixed. It doesn't appear >> to affect everyone -- for example, we have never seen this problem in >> the 4-5 years we've been using PHP on FreeBSD -- and the solution >> doesn't really make much sense anyway. It smells of a missing symbol >> problem (e.g. libxx.so wants a symbol named "hello_bob", but the symbol >> is available in libyy.so, which has to be loaded first; however, ld.so >> and dlopen(3) have explicit handling for this scenario (see RTLD_NOW vs. >> RTLD_LAZY), so I'm at a loss). >> > Maybe you are right. But I would think that a missing symbol problem > should throw an error message telling "missing symbol" instead of making > a segfault. That all depends on the C code. If you'd like to dig around in it and investigate/debug it to find out what the true nature of the problem is, that would be beneficial, since AFAIK no one has done that yet. It's all speculative. >> That said, if you feel this is a humongous issue, I highly recommend you >> mail the PHP port maintainer and express your concerns, or open a PR >> > We had the same problem on our previous server. I'm going to install > another box today and test it. If the problem comes out again, I'm going > to write a PR. And I would also recommend filing a bug report with the PHP folks. This may be something that's a PHP problem and not a FreeBSD problem. It may "not be a Linux problem" because for all we know the Linux RPMs and Portage stuff in CentOS/Gentoo could have workarounds in place. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: php5 segfault
I thought you said you changed the order and it didn't work? *confused* I said no success so far. There are more than 20 modules and there is no description about what the good order should be. I had to keep trying... If so: it should be obvious why it hasn't been fixed. It doesn't appear to affect everyone -- for example, we have never seen this problem in the 4-5 years we've been using PHP on FreeBSD -- and the solution doesn't really make much sense anyway. It smells of a missing symbol problem (e.g. libxx.so wants a symbol named "hello_bob", but the symbol is available in libyy.so, which has to be loaded first; however, ld.so and dlopen(3) have explicit handling for this scenario (see RTLD_NOW vs. RTLD_LAZY), so I'm at a loss). Maybe you are right. But I would think that a missing symbol problem should throw an error message telling "missing symbol" instead of making a segfault. That said, if you feel this is a humongous issue, I highly recommend you mail the PHP port maintainer and express your concerns, or open a PR We had the same problem on our previous server. I'm going to install another box today and test it. If the problem comes out again, I'm going to write a PR. Thank you! Laszlo ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: php5 segfault
On Thu, Oct 09, 2008 at 11:53:11AM +0200, Laszlo Nagy wrote: > >>> There are no options to configure in php5-pgsql. >>> >>> I tried to change the order or module in extensions.ini, no success so far. >>> >> >> Then my recommendation is to build PHP with DEBUG enabled (see "make >> config"), reproduce the situation, and provide a backtrace here. >> > Problem solved. I put pgsql.so on top of all other modules and now there > is no segfault. Thank you! I thought you said you changed the order and it didn't work? *confused* > Although I do not understand why it has not been fixed. The same > problem existed two years ago, right? What "problem" are you referring to? The extension ordering issue? If so: it should be obvious why it hasn't been fixed. It doesn't appear to affect everyone -- for example, we have never seen this problem in the 4-5 years we've been using PHP on FreeBSD -- and the solution doesn't really make much sense anyway. It smells of a missing symbol problem (e.g. libxx.so wants a symbol named "hello_bob", but the symbol is available in libyy.so, which has to be loaded first; however, ld.so and dlopen(3) have explicit handling for this scenario (see RTLD_NOW vs. RTLD_LAZY), so I'm at a loss). That said, if you feel this is a humongous issue, I highly recommend you mail the PHP port maintainer and express your concerns, or open a PR. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: php5 segfault
There are no options to configure in php5-pgsql. I tried to change the order or module in extensions.ini, no success so far. Then my recommendation is to build PHP with DEBUG enabled (see "make config"), reproduce the situation, and provide a backtrace here. Problem solved. I put pgsql.so on top of all other modules and now there is no segfault. Thank you! Although I do not understand why it has not been fixed. The same problem existed two years ago, right? Laszlo ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: php5 segfault
On Thu, Oct 09, 2008 at 10:11:29AM +0200, Laszlo Nagy wrote: > Also, you cannot use a threaded Apache (e.g. threaded MPMs) with PHP since not all extensions support threading. Your Apache needs to be built without threads and use a non-thread model (e.g. prefork). I've also had success with Apache-ITK-mpm. >>> >>> This is very true for mod_php, but less so if PHP is run as FastCGI. >>> I am >>> currently running a box at work with the event mpm and mod_fcgid for >>> testing and it seems to be doing well. YMMV > All right. The problem is that we are getting segfaults with the CLI > version too. We are running some background PHP programs and they also > throw segfault. extensions.ini is used by the CLI version as well. I'm not sure why you think this wouldn't be the case. > Here is the interesting part. I wrote a test script that tries to > connect to the postgresql server. > > - if the hostname is wrong for the connection, there is no segfault > - if the hostname is right but the password is wrong (e.g. it cannot > connect to the server) then there IS segfault. > > There are no options to configure in php5-pgsql. > > I tried to change the order or module in extensions.ini, no success so far. Then my recommendation is to build PHP with DEBUG enabled (see "make config"), reproduce the situation, and provide a backtrace here. I would also consider filing a bug with the PHP folks. They may know something we don't. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: php5 segfault
Also, you cannot use a threaded Apache (e.g. threaded MPMs) with PHP since not all extensions support threading. Your Apache needs to be built without threads and use a non-thread model (e.g. prefork). I've also had success with Apache-ITK-mpm. This is very true for mod_php, but less so if PHP is run as FastCGI. I am currently running a box at work with the event mpm and mod_fcgid for testing and it seems to be doing well. YMMV All right. The problem is that we are getting segfaults with the CLI version too. We are running some background PHP programs and they also throw segfault. Here is the interesting part. I wrote a test script that tries to connect to the postgresql server. - if the hostname is wrong for the connection, there is no segfault - if the hostname is right but the password is wrong (e.g. it cannot connect to the server) then there IS segfault. There are no options to configure in php5-pgsql. I tried to change the order or module in extensions.ini, no success so far. Best, Laszlo ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: php5 segfault
On Oct 8, 2008, at 10:53 AM, Michael Powell wrote: Jeremy Chadwick wrote: On Wed, Oct 08, 2008 at 02:51:00PM +0200, Laszlo Nagy wrote: [snip] So it is using -O2 and -pipe. Is this something that I can disable? If you want. "make config" in /usr/ports/lang/php5 will give you a menu option for DEBUG; turn it on. I'm not sure what the compile options you're showing have *anything* to do with the segfault you're reporting. I don't see any backtraces or details of the segfault. I've used -pipe -O2 for years and never had it cause me trouble. It might be because we are using postgresql connections. For pages without pgsql connection, there is no segfault. Still using MySQL so I can't speak to PostgreSQL PHP connectivity. I've personally used PHP5 (as a CGI only, not as an Apache module) with PostgreSQL and experienced no segfaults. It must be noted that the segfault happens on cleanup. E.g. all web sites are working fine, except that we are getting many many segfault messages in the logs all the time. This will inhibit performance. The ones that are failing are having the script(s) restarted. If you can fix this performance will improve. Many people have found that re-ordering the "extensions" lines in /usr/local/etc/php/extensions.ini has solved odd segfaults. I personally have never seen this, nor have ever needed to adjust that file, but it has worked for others. One quickie shortcut to try as experimentation is to just comment out hash.so in extensions.ini. I have had trouble with this one, ie to the extent Apache wouldn't even start. I've read/heard about the reorder thing too and never needed it. What I suspect is there is a possibility that what happened is people went in after the fact and installed xyz extensions after the first main install after discoverring they forgot or left out something they needed. This results in the line(s) just getting tacked on at the bottom. If they had wiped all PHP and done it again from scratch the list in extensions.ini would then be correct. Only a theory on my part. Also, you cannot use a threaded Apache (e.g. threaded MPMs) with PHP since not all extensions support threading. Your Apache needs to be built without threads and use a non-thread model (e.g. prefork). I've also had success with Apache-ITK-mpm. This is very true for mod_php, but less so if PHP is run as FastCGI. I am currently running a box at work with the event mpm and mod_fcgid for testing and it seems to be doing well. YMMV Search the mailing lists for this situation, try the recommendations, and then if nothing fixes it, provide a backtrace. The normal default of error_reporting = E_ALL & ~E_NOTICE is present, but if you want it to log to it's own file uncomment ;error_log = filename (or syslog if you prefer). You may need to do a 'touch on the and make it's permissions match those the webserver runs under. If things get really bad take a look at http://www.xdebug.org/ I don't think this really belongs on a production machine (IMHO), but I have used it on my development server. Better as a last ditch effort probably. -Mike Have a look at http://www.pingle.org/2007/09/22/php-crashes-extensions-workaround PHP extensions have to be loaded in a particular order to avoid the segfaults at cleanup. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: php5 segfault
Jeremy Chadwick wrote: > On Wed, Oct 08, 2008 at 02:51:00PM +0200, Laszlo Nagy wrote: [snip] >> >> So it is using -O2 and -pipe. Is this something that I can disable? > > If you want. "make config" in /usr/ports/lang/php5 will give you a > menu option for DEBUG; turn it on. > > I'm not sure what the compile options you're showing have *anything* to > do with the segfault you're reporting. I don't see any backtraces or > details of the segfault. I've used -pipe -O2 for years and never had it cause me trouble. >> It might be because we are using postgresql connections. For pages >> without pgsql connection, there is no segfault. Still using MySQL so I can't speak to PostgreSQL PHP connectivity. > I've personally used PHP5 (as a CGI only, not as an Apache module) > with PostgreSQL and experienced no segfaults. > >> It must be noted that the segfault happens on cleanup. E.g. all web >> sites are working fine, except that we are getting many many segfault >> messages in the logs all the time. This will inhibit performance. The ones that are failing are having the script(s) restarted. If you can fix this performance will improve. > Many people have found that re-ordering the "extensions" lines in > /usr/local/etc/php/extensions.ini has solved odd segfaults. I > personally have never seen this, nor have ever needed to adjust that > file, but it has worked for others. One quickie shortcut to try as experimentation is to just comment out hash.so in extensions.ini. I have had trouble with this one, ie to the extent Apache wouldn't even start. I've read/heard about the reorder thing too and never needed it. What I suspect is there is a possibility that what happened is people went in after the fact and installed xyz extensions after the first main install after discoverring they forgot or left out something they needed. This results in the line(s) just getting tacked on at the bottom. If they had wiped all PHP and done it again from scratch the list in extensions.ini would then be correct. Only a theory on my part. > Also, you cannot use a threaded Apache (e.g. threaded MPMs) with PHP > since not all extensions support threading. Your Apache needs to be > built without threads and use a non-thread model (e.g. prefork). I've > also had success with Apache-ITK-mpm. This is very true for mod_php, but less so if PHP is run as FastCGI. I am currently running a box at work with the event mpm and mod_fcgid for testing and it seems to be doing well. YMMV > Search the mailing lists for this situation, try the recommendations, > and then if nothing fixes it, provide a backtrace. > The normal default of error_reporting = E_ALL & ~E_NOTICE is present, but if you want it to log to it's own file uncomment ;error_log = filename (or syslog if you prefer). You may need to do a 'touch on the and make it's permissions match those the webserver runs under. If things get really bad take a look at http://www.xdebug.org/ I don't think this really belongs on a production machine (IMHO), but I have used it on my development server. Better as a last ditch effort probably. -Mike ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: php5 segfault
On Wed, Oct 08, 2008 at 02:51:00PM +0200, Laszlo Nagy wrote: > uname -a: > > FreeBSD shopzeus.com 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #3: Mon Oct > 6 07:50:31 EDT 2008 > [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SHOPZEUS amd64 > > when compiling /usr/ports/php5 I see messages like: > > bin/sh /usr/ports/lang/php5/work/php-5.2.6/libtool --silent > --preserve-dup-deps --mode=compile cc -IZend/ > -I/usr/ports/lang/php5/work/php-5.2.6/Zend/ -DPHP_ATOM_INC > -I/usr/ports/lang/php5/work/php-5.2.6/include > -I/usr/ports/lang/php5/work/php-5.2.6/main > -I/usr/ports/lang/php5/work/php-5.2.6 -I/usr/local/include/libxml2 > -I/usr/local/include -I/usr/ports/lang/php5/work/php-5.2.6/ext/date/lib > -I/usr/ports/lang/php5/work/php-5.2.6/TSRM > -I/usr/ports/lang/php5/work/php-5.2.6/Zend-O2 -fno-strict-aliasing > -pipe -c /usr/ports/lang/php5/work/php-5.2.6/Zend/zend_API.c -o > Zend/zend_API.lo > > So it is using -O2 and -pipe. Is this something that I can disable? If you want. "make config" in /usr/ports/lang/php5 will give you a menu option for DEBUG; turn it on. I'm not sure what the compile options you're showing have *anything* to do with the segfault you're reporting. I don't see any backtraces or details of the segfault. > It might be because we are using postgresql connections. For pages without > pgsql connection, there is no segfault. I've personally used PHP5 (as a CGI only, not as an Apache module) with PostgreSQL and experienced no segfaults. > It must be noted that the segfault happens on cleanup. E.g. all web > sites are working fine, except that we are getting many many segfault > messages in the logs all the time. Many people have found that re-ordering the "extensions" lines in /usr/local/etc/php/extensions.ini has solved odd segfaults. I personally have never seen this, nor have ever needed to adjust that file, but it has worked for others. Also, you cannot use a threaded Apache (e.g. threaded MPMs) with PHP since not all extensions support threading. Your Apache needs to be built without threads and use a non-thread model (e.g. prefork). I've also had success with Apache-ITK-mpm. Search the mailing lists for this situation, try the recommendations, and then if nothing fixes it, provide a backtrace. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
php5 segfault
uname -a: FreeBSD shopzeus.com 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #3: Mon Oct 6 07:50:31 EDT 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SHOPZEUS amd64 when compiling /usr/ports/php5 I see messages like: bin/sh /usr/ports/lang/php5/work/php-5.2.6/libtool --silent --preserve-dup-deps --mode=compile cc -IZend/ -I/usr/ports/lang/php5/work/php-5.2.6/Zend/ -DPHP_ATOM_INC -I/usr/ports/lang/php5/work/php-5.2.6/include -I/usr/ports/lang/php5/work/php-5.2.6/main -I/usr/ports/lang/php5/work/php-5.2.6 -I/usr/local/include/libxml2 -I/usr/local/include -I/usr/ports/lang/php5/work/php-5.2.6/ext/date/lib -I/usr/ports/lang/php5/work/php-5.2.6/TSRM -I/usr/ports/lang/php5/work/php-5.2.6/Zend-O2 -fno-strict-aliasing -pipe -c /usr/ports/lang/php5/work/php-5.2.6/Zend/zend_API.c -o Zend/zend_API.lo So it is using -O2 and -pipe. Is this something that I can disable? It might be because we are using postgresql connections. For pages without pgsql connection, there is no segfault. It must be noted that the segfault happens on cleanup. E.g. all web sites are working fine, except that we are getting many many segfault messages in the logs all the time. Thanks, Laszlo ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
