stack frames as necessary to restore the proper context to transfer control to the target statement within the enclosing outer function. Similarly, C has the setjmp and longjmp functions that act as non-local gotos. Common Lisp allows control of what happens when the stack is unwound by using the unwind-protect special operator. When applying a continuation, the stack is (logically) unwound and then rewound with the stack of the continuation. This is not the only way to implement continuations; for example, using multiple, explicit stacks, application of a continuation can simply activate its stack and wind a value to be passed. The Scheme programming language allows arbitrary thunks to be executed in specified points on "unwinding" or "rewinding" of the control stack when a continuation is invoked. Inspection The call stack can sometimes be inspected as the program is running. Depending on how the program is written and compiled, the information on the stack can be used to determine intermediate values and function call traces. This has been used to generate fine-grained automated tests, and in cases like Ruby and Smalltalk, to implement first-class continuations. As an example, the GNU Debugger (GDB) implements interactive inspection of the call stack of a running, but paused, C program. Taking regular-time samples of the call stack can be useful in profiling the performance of programs, because if a subroutine's pointer appears on the call stack sampling data many times, it is likely a code bottleneck and should be inspected for performance problems. Security In a language with free pointers or non-checked array writes (such as in C), the mixing of control flow data which affects the execution of code (the return addresses or the saved frame pointers) and simple program data (parameters or return values) in a call stack is a security risk, possibly exploitable through stack buffer overflows as the most common type of buffer overflows. One of such attacks involves filling one buffer with arbitrary executable code, and then overflowing the same or some other buffer to overwrite some return address with a value that points directly to the executable code. As a result, when the function returns, the computer executes that code. This kind of an attack can be easily blocked with W^X. Similar attacks can succeed even with W^X protection enabled, including the return-to-libc attack or the attacks coming from return-oriented programming. Various mitigations have been proposed, such as