About setjmp/longjmp

Question

I was investigating setjmp/longjmp and found out that setjmp saves registers such as instruction pointer, stack pointer etc...

However what I don't get here is that, can't the data in the stack of the thread itself be modified between the call to setjmp and longjmp. In that case, wouldn't longjmp not work as expected.

To make it clear, for example, when longjmp restores the stack pointer, say the data in the memory the stack pointer is pointing now is not the same as was when setjmp was called. Can this happen? And if that happens, aren't we in trouble?

Also what is meant by the statement, "The longjmp() routines may not be called after the routine which called the setjmp() routines returns."

Answer 1

setjmp()/longjmp() are not meant to save the stack, that's what setcontext()/getcontext() are for.

The standard specifies that the value of non-volatile automatic variables defined in the function that calls setjmp() that are changed between the setjmp() and the longjmp() calls are unspecified after a longjmp(). There are also some restrictions on how you call setjmp() for this same reason.

Answer 2

The stack pointer marks the division between the "used" and "unused" portions of the stack. When you call setjmp, all current call frames are on the "used" side, and any calls that take place after setjmp, but before the function which called setjmp returns, have their call frames on the "unused" side of the saved stack pointer. Note that calling longjmp after the function which called setjmp has returned invokes undefined behavior, so that case does not need to be considered.

Now, it's possible that local variables in some of the existing call frames are modified after setjmp, either by the calling function or through pointers, and this is one reason why it's necessary to use volatile in many cases...

Answer 3

The setjmp/longjmp (hereafter slj) feature in C is ugly, and its behavior may vary between implementations. Nonetheless, given the absence of exceptions, slj is sometimes necessary in C (note that C++ provides exceptions which are in almost every way superior to slj, and that slj interacts badly with many C++ features).

In using slj, one should bear in mind the following, assuming routine Parent() calls routine Setter(), which calls setjmp() and then calls Jumper, which in turn calls longjmp().

1. Code may legally exit the scope in which a setjmp is performed without a longjmp having been executed; as soon as the scope exits, however, the previously-created jmp_buf must be regarded as invalid. The compiler probably won't do anything to mark it as such, but any attempt to use it may result in unpredictable behavior, likely including a jump to an arbitrary address.
2. Any local variables in Jumper() will evaporate with the call to longjmp(), rendering their values irrelevant.
3. Whenever control returns to Parent, via whatever means, Parent's local variables will be as they were when it called Setter, unless such variables had their addresses taken and were changed using such pointers; in any case, setjmp/longjmp will not affect their values in any way. If such variables do not have their addresses taken, it is possible that setjmp() may cache the values of such variables and longjmp() may restore them. In that scenario, however, there would be no way for the variables to change between when they are cached and when they are restored, so the cache/restore would have no visible effect.
4. The variables in Setter may or may not be cached by setjmp() call. After a longjmp() call, such variables may have the value they had when setjmp() was performed, or the values they had when it called the routine which ultimately called longjmp(), or any combination thereof. In at least some C dialects, such variables may be declared "volatile" to prevent them from being cached.

Although setjmp/longjmp() can sometimes be useful, they can also be very dangerous. There is in most cases no protection errant code causing Undefined Behavior, and in many real-world scenarios, improper usage is likely to cause bad things to happen (unlike some kinds of Undefined Behavior, where the actual outcome may often line up with what the programmer intended).

Answer 4

It is somewhat useless to use setjmp() and longjmp() in data processing situations. So, this would be the case where you might be concerned with automatic variables. The variables can be in a stack slot or a register. If they are in a stack slot, the stack is not restored by popping contexts along the stack. Instead, the stack is immediately rewound and callee saved registers are restored.

The stack space used by the routine is reserved and other routines should not use it. So if the compiler is aware that the variable is stored on the stack before (setjmp()), then it can retrieve it on return. It will just confound analysis, which is based on 'basic blocks' and setjmp()/longjmp() defy that categorization.

I would question why anyone would use setjmp()/longjmp() in this context. A good use might be found in libjpeg and another by Simon Tatham use in co-routines. Ie, the routines are rather single purposed. They either setup a context for a long running operation that might have many exceptional conditions or they are used as a primitive scheduler. Mixing actual data processing with them is a mistake waiting to happen (for all the reason mentioned elsewhere).

Subclause 7.13.1.1 of the C Standard spells out where you can use setjmp(). It is an abnormal function, so treating it like a normal function call is the main issue. Perhaps the language should have gave it a different syntax.

---

Also what is meant by the statement, "The longjmp() routines may not be called after the routine which called the setjmp() routines returns."

Here is an example in function e(),

jmp_buf buf;  // Another reason to avoid static/globals here.
 
void k(void) {
  /* ... */
  longjmp(buf, 1);
}

void f(void) {
  if (setjmp(buf) == 0) {
    k();
  } else {
    /* longjmp was invoked */
  }
}
 

void e(void) {
  f();
  longjmp(buf, 1);  // ERROR! we will return to f(); popped stack slot.
   // If 'buf' wasn't global, but declared in f(), this would not compile
   // That is a good thing.
}

The code sequence is e() -> f() -> k() -> f() -> e() -> crash. It is somewhat like using a closed file handle. Ie, the jmp_buf is still set to valid looking values, but they point to non-existent stack.

Answer 5

In the example below, setjmp / longjump alters the value of i, which lives in main, via a pointer. I is never incremented in the for loop. For extra fun see the entry albert.c , http://www.ioccc.org/years-spoiler.html winner of the 1992 IOCCC. (one of the few times I ever ROTFLed reading a C source ...)

#include <stdio.h>
#include <setjmp.h>

jmp_buf the_state;

void helper(int *p);
int main (void)
{
int i;

for (i =0; i < 10;    ) {
    switch (setjmp (the_state) ) {
    case 0:  helper (&i) ; break;
    case 1:    printf( "Even=\t"); break;
    case 2:    printf( "Odd=\t"); break;
    default: printf( "Oops=\t"); break;
        }
    printf( "I=%d\n", i);
    }

return 0;
}
void helper(int *p)
{
*p += 1;
longjmp(the_state, 1+ *p%2);
}

Answer 6

Also what is meant by the statement, "The longjmp() routines may not be called after the routine which called the setjmp() routines returns."

This is saying that you can only longjmp up the call tree / call stack, to a parent function which called setjmp. (Or within the same invocation of the current function, like a glorified goto, so it doesn't strictly have to be a parent function.)

So it's a lot like try{}catch / throw in terms of call structure, where setjmp sets up a catch point and longjmp is like throw. Somewhat different semantics for stack unwinding and local variables, but still only unwinding up the call stack.

This is why reuse of stack space for something else isn't a problem: the locals (in automatic storage) that were alive when setjmp was called must still be alive, during the same lifetime.

You can't longjmp back into a function that's already returned. Well you can but it's undefined behaviour. Unlike try{}catch/throw where you literally can't since catching is based on nesting of scopes and function calls, so you can't do the broken thing of jumping to the catch{} block if you're not inside its try.

Other answers go into more details about volatile and other things; I posted this since others seemed to be lacking a simple and clear statement about only being able to jump to a setjmp call-site in a scope that hadn't reached the end of its lifetime.