Call stack і stack frames — як читати стек викликів

1. Call stack: що це таке і навіщо він потрібен під час налагодження

Коли ви починаєте налагодження, може здаватися, що достатньо поставити breakpoint десь поруч і покроково пройтися кодом. Але справжня програма майже завжди складається з ланцюжків викликів: main() викликає обробник команди, обробник — функцію розбору, та — допоміжну перевірку, а далі вже щось «ламається». У цей момент ви опиняєтеся в маленькій функції й бачите лише локальні змінні. Але головне запитання інше: хто викликав цю функцію і з якими даними?

У таких ситуаціях налагоджувач має відповідати не лише на запитання «який рядок виконається зараз», а й на запитання «яким шляхом ми сюди прийшли». Цей шлях і є call stack (стек викликів): список активних викликів функцій, які ще не завершилися.

Ментальна модель: стек як стос справ

Уявіть, що кожна функція — це доручення. Коли програма викликає функцію, вона ніби кладе на стіл нову картку: «виконати доручення X». Поки доручення не завершено, тобто поки функція не виконала return, картка лежить зверху. Якщо всередині цього доручення викликається інше, нова картка теж лягає зверху. Коли внутрішнє доручення завершується, верхню картку знімають, і ми повертаємося до попередньої.

Це буквально відповідає слову «stack» — стос/стек, структура «останнім прийшов — першим пішов» (LIFO). Тому стек викликів зростає під час входу у функції й зменшується під час виходу з них.

Нижче — схема того, як це виглядає в момент, коли ми зупинилися всередині найглибшої функції:

flowchart TB
    A["main()"] --> B["handle_command()"]
    B --> C["set_done_by_id()"]
    C --> D["find_task_index_by_id()  <-- ми тут"]

На вершині цього ланцюжка, з погляду стека, розташована поточна функція find_task_index_by_id(). Нижче — та, що її викликала, set_done_by_id(), далі handle_command(), а внизу — main().

Stack frame: один виклик функції як окремий світ

Коли ви бачите call stack, важливо розуміти й друге слово з теми: frames (кадри, або фрейми стека). Якщо стек викликів — це «список функцій», то stack frame — це один конкретний виклик функції з його параметрами та локальними змінними.

Тобто set_done_by_id(tasks, 10) і set_done_by_id(tasks, 20) — це одна й та сама функція за назвою, але різні фрейми, бо це різні виклики з різними параметрами та різними локальними змінними.

Під час налагодження це принципово: коли ви перемикаєтеся між різними фреймами в call stack, змінюється контекст перегляду змінних. І якщо дивитися не туди, можна зробити «геніальний висновок», який буде повністю хибним. Типова ситуація: «усередині функції id дорівнює 0», хоча насправді id дорівнює 10 — просто ви дивитеся не на той фрейм.

2. Як читати стек викликів в IDE

Де верх, де низ і запитання «чому я тут»

Коли ви відкриваєте вікно Call Stack в IDE, то зазвичай бачите список рядків: функція → файл → рядок. Новачки часто сприймають його як «історію», але плутаються, де початок. Тут допомагає просте правило: верх стека — це те, що виконується зараз. Нижче — ті, хто привів нас сюди.

Правильний спосіб читати стек — ставити собі запитання в такій послідовності. Спочатку зафіксуйте, де ви зараз. Потім дайте відповідь на запитання «хто нас викликав». Далі піднімайтеся вище, доки не побачите місце, де дані стали неправильними або де було вибрано хибну гілку.

Можете тримати в голові маленьку табличку — вона справді заощаджує нерви:

Перемикання фреймів: чому «змінна зникла» і це нормально

Коли ви перемикаєте фрейм у налагоджувачі, змінюється набір доступних змінних. Це не помилка і не примха IDE, а наслідок областей видимості: різні функції мають різні локальні змінні.

Уявіть, що ви зупинилися всередині find_task_index_by_id(). У цьому фреймі ви бачите i, tasks, id (параметр функції). Але змінної commandLine там немає, бо вона могла бути локальною змінною в handle_command(). Щоб побачити commandLine, треба перейти до фрейму handle_command().

Тут діє важливе практичне правило: перш ніж аналізувати значення змінної, переконайтеся, що вибрано правильний фрейм. Це звучить банально, але рятує від налагодження «привидів».

3. Навчальний приклад: TaskBook і помилка, захована вище в стеці

Щоб call stack не залишився абстракцією, продовжимо єдиний навчальний контекст: невеликий консольний застосунок TaskBook — список завдань, у якому можна позначати завдання виконаним за id. Ми не будуємо тут «велику архітектуру» — нам важливо, щоб було достатньо функцій для ланцюжка викликів.

Почнімо з моделі завдання:

#include <string>

struct Task {
    int id = 0;
    std::string title;
    bool done = false;
};

Тепер уявімо, що в нас є команда done 10, і ми хочемо знайти завдання, для якого id == 10, а потім позначити його виконаним.

Функція пошуку з навмисною помилкою

Напишімо функцію, яка шукає індекс завдання за id. І навмисно припустімося типової логічної помилки: порівняємо tasks[i].id не з id, а з i. Код компілюється, часом навіть працює, і саме такі помилки налагоджувачі люблять, а люди — ні.

#include <optional>
#include <vector>

std::optional<std::size_t> find_task_index_by_id(const std::vector<Task>& tasks, int id) {
    for (std::size_t i = 0; i < tasks.size(); ++i) {
        if (tasks[i].id == static_cast<int>(i)) { // ПОМИЛКА: має бути == id
            return i;
        }
    }
    return std::nullopt;
}

Коли ви дивитеся на цей фрагмент окремо, помилка здається очевидною. Але в реальному житті перед вами 200 рядків, половина з яких «ніби нормальна», — і саме тут call stack та фрейми починають працювати як рентген.

Функція «позначити як виконане»

Тепер — функція вищого рівня, яка використовує пошук:

#include <iostream>

void set_done_by_id(std::vector<Task>& tasks, int id) {
    auto idx = find_task_index_by_id(tasks, id);
    if (!idx) {
        std::cout << "Завдання не знайдено\n";
        return;
    }
    tasks[*idx].done = true;
}

Ланцюжок викликів: main → обробник → set_done_by_id → пошук

Зберемо мінімальний ланцюжок. Він навмисно простий: нам потрібен саме «маршрут», щоб було на що дивитися в call stack.

#include <iostream>
#include <vector>

void handle_done_command(std::vector<Task>& tasks, int id) {
    set_done_by_id(tasks, id);
}

int main() {
    std::vector<Task> tasks{{10, "Вивчити C++", false}, {20, "Виправити помилки", false}};
    handle_done_command(tasks, 20);
    std::cout << tasks[1].done << '\n'; // очікуємо 1, але отримаємо 0
}

За такої помилки ви побачите, що tasks[1].done залишиться false. І ось тут починається налагодження.

Як call stack допомагає знайти помилку

Припустімо, ви поставили точку зупину у find_task_index_by_id() на рядок return i; або на рядок return std::nullopt; і запустили налагодження.

Ви зупинилися всередині find_task_index_by_id(). У локальних змінних бачите i і tasks[i].id. Але головне запитання таке: який id шукали й хто попросив це зробити?

Саме тут ви відкриваєте Call Stack і бачите ланцюжок:

• find_task_index_by_id(tasks, id)
• set_done_by_id(tasks, id)
• handle_done_command(tasks, id)
• main()

Далі ви переходите до фрейму set_done_by_id(...) і дивитеся на параметр id. Там буде 20. Це ключовий момент: у поточному фреймі ви бачите локальну механіку пошуку, а в батьківському — сенс виклику.

Після цього ви повертаєтеся до поточного фрейму find_task_index_by_id() і дивитеся, що відбувається в умові tasks[i].id == static_cast<int>(i). І бачите абсурд: id дорівнює 20, але порівнюємо ми його з i.

Помилка стає очевидною саме тому, що ви зіставили два фрейми: «що хотіли» (батьківський) і «що робимо» (поточний).

4. Рекурсія і стек викликів

Рекурсія — особливий випадок, у якому call stack стає особливо наочним: одна й та сама функція зʼявляється в стеці багато разів. Це часто лякає початківців: «чому fact десять разів?!» — але це просто десять різних фреймів, тобто десять різних викликів.

Ось короткий приклад обчислення факторіала:

#include <iostream>

long long fact(int n) {
    if (n <= 1) return 1;
    return n * fact(n - 1);
}

int main() {
    std::cout << fact(4) << '\n'; // 24
}

Якщо поставити точку зупину на рядок return n * fact(n - 1);, то стек міститиме кілька фреймів fact, і кожен із них відрізнятиметься значенням n.

Уміння в такий момент перемикати фрейми й дивитися параметри — це майже «рентген» алгоритму: ви буквально бачите, як рекурсія розгортається, а потім згортається назад.

Тут корисно памʼятати ще одне практичне правило: у рекурсії ви майже завжди розрізняєте рівні за параметрами. І налагоджувач дає вам це безкоштовно: просто переходьте між сусідніми фреймами fact і дивіться, як змінюється n.

5. Як стек змінюється під час Step Into і Step Out

Call stack — не статична картинка: він «дихає» разом із вашим покроковим виконанням. Це дуже корисно розуміти, бо так ви перестаєте сприймати налагоджувач як кіно й починаєте сприймати його як приладову панель.

Коли ви натискаєте Step Into на рядку з викликом функції, до стека додається новий фрейм: ви заходите в нову функцію. Коли ви натискаєте Step Out, поточна функція завершується — тобто виконує return — і верхній фрейм зникає. Ви повертаєтеся до функції, що її викликала.

Якщо ви колись плуталися, «чому я раптом опинився в іншому місці», то це майже завжди пояснюється зміною стека: ви або зайшли глибше, або вийшли назовні. Тому корисна звичка така: коли ви втратили нитку, просто погляньте на call stack і спитайте себе: «я зараз в основній логіці чи в допоміжній функції?»

6. Типові помилки під час роботи з call stack і frames

Помилка № 1: читати стек «знизу вгору», ніби це поточний шлях виконання.
Нижня частина стека — це початок історії (main() і те, що його викликало), а верхня — те, що виконується просто зараз. Якщо переплутати напрям, ви легко зробите неправильний висновок про порядок викликів: думатимете, що main() викликали з find_task_index_by_id(), хоча все навпаки.

Помилка № 2: аналізувати змінні не в тому фреймі.
Типовий сценарій: ви зупинилися в find_task_index_by_id(), але хочете дізнатися, що було в рядку, який увів користувач. А цей рядок зберігається в handle_command(). Якщо не перемкнутися на потрібний фрейм, ви або не знайдете змінну взагалі («зникла!»), або дивитиметеся на однойменну змінну з іншого контексту й дивуватиметеся, чому вона «не та».

Помилка № 3: звинувачувати поточну функцію, не перевіривши вхідні дані.
Коли ви зупинилися в маленькій функції, перша реакція часто така: «ось тут і помилка!». Але дуже часто проблема в тому, що сюди передали неправильні аргументи. Стек якраз і потрібен для того, щоб піднятися на фрейм вище й подивитися, хто і які значення передав. У нашому прикладі із завданнями саме порівняння «що хотіли знайти» (параметр id у функції, що викликає) і «що реально порівнюємо» (умова в поточній) швидко виявляє проблему.

Помилка № 4: плутатися під час рекурсії й вважати однакові імена функцій дублікатами.
Однакова назва в стеці під час рекурсії — це не баг і не «зламаний налагоджувач», а нормальна картина: кожен фрейм відповідає своєму рівню рекурсії. Розрізняти рівні треба за значеннями параметрів, а не за назвою функції. Якщо тримати це в голові, рекурсія перестає бути містикою і стає звичайною послідовністю викликів.

Помилка № 5: робити висновки, не зафіксувавши, де саме ви зупинилися.
Іноді налагоджувач зупинився у функції не тому, що «тут помилка», а тому, що ви випадково зайшли через Step Into, або тому, що спрацював старий breakpoint. Перш ніж аналізувати стек, корисно на секунду зупинитися й зрозуміти: «чому я тут?» — точка зупину, ручна пауза, кінець кроку чи ви справді прийшли сюди за логікою розслідування.