"Carl Shapiro" <[EMAIL PROTECTED]> writes: > Rex, > > On Sat, Mar 15, 2008 at 6:58 PM, Rex Dieter <[EMAIL PROTECTED]> wrote: >> I would be tempted to say "on any gcc43-derived linux system", but I'm >> not convinced that gcc43 is the (sole, if at all) culprit. > > This turns out to be a problem with CMUCL. I have just committed a > change which resolves this issue. With the change in place, I have > been able to run and rebuild CMUCL on an FC9 virtual machine I am > running locally. This change, along with the others I have made for > FC9 compatibility, will be down-integrated into the 19e release > branch.
For your information: I believe that this is (was) not a problem with CMUCL, though the changes you have made to clear the direction flag close to where you set it will work around most of the problem. The problem is in fact a kernel bug, which was masked until gcc-4.3 by a conservative treatment of the ABI. The kernel failed to clear the direction flag before running a signal handler, but this didn't matter because the compiler cleared it for you in various circumstances, including across function call boundaries; a libc6 compiled with gcc-4.3, with its signals/ directory compiled with gcc-4.2, will eliminate the observed problem. Even with your changes to the assembly routines, there is a small window wherein a signal (such as SIGINT) will cause trouble; if the signal is received when the direction flag is set, then handlers will run with the wrong flag. The only way to fix these is to clear the direction flag within signal handlers before calling sigemptyset() or memset() or similar; as far as I know, this would need to be done for the *BSDs and Linux, but not for Solaris (though of course it is harmless to do so). For more information, see the discussion of this on sbcl-devel and linux-kernel, or a LWN summary at <http://lwn.net/Articles/272048/>. Best, Christophe
