Men-debug dengan debugger GNU (gdb)
Men-debug dengan debugger GNU (GDB) lebih bermanfaat ketika OpenFOAM telah dikompilasi tanpa ada optimasi. Optimasi dilakukan oleh kompilator dan umumnya tidak mengganggu informasi debug yang dihasilkan untuk kode yang telah dikompilasi. Namun, memprofil dan memeriksa kode yang tidak dioptimalkan oleh kompilator mungkin memberikan wawasan lebih dalam tentang bottleneck komputasi yang tersembunyi.
Flag kompilator yang digunakan untuk OpenFOAM dibundel ke dalam kelompok opsi yang dapat dipertukarkan tergantung pada konfigurasi target.
Opsi kompilator dapat ditemukan dalam skrip konfigurasi global $WM_PROJECT_DIR/etc/bashrc dan tercantum di bawah ini:
Untuk mengaktifkan penggunaan OpenFOAM dalam mode debugging menggunakan gdb, variabel $WM_COMPILE_OPTION harus diatur sebagai berikut:
Agar perubahan ini berlaku, OpenFOAM harus dikompilasi ulang. Kompilasi ulang juga diperlukan untuk semua pustaka dan aplikasi kustom yang membutuhkan debugging. Harap diingat bahwa waktu eksekusi kode yang dikompilasi dengan opsi debug aktif jauh lebih lama.
INFO
Debugging dengan gdb cukup mudah dipahami dan terdapat banyak informasi tentang penggunaan gdb yang tersedia di situs web resmi www.gnu.org/software/gdb/.
Debugging kode kadang-kadang bisa sederhana untuk bug seperti segmen fault (mengakses alamat memori yang salah) atau pengecualian titik mengambang (pembagian dengan nol). Kesalahan-kesalahan tersebut dalam eksekusi kode memicu sinyal-sinyal sistem, seperti SIGFPE (sinyal pengecualian titik mengambang) dan SIGSEGV (sinyal pelanggaran segmen) dan ditangkap oleh debugger. Debugger kemudian memungkinkan pengguna untuk menjelajahi kode untuk menemukan kesalahan, menetapkan titik-titik henti, memeriksa nilai-nilai variabel, dan banyak lagi.
Untuk menunjukkan gdb dalam aksi, contoh debugging dengan gdb dibahas dalam bagian ini. Tutorial ini disediakan dalam repositori kode contoh di direktori ofprimer/applications/test/testDebugging. Tutorial ini terdiri dari aplikasi pengujian yang berisi sebuah fungsi template yang digunakan untuk menghitung rata-rata harmonik dari suatu lapangan yang diberikan, selama semua langkah waktu simulasi. Karena rata-rata harmonik melibatkan perhitungan x1, di mana x adalah nilai lapangan, sebuah pengecualian titik mengambang (SIGFPE) muncul jika kode dieksekusi pada lapangan yang mengandung nilai nol. Fungsi template didefinisikan dalam namespace fvc:: dan berperilaku mirip dengan operasi OpenFOAM lainnya. Namun, ia memiliki fungsionalitas yang sedikit berkurang. Untuk alasan ini, fungsi template
Definisi dan deklarasi dikemas bersama dengan aplikasi pengujian yang bukan (dan seharusnya tidak pernah) merupakan praktik standar.
Kasus simulasi tutorial yang dapat digunakan dengan contoh ini adalah kasus book-cases/chapter4/rising-bubble-2D. Memanggil aplikasi test-Debugging dengan argumen -field alpha.water di dalam direktori kasus risingBubble-2D menghasilkan kesalahan berikut:
Variabel $FOAM_USER_APPBIN tentu saja diperluas ke path yang sesuai di mesin Anda. Langkah pertama dalam men-debug masalah ini adalah memulai gdb, digabungkan dengan testDebugging. Semua komponen dari testDebugging harus dikompilasi dalam mode debug, ini juga termasuk semua pustaka yang menarik serta platform OpenFOAM.
Hal ini mengarah ke versi konsol dari gdb, yang digunakan untuk menjalankan program-program yang membutuhkan debugging:
Dalam konsol debugging gdb ini, setiap perintah dapat dieksekusi untuk tujuan debugging ketika diawali dengan perintah run. Untuk aplikasi testDebugging, ini berarti bahwa lapangan alpha1 juga harus dilewatkan sebagai argumen tambahan:
Setelah eksekusi perintah di atas, kesalahan SIGFPE muncul lagi, namun dengan lebih banyak detail:
Karena kompilasi OpenFOAM dan aplikasi dalam mode Debug, gdb menunjukkan langsung ke baris dalam kode sumber yang bertanggung jawab atas SIGFPE. Untuk contoh yang sangat dasar dari aplikasi testDebugging, menganalisis kode sumber secara manual mungkin akan menghasilkan wawasan yang sama. Dengan kompleksitas algoritma yang meningkat, kemungkinan bahwa pencarian manual untuk bug akan berhasil menjadi lebih rendah. Sementara menyisipkan pernyataan Info adalah metode pertama yang digunakan pemula untuk debugging, pada akhirnya itu menghabiskan waktu yang jauh lebih banyak daripada belajar beberapa perintah gdb dasar. Debugger, di sisi lain, dapat: menggunakan informasi yang disimpan pada tumpukan memori untuk memasuki fungsi-fungsi, menjalankan loop satu iterasi demi satu iterasi, mengubah nilai variabel, menetapkan titik-titik henti dalam eksekusi, mengkondisikan titik-titik henti berdasarkan nilai variabel, dan banyak opsi lanjutan lainnya yang dapat Anda temukan dalam dokumentasi debugger.
Untuk meninjau alur kerja dasar dengan gdb, kesalahan yang disebutkan di atas diasumsikan terjadi di dalam basis kode yang rumit. Kode ini terletak di sebuah pustaka dengan kelas-kelas yang tidak kohesif yang sangat terkait dengan antarmuka berat dan fungsi anggota yang meluas hingga ratusan baris. Dalam situasi ini, programmer perlu memeriksa kode di atas dan di bawah baris sinyal untuk mendapatkan pemahaman tentang konteks eksekusi. Debugger dapat menampilkan jalur yang telah diambil oleh sinyal: dari panggilan tingkat atas dalam aplikasi pengujian, sampai ke kontainer level rendah yang menyebabkan kesalahan ini. Informasi ini dapat diperoleh di dalam gdb, dengan menjalankan frame di konsol gdb:
Karena contoh testDebugging hanya terdiri dari fungsi utama, hanya ada satu frame tumpukan yang tersedia, di mana informasi tentang kode objek fungsi disimpan. Ketika beberapa panggilan fungsi dilakukan, ada beberapa frame yang tersedia. Frame terendah dari sinyal SIGSEV biasanya mengarah ke suatu tempat pada kontainer dasar OpenFOAM UList. Namun, sangat tidak mungkin bahwa kesalahan disebabkan oleh UList, dan jauh lebih mungkin bahwa itu disebabkan oleh kode kustom. Dalam kasus ini, kesalahan penanganan di dalam suatu kontainer (yang mewarisi dari UList) adalah alasan terjadinya kesalahan.
Memilih frame 0 dan menampilkan daftar kode sumber dengan perintah list, mempersempit lokasi kesalahan:
Oleh karena itu, penyebab sinyal SIGFPE adalah baris 80. Untuk menempatkan titik henti di baris 80, perintah break harus dieksekusi dan testDebugging harus dijalankan ulang:
Setelah menempatkan titik henti di baris 80, variabel I dapat dievaluasi pada posisi ini:
Mencetak resultField[I] menunjukkan bahwa nilainya adalah 0. Untuk memeriksa pengaruh nilai-nilai berbeda dari resultField[I], mereka dapat diatur secara manual menggunakan gdb:
