[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1199561709625@dmwebmail.japan.chezphil.org>
Date: Sat, 05 Jan 2008 19:35:09 +0000
From: "Phil Endecott" <phil_wueww_endecott@...zphil.org>
To: "Andreas Schwab" <schwab@...e.de>
Cc: "Jiri Slaby" <jirislaby@...il.com>, <linux-kernel@...r.kernel.org>,
"Frederik Deweerdt" <deweerdt@...e.fr>
Subject: Re: strace, accept(), ERESTARTSYS and EINTR
Andreas Schwab wrote:
> "Phil Endecott" <phil_wueww_endecott@...zphil.org> writes:
>> Andreas Schwab wrote:
>>> "Phil Endecott" <phil_wueww_endecott@...zphil.org> writes:
>>>> However, there's a lot of code and I know that there are bugs in it. I
>>>> just want to focus on the kernel-related issue that the strace fragment
>>>> that I posted brings up: even if my user code gets completely screwed up
>>>> (corrupts its stack, runs out of FDs/VM/threads etc), I don't think that I
>>>> should see in the strace output that accept() has returned
>>>> ERESTARTSYS.
>>>
>>> strace always sees the raw return value, before the signal handler is
>>> executed and before the check for syscall restart is done.
>>
>> Yes, but I should see the real final return value in another strace output
>> line before I see that thread doing something else. Correct?
>
> No. As far as strace is concerned the syscall has finished. Since it
> isn't restarted, you won't see it again in the trace.
Sorry for being dense, but what is the implication of your comment
"Since it isn't restarted" ? Are you saying that the kernel isn't
going to restart it and will have converted it to EINTR and returned
that to user-space, and that this modified return value is not reported
by strace?
Phil.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists