Apa Itu Segmentation Fault?

Sebuah program C mencetak baris pertamanya lalu berhenti dengan pesan yang tidak ditulis siapa pun:

#include <stdio.h>

int main(void) {
    int *score = NULL;

    printf("About to read the score\n");
    printf("Score: %d\n", *score);
    return 0;
}

About to read the score
bash: line 1: 64030 Segmentation fault: 11  ./seg

Output itu berasal dari bash di macOS, dengan 64030 sebagai ID proses dan 11 sebagai nomor sinyal. Di Linux, crash yang sama biasanya terbaca Segmentation fault (core dumped). Apa pun bentuknya, program tidak pernah mencetak skornya. score menyimpan alamat 0, dan *score meminta prosesor membaca memori di alamat itu, yang tidak boleh dilakukan program mana pun.

Bagaimana segmentation fault terjadi

Setiap program berjalan di ruang alamat virtualnya sendiri, rentang alamat yang sangat besar yang diisi sedikit demi sedikit oleh sistem operasi. Sistem operasi memetakan kode program, variabel globalnya, stack-nya, dan heap-nya ke rentang itu, dalam blok-blok yang disebut page (4 KB di sebagian besar sistem Linux x86, 16 KB di Mac dengan Apple silicon). Sebagian besar alamat dibiarkan tidak terpetakan, dan alamat 0 selalu termasuk di antaranya supaya bug null pointer tertangkap.

1. Program mengeksekusi instruksi yang membaca atau menulis sebuah alamat. Di sini instruksinya adalah membaca *score, alamat 0.
2. Memory management unit pada prosesor mencari alamat itu di page table. Page-nya tidak terpetakan, atau program mencoba menulis ke page yang hanya bisa dibaca.
3. Prosesor menghentikan instruksi itu dan menyerahkan kendali ke kernel dengan sebuah page fault.
4. Kernel memeriksa apakah akses itu bisa saja sah, misalnya stack yang perlu membesar. Ternyata tidak, jadi kernel mengirim sinyal 11, SIGSEGV, ke proses itu.
5. Tindakan default untuk SIGSEGV adalah mengakhiri proses dan, kalau sistemnya mengizinkan, menyimpan core dump. Shell lalu mencetak pesannya dan mengisi exit status dengan 139, yaitu 128 ditambah nomor sinyalnya.

Jadi segmentation fault tidak dilaporkan oleh compiler, dan bukan exception yang dimunculkan bahasanya. Ini adalah hardware dan kernel yang sedang melindungi memori, yang menjadikannya runtime error yang paling mendadak. Windows menangani kejadian yang sama sebagai access violation, dengan kode exception 0xC0000005.

Penyebab umum segmentation fault

C dan C++ membolehkan program menghitung alamat apa pun dan memakainya, jadi penyebabnya selalu bermuara pada pemakaian alamat yang tidak valid.

• Dereference null pointer. int *p = NULL; *p = 5; Fungsi yang mengembalikan NULL saat gagal, seperti malloc atau fopen, berujung ke sini kalau hasilnya tidak diperiksa.
• Index yang jauh melewati akhir sebuah array. C tidak memeriksa batas, jadi arr[1000000] hanyalah alamat yang sejuta elemen lebih jauh.
• Memakai memori setelah free. Pointer-nya masih menyimpan alamat lama, tetapi memorinya sudah bukan milikmu lagi.
• Pointer yang belum diinisialisasi. int *p; *p = 5; menulis lewat nilai sampah apa pun yang kebetulan disimpan p.
• Stack overflow. Fungsi rekursif tanpa kasus berhenti terus menambah stack frame sampai melewati ujung stack. Contoh di bawah crash di macOS dengan Segmentation fault: 11 dan exit status 139.
• Menulis ke string literal. char *name = "coddy"; name[0] = 'C'; mencoba mengubah memori yang hanya bisa dibaca. Di Linux, itu segfault. Di macOS, program yang sama berhenti dengan Bus error: 10, sinyal yang berkerabat.

#include <stdio.h>

int depth(int n) {
    return depth(n + 1) + 1;   /* never stops calling itself */
}

int main(void) {
    printf("%d\n", depth(0));
    return 0;
}

Kesalahan kecil sering kali sama sekali tidak menyebabkan crash, dan justru itu yang membuatnya lebih berbahaya. Loop ini membaca satu elemen melewati akhir array berisi tiga elemen:

#include <stdio.h>

int main(void) {
    int scores[3] = {72, 88, 95};
    int total = 0;

    for (int i = 0; i <= 3; i++) {   /* <= reads scores[3] */
        total += scores[i];
    }
    printf("Total: %d\n", total);
    return 0;
}

Di-compile dengan Clang di Mac, program ini mencetak Total: 256. Total yang benar adalah 255. scores[3] adalah 4 byte berikutnya di stack, yang masih milik program, jadi tidak ada fault yang terjadi dan nilai sampahnya ditambahkan diam-diam. Sistem operasi hanya menghentikan akses ke memori yang sama sekali bukan milik program.

Perbaikan untuk kedua kesalahan itu adalah kebiasaan yang sama: ketahui ada berapa elemen, dan periksa pointer sebelum mengikutinya.

#include <stdio.h>

/* Returns a pointer to the highest score, or NULL if there are none. */
int *find_best(int *scores, int count) {
    if (count == 0) {
        return NULL;
    }
    int *best = &scores[0];
    for (int i = 1; i < count; i++) {
        if (scores[i] > *best) {
            best = &scores[i];
        }
    }
    return best;
}

int main(void) {
    int scores[3] = {72, 88, 95};
    int *best = find_best(scores, 3);
    int *none = find_best(scores, 0);
    if (best != NULL) printf("Best: %d\n", *best);
    if (none == NULL) printf("No scores, nothing to read\n");
    return 0;
}

Best: 95
No scores, nothing to read

Apa arti "core dumped"

Core dump adalah file yang menyimpan salinan memori program pada saat program crash. Debugger bisa membukanya belakangan dan menunjukkan dengan tepat di mana program berada dan apa isi variabel-variabelnya: gdb ./app core. Di banyak distribusi Linux, systemd-coredump mengumpulkan file-file ini, dan coredumpctl list menampilkannya. Saat core dump dimatikan, misalnya dengan ulimit -c 0, pesannya hanya Segmentation fault, tanpa kata-kata di dalam kurung.

Cara menemukan baris yang crash

Baris tempat program crash sering kali bukan baris yang berisi bug. Sebuah pointer bisa menjadi tidak valid di satu fungsi lalu dipakai di fungsi lain jauh setelahnya. Tool-tool berikut menunjukkan keduanya.

Debugger. Compile dengan informasi debug lalu jalankan program di dalam debugger. Saat program berhenti, bt (backtrace) mencetak rantai pemanggilan fungsi beserta nama file dan nomor barisnya. Di Linux debugger-nya biasanya gdb; di macOS lldb, dan di sana bt bekerja dengan cara yang sama.

gcc -g app.c -o app
gdb ./app
(gdb) run
(gdb) bt

AddressSanitizer. Compile dengan -fsanitize=address (GCC dan Clang sama-sama mendukungnya) lalu jalankan program seperti biasa. Alih-alih segfault tanpa keterangan, tool ini mencetak laporan yang menyebutkan jenis kesalahannya, seperti heap-use-after-free atau stack-buffer-overflow, beserta baris yang melakukan akses dan baris yang mengalokasikan memorinya. Tool ini juga menangkap pembacaan satu elemen setelah akhir array yang diam-diam di atas, yang tidak pernah crash dengan sendirinya.

Valgrind. Di Linux, valgrind ./app menjalankan program tanpa perlu diubah dan melaporkan setiap pembacaan atau penulisan yang tidak valid, seperti Invalid read of size 4.

Segmentation fault di bahasa lain

Python, Java, dan JavaScript memeriksa setiap index dan setiap referensi sebelum memakainya, jadi kesalahan yang sama menjadi exception dengan pesan yang jelas: IndexError atau AttributeError di Python, ArrayIndexOutOfBoundsException atau NullPointerException di Java, TypeError di JavaScript. Semua itu bisa ditangkap dengan exception handling. Segfault tidak bisa ditangani dengan cara itu: segfault adalah sinyal, dan blok catch di C++ tidak melihatnya.

Program Python tetap bisa segfault saat kode C di bawahnya gagal. Baris ini meminta ctypes membaca alamat 0:

import ctypes
ctypes.string_at(0)

Dijalankan dengan python3 -X faulthandler, Python 3.12 mencetak Fatal Python error: Segmentation fault, diikuti baris-baris Python yang sedang berjalan. Crash yang sama terjadi saat ekstensi C atau library native punya bug memori. Rust mengambil pendekatan berbeda: compiler-nya menolak sebagian besar kode yang bisa mengakses memori tidak valid sebelum program dibangun.

Lanjut ke mana

Panduan C tentang segmentation fault membahas setiap penyebabnya dengan program minimal beserta perbaikannya. Untuk menghindari kesalahan-kesalahan ini sejak awal, baca tentang pointer, null pointer, serta stack dan heap, lalu latih semuanya di kursus C. Untuk cara error dilaporkan di bahasa yang memeriksa memori untukmu, lihat halaman runtime error.