Bug 219235
Summary: | serializer issue with incomplete class | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 4 | Reporter: | William Lovaton <williama_lovaton> | ||||
Component: | php | Assignee: | Joe Orton <jorton> | ||||
Status: | CLOSED ERRATA | QA Contact: | David Lawrence <dkl> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | 4.4 | CC: | walovaton | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | i686 | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2009-05-18 20:32:37 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
William Lovaton
2006-12-12 00:25:57 UTC
Thanks for the report. - Can you reproduce with this "TurckMM-Cache" also disabled? - Can you reproduce this with php-4.3.9-3.22, the latest update for RHEL4? (there are no pertinent fixes but this should always be the first step) Can you bzip2 and attach one of the core dumps produced? (hit the "Private" link so it's not publically available) Hi Joe, thanks for the reply. - It's difficult to test without TurckMM-Cache because the web app has a huge traffic and it will melt the server compiling PHP programs over and over again. You can see more about this op-code cache here: http://turck-mmcache.sourceforge.net/index_old.html I know eAccelerator is a fork of this project (http://eaccelerator.net/) and it seems like it is being maintained but I don't want to switch to a new one knowing that TurckMM-Cache worked fine with every distro I tried. Our Fedora Core 3 production servers use TurckMM with PHP 4.3 Do you know a good alternative to Turck? do you know if eAccelerator is good enough? May be I'll try to use this one and see if this prevents the crashes. - I'll try to upgrade PHP but it's very hard for me since this server is not registered in RHN. Is there an easy way to upgrade httpd and php without fighting too much with deps? - Given the backtrace in my initial post I can see that the problem occurs when it tries to serialize something. Right now in our apps there are 3 places where we depends heavily on PHP serialization: 1) PHP sessions. 2) Query caching. 3) Performance monitoring and user data. I think number 1 is not causing any problem. Number 2 uses several backends to store serialized data (shm, disk, null). I'll try to use NULL to avoid serializing and caching and see what happens (I believe our app can take the performance hit of this). Number 3 is used to store $_REQUEST and $_SESSION data in a special file every time a request takes too long to execute (more than 20 secs) so that we can have a chance of looking at the input given by the user and see if the slowness is reproducible on a test system and try to optimize the algorithms. This too can be disabled to avoid serializing and storing of this information. - I'll attach the bziped core later Thanks again for your help. That's great, thanks a lot, I have a reproducer which seems to match this exactly. Cool! I was thinking about disabling TurckMM-Cache really early in the morning without many users on the system and see if the crashes were reproducible that way but I am almost sure that this isn't causing any problem. I really hope you can track this sucker down. Little question: What would you recommend me for an op-code cache for PHP that works well with RHEL 4? I mean, sure there are lots of customers using PHP on heavy loaded web sites, isn't it? Cheers. No, sorry, we don't have a recommendation of any particular op-cache package. I'm building packages with the patch for the serializer issue now and will make them available for testing shortly. Can you try out the php-4.3.2-3.23 packages from here: http://people.redhat.com/jorton/Nahant-php/ not that these packages *have not been through Red Hat QA* - they've only been tested to not cause regressions in the PHP test suite and to fix the specific reproduction case I have which is hopefully the same issue that you are seeing. Thanks, I'll try them soon, may be at the end of the day. - Do I need to upgrade httpd too? - How do I downgrade if needed? (I've never done that with RPM) Cheers. No, just the php packages are needed. To downgrade to older versions of packages, find the RPMs on RHN/the CD or wherever and "upgrade" to them using: # rpm -Uvh --oldpackage php-4.3.2-3.15.i386.rpm ... Thanks, will do. I'm gonna ask you an "off-bug" question: Do you think is a good idea to use the latest oci8 PHP module (the one in PECL) with PHP 4.3.X?? I need the pinging functionality in that version to solve some issues with Oracle: Once in a while it returns an Oracle error saying that is not connected to Oracle, we use persistent connections to the DB but no one is killing the server side process or anything and I don't know what is happening there. Hi Joe, You saved my day! it totally worked. Our production server have been running for about an entire hour with the updates and there is not a single crash in the error_log. Our performance monitor tool shows good measures again and all of the entries there are justified (sometimes a heavy query, sometimes a very slow network link, etc). Our "slowness" events went from every 10 seconds to every 1.5 minutes which is normal. The installed packages are: php-ldap-4.3.9-3.23 php-4.3.9-3.23 php-pear-4.3.9-3.23 php-gd-4.3.9-3.23 php-devel-4.3.9-3.23 I'll keep monitoring the system for a few days and I'll give back some more feedback. Thanks again. Thanks a lot for testing out the packages. w.r.t. to the oci8 question, I'd certainly recommend using the latest upstream OCI8 module that works - but again, this is not something we've done in-house testing on, so can't give a more specific recommendation. This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release. Hi Joe, I got a new crash but this seems to be a totally different issue. PHP have been very stable, there wasn't any crashes in the log until 14 Dec at 7:20 AM, it was the only one. I then activated the core dump directory in apache and waited for other crash to happen. It finally did today 15 Dec at 7:27 AM and the core dump show the following: (gdb) bt full #0 0x001f4666 in malloc_consolidate () from /lib/tls/libc.so.6 No symbol table info available. #1 0x001f5643 in _int_malloc () from /lib/tls/libc.so.6 No symbol table info available. #2 0x001f7401 in malloc () from /lib/tls/libc.so.6 No symbol table info available. #3 0x010fda96 in _emalloc () from /etc/httpd/modules/libphp4.so No symbol table info available. #4 0x010f0f5c in php_end_implicit_flush () from /etc/httpd/modules/libphp4.so No symbol table info available. #5 0x0000a001 in ?? () No symbol table info available. #6 0x00000000 in ?? () No symbol table info available. It's weird it happened almost at the same hour in the morning, may be httpd is restarting or something like that and it is crashing doing that. Do you think I should file a different bug report?? I'll attach the bzipped core later. Cheers. Created attachment 143765 [details]
core dump of a new crash
This is the new core dump that I got today at 7:27 AM (local time). I assume
that this will happen once a day may be. Not a really serious issue for me but
I still want to know what might be happening there.
That does look like a separate issue; can you file a new bug, and attach your php.ini too? Ok, I just got another crash at 10:34 AM with the following message: [Fri Dec 15 10:34:58 2006] [notice] child pid 16791 exit signal Bus error (7), possible coredump in /tmp/httpd-coredump I'll create a new bug report soon with the new information. I cleared the rhel-4.6 flag for this BZ and request that you [Joe] do the same for any others proposed for 4.6. Please don't set the rhel-4.7 flag until you know which ones you want to proceed fixes for. Thanks... Ken Sorry, I have to ask: Is this fix not included in RHEL 4.5?? I thought it was. This request was evaluated by Red Hat Product Management for inclusion, but this component is not scheduled to be updated in the current Red Hat Enterprise Linux release. If you would like this request to be reviewed for the next minor release, ask your support representative to set the next rhel-x.y flag to "?". This request was evaluated by Red Hat Product Management for inclusion, but this component is not scheduled to be updated in the current Red Hat Enterprise Linux release. If you would like this request to be reviewed for the next minor release, ask your support representative to set the next rhel-x.y flag to "?". This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release. Hi, is this going in for the next update? I hope so since I'm still using RHEL 4. Thanks. William - the fix for this bug is indeed scheduled to be included in RHEL 4.8. Hi Joe, I just upgraded all of my servers and I reinstalled RHEL 4 but I don't have the PHP packages you gave me in comment #7 (php-4.3.9-3.23) that fixed this problem. Is there a way to get these packages? Any idea when an updated package will be officially released? William - I've uploaded the latest package set here: http://people.redhat.com/jorton/Nahant-php/ Let me know how testing goes! So far so good. I installed the updates very early this morning and there is not even one segfault in the logs. Before there used to be about 1000 segfaults a day, so far there is none. Thanks a lot, I'll keep you updated if anything abnormal show up. Great to hear - thanks for following up, and sorry this has taken so long to resolve. An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2009-1013.html |