pengantar
Saat kami mengerjakan Diablo IV, kami menulis semua kode di Windows dan kemudian mengkompilasinya untuk platform yang berbeda. Ini juga berlaku untuk server kami yang menjalankan Linux. (Kode menyertakan arahan kompilasi bersyarat dan, jika perlu, berisi fragmen yang ditulis khusus untuk platform tertentu.) Pekerjaan kami diatur seperti ini karena berbagai alasan. Sebagai permulaan, keterampilan profesional utama tim kami adalah Windows. Bahkan programmer server kami paling akrab dengan pengembangan Windows. Kami menghargai kemampuan untuk menggunakan alat yang sama dan basis pengetahuan yang sama oleh semua pemrogram di tim kami.
Alasan terpenting lainnya mengapa kami melakukan pengembangan pada Windows adalah kemampuan untuk memanfaatkan seperangkat alat yang sangat fungsional dan andal yang diberikan Visual Studio kepada kami. Dan bahkan jika kami mengembangkan sesuatu di Linux, maka saya dapat mengatakan bahwa tidak ada di dunia Linux yang dapat dibandingkan dengan Visual Studio.
Benar, karena ini, kami menghadapi beberapa kesulitan yang muncul saat server macet dan kami perlu men-debug dump memori. Kami memiliki kemampuan untuk masuk dari jarak jauh ke mesin virtual (atau, lebih tepatnya, ke dalam wadah) yang gagal, kami dapat menjalankan gdb untuk mencari tahu alasan apa yang terjadi. Tetapi pendekatan ini memiliki banyak kelemahan. Misalnya - kami tidak menerapkan binari bersama dengan kode sumber - akibatnya, saat bekerja dengan mesin virtual atau dengan penampung, kode sumber tidak tersedia di sesi gdb.
Komplikasi lain terletak pada gdb itu sendiri. Faktanya adalah bahwa jika kita tidak menggunakan alat ini terus-menerus, secara teratur, itu tidak dapat dikuasai pada tingkat yang sesuai untuk kita. Sederhananya, pengembang kami akan jauh lebih bersedia menggunakan alat yang sudah dikenal untuk men-debug kode. Karena hanya 2-3 pengembang kami yang tahu gdb dengan baik, ketika terjadi kesalahan, merekalah yang mencari masalah tersebut. Dan ini tidak bisa disebut distribusi beban kerja yang optimal untuk pemrogram.
Kami selalu ingin menemukan cara untuk men-debug kode Linux yang intuitif. Itulah mengapa kami sangat senang dapat menggunakan fitur Visual Studio baru yang memungkinkan kami menyelesaikan masalah ini dengan tepat di lingkungan yang akrab! Dan tidak berlebihan untuk mengatakan bahwa berkat ini impian kami menjadi kenyataan.
Tentang proses debugging kode kami
Debugging kode Linux di Visual Studio hanya mungkin jika Subsistem Windows untuk Linux (WSL) diinstal di sistem, atau jika sambungan ke Linux dikonfigurasi di Manajer Sambungan . Semua pengembang backend kami telah menginstal WSL menggunakan distribusi tempat kami menerapkan proyek kami. Kami menjalankan skrip yang saya tulis yang menginstal semua alat pengembangan dan pustaka dukungan yang diperlukan untuk membangun server kami di WSL.
(Saya akan menyimpang sejenak dari topik utama kami. Saya ingin menekankan bahwa kami telah sampai pada kesimpulan bahwa WSL adalah lingkungan terbaik yang ada yang memungkinkan pengembang untuk menguji perubahan dalam build Linux. Skema kerja ini terlihat sangat nyaman: beralih ke WSL, menggunakan perintah
cd
untuk masuk ke direktori kode bersama dan membangun proyek langsung dari sana. Ini adalah solusi yang jauh lebih baik daripada menggunakan mesin virtual atau bahkan kontainer. Jika Anda membangun proyek menggunakan CMake, Anda juga dapat menggunakan dukungan Visual Studio built-in untuk WSL .)
Saya akan memberi tahu Anda sedikit tentang majelis kami. Kami mengembangkan kode pada Windows dan kami memiliki versi Windows dari server kami yang dirancang untuk bekerja pada OS ini. Ini berguna bagi kami saat mengerjakan kapabilitas proyek biasa. Tapi kami menerapkan kode sisi server kami di Linux, yang membutuhkan build di Linux. Rakitan Linux dibuat di build farm. Ini menggunakan sistem build yang berjalan di komputer Linux. Dengan bantuannya, proyek server kami dan penampung terkait dirakit, yang kemudian disebarkan. Biner Linux hanya di-deploy di container. Biasanya pengembang tidak memiliki akses ke wadah ini.
Ketika salah satu server di infrastruktur kami gagal, kami diberitahu tentang hal ini dengan skrip khusus, setelah itu file dump ditulis ke folder jaringan bersama. Untuk men-debug file ini, baik di Linux atau Visual Studio, Anda memerlukan program yang berfungsi. Saat men-debug, sebaiknya gunakan pustaka bersama yang sama persis dengan yang digunakan dalam penampung yang diterapkan. Kami menggunakan skrip yang berbeda untuk mendapatkan file ini. Pertama, kami menyalin dump ke mesin lokal, dan kemudian kami menjalankan skrip dan menyampaikan informasi tentang dump ini. Skrip mendownload container Docker yang dibuat untuk versi kode yang diuji, mengekstrak file yang dapat dieksekusi dari server kami, serta library runtime umum tertentu. Semua ini dibutuhkan untuk gdb. (Ini, saat bekerja dengan gdb, menghindari masalah kompatibilitas yang mungkin muncul jikajika versi WSL sistem tidak persis sama dengan versi Linux yang diterapkan.) Skrip, menyiapkan sesi debugging, menulis data ke
~/.gdbinit
, menunjukkan bahwa perpustakaan bersama adalah perpustakaan sistem.
Lalu kita pergi ke Visual Studio, tempat kesenangan dimulai. Kami mengunduh solusi build untuk versi Windows server kami. Kemudian kami membuka dialog debug baru menggunakan perintah
Debug -> Other Debug Targets -> Debug Linux Core Dump with Native Only
. Kami mencentang kotak
Debug on WSL
dan memasukkan jalur ke file dump dan binari server (ditujukan untuk WSL!). Setelah itu, cukup tekan tombolnya
Debug
dan lihat apa yang terjadi.
Memulai Debugging di Visual Studio
Visual Studio secara otomatis meluncurkan gdb di WSL. Setelah sistem bekerja dengan disk selama beberapa waktu, tumpukan panggilan program yang gagal ditampilkan, dan penunjuk instruksi disetel ke baris kode yang sesuai. Ini benar-benar dunia baru yang berani!
Selanjutnya, kita berurusan dengan identifikasi kegagalan itu sendiri. Kami memiliki penangan kesalahan yang menyadap kejadian yang sesuai untuk menjalankan beberapa prosedur layanan. Oleh karena itu, informasi tentang kegagalan itu sendiri terletak, di server single-threaded, lebih dalam di tumpukan panggilan. Tetapi beberapa server kami multithread. Dan kerusakan dapat terjadi di salah satu utas mereka. Penangan kesalahan mencatat informasi tentang kode file yang salah dan tentang nomor baris. Oleh karena itu, memeriksa data ini memberi kita petunjuk pertama. Kami mencari tempat di tumpukan panggilan yang sesuai dengan eksekusi kode ini.
Di masa lalu, yaitu beberapa minggu yang lalu, kami akan menggunakan gdb untuk melacak mundur semua utas, dan kemudian memindai daftar yang dihasilkan untuk menemukan utas yang tumpukan panggilannya kemungkinan besar macet. Misalnya, jika utas dalam keadaan tidak aktif, kemungkinan besar utas itu tidak macet. Kami membutuhkan tumpukan yang memiliki lebih dari beberapa bingkai dan informasi yang kami hadapi dengan benang tidur. Selanjutnya, kita perlu memeriksa kodenya untuk memahami apa masalahnya. Jika itu sesuatu yang sederhana, Anda dapat melihatnya langsung di kode. Jika kami menghadapi masalah yang lebih rumit, kami harus menggunakan kemampuan gdb untuk menyelidiki status proses.
Tetapi Visual Studio memberi kami kemampuan yang jauh lebih kuat daripada yang kami miliki sebelumnya. Dalam lingkungan multithread, Anda dapat membuka jendela dalam sesi debug
Threads
dan mengklik utas untuk melihat tumpukannya. Ini, bagaimanapun, sangat mirip dengan pendekatan yang digunakan di gdb. Oleh karena itu, jika Anda perlu mempelajari, katakanlah, 50 utas, itu bisa berubah menjadi tugas yang memakan waktu dan membosankan. Untungnya, Visual Studio memiliki alat yang mempermudah tugas ini. Ini adalah jendela Parallel Stacks .
Saya akui, sebagian besar dari kami tidak tahu tentang Parallel Stacks sampai Erica Sweet dan timnya memberi tahu kami tentang hal itu. Jika selama sesi debug jalankan perintah
Debug -> Windows -> Parallel Stacks
- jendela baru akan terbuka, yang menampilkan informasi tentang tumpukan panggilan dari setiap utas dalam proses yang sedang diselidiki. Ini seperti pandangan luas dari seluruh ruang proses. Bingkai tumpukan apa pun dari utas apa pun dapat diklik dua kali. Setelah itu, Visual Studio akan melompat ke bingkai ini di jendela kode sumber dan jendela tumpukan panggilan. Ini sangat membantu kami menghemat waktu.
Setelah kami melihat kode di sekitar situs kerusakan, kami dapat memeriksa variabel menggunakan mouse, menggunakan QuickWatch, atau menggunakan salah satu dari banyak alat Visual Studio. Tentu saja, dalam build rilis, banyak variabel dioptimalkan, tetapi pada saat yang sama, banyak juga yang tidak! Kami, dengan menggunakan antarmuka Visual Studio, dapat menunjukkan masalah lebih cepat daripada sebelum menggunakan gdb.
Hasil
Tim kami sangat senang dapat men-debug dump Linux di Visual Studio, lingkungan tempat kami mengembangkan. Bagi kami, ini adalah peningkatan besar, karena memungkinkan lebih banyak pengembang daripada sebelumnya untuk mendiagnosis masalah di alam liar. Ini memungkinkan kita semua untuk memanfaatkan alat debugging yang kuat dari Visual Studio. Setelah persiapan awal lingkungan kerja selesai, Anda dapat berada dalam sesi debug Visual Studio dalam hitungan menit. Fitur ini sangat meningkatkan kecepatan menemukan masalah dan efisiensi pekerjaan kami. Terima kasih kepada Erica dan timnya atas bantuan mereka.
Apa yang menurut Anda paling berguna dalam Visual Studio?
