1 .\" Copyright (c) 2001, 2017 Michael Kerrisk <mtk.manpages@gmail.com>
3 .\" %%%LICENSE_START(VERBATIM)
4 .\" Permission is granted to make and distribute verbatim copies of this
5 .\" manual provided the copyright notice and this permission notice are
6 .\" preserved on all copies.
8 .\" Permission is granted to copy and distribute modified versions of this
9 .\" manual under the conditions for verbatim copying, provided that the
10 .\" entire resulting derived work is distributed under the terms of a
11 .\" permission notice identical to this one.
13 .\" Since the Linux kernel and libraries are constantly changing, this
14 .\" manual page may be incorrect or out-of-date. The author(s) assume no
15 .\" responsibility for errors or omissions, or for damages resulting from
16 .\" the use of the information contained herein. The author(s) may not
17 .\" have taken the same level of care in the production of this manual,
18 .\" which is licensed free of charge, as they might when working
21 .\" Formatted or processed versions of this manual, if unaccompanied by
22 .\" the source, must acknowledge the copyright and authors of this work.
25 .\" aeb, various minor fixes
26 .TH SIGALTSTACK 2 2021-03-22 "Linux" "Linux Programmer's Manual"
28 sigaltstack \- set and/or get signal stack context
31 .B #include <signal.h>
33 .BI "int sigaltstack(const stack_t *restrict " ss \
34 ", stack_t *restrict " old_ss );
38 Feature Test Macro Requirements for glibc (see
39 .BR feature_test_macros (7)):
45 .\" || _XOPEN_SOURCE && _XOPEN_SOURCE_EXTENDED
46 || /* Since glibc 2.12: */ _POSIX_C_SOURCE >= 200809L
47 || /* Glibc <= 2.19: */ _BSD_SOURCE
51 allows a thread to define a new alternate
52 signal stack and/or retrieve the state of an existing
53 alternate signal stack.
54 An alternate signal stack is used during the
55 execution of a signal handler if the establishment of that handler (see
59 The normal sequence of events for using an alternate signal stack
63 Allocate an area of memory to be used for the alternate
69 to inform the system of the existence and
70 location of the alternate signal stack.
73 When establishing a signal handler using
75 inform the system that the signal handler should be executed
76 on the alternate signal stack by
77 specifying the \fBSA_ONSTACK\fP flag.
79 The \fIss\fP argument is used to specify a new
80 alternate signal stack, while the \fIold_ss\fP argument
81 is used to retrieve information about the currently
82 established signal stack.
83 If we are interested in performing just one
84 of these tasks, then the other argument can be specified as NULL.
88 type used to type the arguments of this function is defined as follows:
93 void *ss_sp; /* Base address of stack */
94 int ss_flags; /* Flags */
95 size_t ss_size; /* Number of bytes in stack */
100 To establish a new alternate signal stack,
101 the fields of this structure are set as follows:
104 This field contains either 0, or the following flag:
107 .BR SS_AUTODISARM " (since Linux 4.7)"
108 .\" commit 2a74213838104a41588d86fd5e8d344972891ace
109 .\" See tools/testing/selftests/sigaltstack/sas.c in kernel sources
110 Clear the alternate signal stack settings on entry to the signal handler.
111 When the signal handler returns,
112 the previous alternate signal stack settings are restored.
114 This flag was added in order to make it safe
115 to switch away from the signal handler with
117 Without this flag, a subsequently handled signal will corrupt
118 the state of the switched-away signal handler.
119 On kernels where this flag is not supported,
123 when this flag is supplied.
127 This field specifies the starting address of the stack.
128 When a signal handler is invoked on the alternate stack,
129 the kernel automatically aligns the address given in \fIss.ss_sp\fP
130 to a suitable address boundary for the underlying hardware architecture.
133 This field specifies the size of the stack.
134 The constant \fBSIGSTKSZ\fP is defined to be large enough
135 to cover the usual size requirements for an alternate signal stack,
136 and the constant \fBMINSIGSTKSZ\fP defines the minimum
137 size required to execute a signal handler.
139 To disable an existing stack, specify \fIss.ss_flags\fP
141 In this case, the kernel ignores any other flags in
143 and the remaining fields
146 If \fIold_ss\fP is not NULL, then it is used to return information about
147 the alternate signal stack which was in effect prior to the
150 The \fIold_ss.ss_sp\fP and \fIold_ss.ss_size\fP fields return the starting
151 address and size of that stack.
152 The \fIold_ss.ss_flags\fP may return either of the following values:
155 The thread is currently executing on the alternate signal stack.
156 (Note that it is not possible
157 to change the alternate signal stack if the thread is
158 currently executing on it.)
161 The alternate signal stack is currently disabled.
163 Alternatively, this value is returned if the thread is currently
164 executing on an alternate signal stack that was established using the
167 In this case, it is safe to switch away from the signal handler with
169 It is also possible to set up a different alternative signal stack
170 using a further call to
172 .\" FIXME Was it intended that one can set up a different alternative
173 .\" signal stack in this scenario? (In passing, if one does this, the
174 .\" sigaltstack(NULL, &old_ss) now returns old_ss.ss_flags==SS_AUTODISARM
175 .\" rather than old_ss.ss_flags==SS_DISABLE. The API design here seems
179 The alternate signal stack has been marked to be autodisarmed
186 as a non-NULL value, one can obtain the current settings for
187 the alternate signal stack without changing them.
190 returns 0 on success, or \-1 on failure with
191 \fIerrno\fP set to indicate the error.
195 Either \fIss\fP or \fIold_ss\fP is not NULL and points to an area
196 outside of the process's address space.
199 \fIss\fP is not NULL and the \fIss_flags\fP field contains
203 The specified size of the new alternate signal stack
209 An attempt was made to change the alternate signal stack while
210 it was active (i.e., the thread was already executing
211 on the current alternate signal stack).
213 For an explanation of the terms used in this section, see
221 Interface Attribute Value
224 T} Thread safety MT-Safe
230 POSIX.1-2001, POSIX.1-2008, SUSv2, SVr4.
234 flag is a Linux extension.
236 The most common usage of an alternate signal stack is to handle the
238 signal that is generated if the space available for the
239 standard stack is exhausted: in this case, a signal handler for
241 cannot be invoked on the standard stack; if we wish to handle it,
242 we must use an alternate signal stack.
244 Establishing an alternate signal stack is useful if a thread
245 expects that it may exhaust its standard stack.
246 This may occur, for example, because the stack grows so large
247 that it encounters the upwardly growing heap, or it reaches a
248 limit established by a call to \fBsetrlimit(RLIMIT_STACK, &rlim)\fP.
249 If the standard stack is exhausted, the kernel sends
250 the thread a \fBSIGSEGV\fP signal.
251 In these circumstances the only way to catch this signal is
252 on an alternate signal stack.
254 On most hardware architectures supported by Linux, stacks grow
257 automatically takes account
258 of the direction of stack growth.
260 Functions called from a signal handler executing on an alternate
261 signal stack will also use the alternate signal stack.
262 (This also applies to any handlers invoked for other signals while
263 the thread is executing on the alternate signal stack.)
264 Unlike the standard stack, the system does not
265 automatically extend the alternate signal stack.
266 Exceeding the allocated size of the alternate signal stack will
267 lead to unpredictable results.
271 removes any existing alternate
273 A child process created via
275 inherits a copy of its parent's alternate signal stack settings.
276 The same is also true for a child process created using
278 unless the clone flags include
282 in which case any alternate signal stack that was established in the parent
283 is disabled in the child process.
289 For backward compatibility, glibc also provides
291 All new applications should be written using
298 different struct, and had the major disadvantage that the caller
299 had to know the direction of stack growth.
301 In Linux 2.2 and earlier, the only flag that could be specified
306 In the lead up to the release of the Linux 2.4 kernel,
308 .\" After quite a bit of web and mail archive searching,
309 .\" I could not find the patch on any mailing list, and I
310 .\" could find no place where the rationale for this change
312 a change was made to allow
315 .I ss.ss_flags==SS_ONSTACK
316 with the same meaning as
318 (i.e., the inclusion of
323 On other implementations, and according to POSIX.1,
325 appears only as a reported flag in
326 .IR old_ss.ss_flags .
327 On Linux, there is no need ever to specify
331 and indeed doing so should be avoided on portability grounds:
332 various other systems
333 .\" See the source code of Illumos and FreeBSD, for example.
339 The following code segment demonstrates the use of
343 to install an alternate signal stack that is employed by a handler
352 ss.ss_sp = malloc(SIGSTKSZ);
353 if (ss.ss_sp == NULL) {
358 ss.ss_size = SIGSTKSZ;
360 if (sigaltstack(&ss, NULL) == \-1) {
361 perror("sigaltstack");
365 sa.sa_flags = SA_ONSTACK;
366 sa.sa_handler = handler(); /* Address of a signal handler */
367 sigemptyset(&sa.sa_mask);
368 if (sigaction(SIGSEGV, &sa, NULL) == \-1) {