Роббинс Арнольд
Шрифт:
1 /* ch12-memleak.с --- демонстрирует утечки памяти с помощью setjmp/longjmp. */
2
3 #include <stdio.h>
4 #include <malloc.h> /* для определения ptrdiff_t в GLIBC */
5 #include <setjmp.h>
6 #include <unistd.h>
7
8 jmp_buf env;
9
10 void f1(void), f2(void);
11
12 /* main --- утечка памяти с помощью setjmp и longjmp */
13
14 int main(void)
15 {
16 char *start_break;
17 char *current_break;
18 ptrdiff_t diff;
19
20 start_break = sbrk((ptrdiff_t)0);
21
22 if (setjmp(env) == 0) /* первый раз */
23 printf("setjmp called\n");
24
25 current_break = sbrk((ptrdiff_t) 0);
26
27 diff = current_break - start_break;
28 printf("memsize = %ld\n", (long)diff);
29
30 f1;
31
32 return 0;
33 }
34
35 /* f1 --- выделяет память, осуществляет вложенный вызов */
36
37 void f1(void)
38 {
39 char *p = malloc(1024);
40
41 f2;
42 }
43
44 /* f2 --- выделяет память, выполняет longjmp */
45
46 void f2(void)
47 {
48 char *p = malloc(1024);
49
50 longjmp(env, 1);
51 }
Эта программа устанавливает бесконечный цикл, используя
setjmp
и longjmp
. Строка 20 использует для нахождения текущего начала кучи sbrk
(см. раздел 3.2.3 «Системные вызовы: brk
и sbrk
»), а затем строка 22 вызывает setjmp
. Строка 25 получает текущее начало кучи; это место каждый раз изменяется, поскольку longjmp
повторно входит в код. Строки 27–28 вычисляют, сколько было выделено памяти, и выводят это количество. Вот что происходит при запуске: $ ch12-memleak /* Запуск программы */
setjmp called
memsize = 0
memsize = 6372
memsize = 6372
memsize = 6372
memsize = 10468
memsize = 10468
memsize = 14564
memsize = 14564
memsize = 18660
memsize = 18660
...
Память утекает из программы, как через решето. Она работает до тех пор, пока не будет прервана от клавиатуры или пока не закончится память (в этом случае образуется основательный дамп ядра).
Каждая из функций
f1
и f2
выделяют память, a f2
выполняет longjmp
обратно в main
(строка 51). Когда это происходит, локальные указатели (строки 39 и 48) на выделенную память пропали! Такие утечки памяти может оказаться трудно отследить, поскольку часто выделяются небольшие размеры памяти, и как таковые, они могут оставаться незамеченными в течение ряда лет [128] . Этот код явно патологический, но он предназначен для иллюстрации нашей мысли:
setjmp
и longjmp
могут вести к трудно обнаруживаемым утечкам памяти. Предположим, что f1
правильно вызвал free
. Было бы далеко неочевидно, что память никогда не будет освобождена. В более крупной и более реалистичной программе, в которой longjmp
мог быть вызван лишь посредством if
, найти такую утечку становится даже еще труднее.128
Такая утечка была у нас в
gawk
К счастью, она исправлена — Примеч. автора. Таким образом, при наличии
setjmp
и longjmp
динамическая память должна управляться посредством глобальных переменных, а у вас должен быть код, который обнаруживает вход через longjmp
(посредством проверки возвращаемого значения setjmp
). Такой код должен затем освободить динамически выделенную память, которая больше не нужна. В-шестых,
longjmp
и siglongjmp
не следует использовать из функций, зарегистрированных посредством atexit
(см. раздел 9.1.5.3 «Функции завершения»). В-седьмых,
setjmp
и longjmp
могут оказаться дорогими операциями на машинах с множеством регистров. При наличии всех этих проблем вы должны строго рассмотреть дизайн своей программы. Если вам не нужно использовать
setjmp
и longjmp
, то, может, стоит обойтись без их использования. Однако, если их использование является лучшим способом структурировать свою программу, продолжайте и используйте их, но делайте это осмотрительно.