This bug has been copied from bug #664931 and has been proposed to be backported to 5.6 z-stream (EUS).
in kernel-2.6.18-238.1.1.el5 linux-2.6-mm-prevent-file-lock-corruption-using-popen-3.patch
Guan, how does it look? Anyway, Larry told me that the other test may not reveal the problem...
Flipping back to ON_QA
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/RHSA-2011-0163.html
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Prior to this update, a multi-threaded application, which invoked popen(3) internally, could cause a thread stall by FILE lock corruption. The application program waited for a FILE lock in glibc, but the lock seemed to be corrupted, which was caused by a race condition in the COW (Copy On Write) logic. With this update, the race condition was corrected and FILE lock corruption no longer occurs.