From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5)
Description of problem:
Sometimes when recv() is interrupted by a signal (e.g. SIGUSR1), it
returns not EINTR as expected, but EAGAIN. This happens sporadically,
but the attached reproducerar reproduced the problem within a few seconds.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Run the attached reproducer.
Actual Results: [magnusi@stheng30:~]$ ./test_select_ia64
recv returned EAGAIN, after 132981248 bytes and 80 interrupts
recv returned EAGAIN, after 291813888 bytes and 137 interrupts
recv returned EAGAIN, after 8419840 bytes and 4 interrupts
recv returned EAGAIN, after 6356992 bytes and 3 interrupts
recv returned EAGAIN, after 4243456 bytes and 2 interrupts
Expected Results: No output should have been written, since recv
should not have returned EAGAIN.
This only happens on SMP machines. It is confirmed to happen on both
i386 and ia64.
Created attachment 110282 [details]
Created attachment 110485 [details]
Fix for EAGAIN signal race
Pretty tight race. We were returning -EAGAIN when the
recv queue is non-empty.
A fix for this problem has just been committed to the RHEL3 U5
patch pool this evening (in kernel version 2.4.21-27.12.EL).
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 the 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.