XComp wrote:
It seems likely that either the registers or the stack (wherever "i"
is stored) is getting trashed. What is "i" in the cases where the
test
fails?
You find a sample output below. It seems to work in some cases. So
you
might be right with the stack. But why? I mean... there is nothing
else but the for-loop. Or do I have the wrong idea of how the stack
works?! Can a stack be overflown by a simple for-loop? Is an
alternate
signal stack needed? I thought it doesn't because the current stack
should be big enough.
It isn't an issue with it overflowing. I was assuming that the loop
terminated because "i" was getting set to a value > 1000000000, which
implies it was being corrupted.
Your output indicates that isn't actually the case; it appears that
the branch back to the beginning of the loop is being skipped.
But it does not cancel after the first signal is raised.
I've found out that using the third parameter old_context for
storing
the old context is the reason. But I don't know why.
Note that the old_context parameter to the signal handler won't be
pointing to any of your context "slots". When a signal occurs, the
current context will be saved in a ucontext_t on the current
context's
stack, and the old_context argument will point to that.
I'm not sure whether I understood this correctly. What do you mean
with slots?
Well, I was assuming that your code vaguely resembles the URL you
gave:
http://www.seas.upenn.edu/~cse381/context_demo.c
By "slots", I was refering to:
ucontext_t contexts[NUMCONTEXTS]; /* store our context info */
OTOH, if the only contexts involved are these two:
static ucontext_t thread_context;
static ucontext_t scheduler_context;
then those are the "slots".
In any case, I don't think that you can rely upon the old_context
being usable once you leave the signal handler. Even if you copy the
contents, the uc_mcontext field may not be meaningful outside of the
handler.
So you think that solving the problem in this way will lead me in a
dead end?
But I am confused because of the fact that it works sometimes.
Shouldn't it work the whole time or at no time only?
So I thought there might be a problem in the kernel. Am I right?
I don't think so.
Because of the fact that ucontext_t is part of the C library? I
thought that it might be a kernel issue because of the signal
handling
which is implemented in the kernel.
No, I'm just saying that a failure for context-switching to behave as
you expect with regard to signal handlers isn't a reason to assume a
bug. The standards are fairly vague about how signal handling and
contexts interact.
However, it's also true that the context handling is almost purely in
user-space. The only system call involved is sigprocmask() to get the
signal mask in getcontext() and set it in setcontext()/swapcontext().
So you see that the for-loops quits right after a signal was
caught. I
am really in a dead end now. Do you see any parts of my code, which
might be wrong?
Probably the line:
thread_context = *((ucontext_t*) old_context);
I wouldn't assume that you can do anything with old_context other than
pass it to setcontext() or swapcontext() within the signal handler. In
the absence of documentation to the contrary, I wouldn't assume that
it can be stored and used outside of the handler.
I've tested it. If I use the old_context with setcontext() and go
directly back to the thread in this case (the scheduler_function would
be ignored), the behaviour is the same. Sometimes the loop finishes,
sometimes not.
It's quite possible that the context_t passed to a signal handler and
a context created by calling getcontext() within a signal handler have
some "magic" within the mcontext_t to unwind the signal handling
I note that the code at the above URL doesn't use the old_context
parameter at all.
--
Glynn Clements <glynn@xxxxxxxxxxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-c-
programming" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
