From: Sean Reifschneider <[EMAIL PROTECTED]> Date: Wed, 10 Jan 2007 18:04:29 -0700
> On Wed, Jan 10, 2007 at 04:27:47PM -0800, David Miller wrote: > >It gets caught by the return into userspace code. > > Ok, so somehow it is leaking. I have a system in the lab that is the same > hardware as production, but it currently has no, you know, hard drives in > it, so some assembly is required. I'll see if I can reproduce it in a test > environment and then see if I can get more information on when/where it is > leaking. If you're only seeing it in strace, that's expected due to some unfortunate things in the way that x86 and x86_64 handle signal return events via ptrace(). On sparc and sparc64 I fixed this long ago such that ptrace() will update the user registers before ptrace parents are notified, and therefore you'll never see those kernel internal error codes. The upside of this is that you'll really need to see what value is making it to the application. What the kernel is probably doing is looping trying to restart the system call and sending the signal. If it's doing that the application is being rewound to call the system call again once the signal handler returns (if that is even being run at all). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
