Apa itu schrödinbug?

Halaman wiki ini memberi tahu:

Schrödinbug adalah bug yang bermanifestasi hanya setelah seseorang membaca kode sumber atau menggunakan program dengan cara yang tidak biasa, mengetahui bahwa itu tidak seharusnya bekerja sejak awal, di mana program tersebut segera berhenti bekerja untuk semua orang sampai diperbaiki. File Jargon menambahkan: "Meskipun ... ini terdengar mustahil, itu terjadi; beberapa program telah menyembunyikan schrödinbugs laten selama bertahun-tahun."

Apa yang sedang dibicarakan sangat kabur ..

Dapatkah seseorang memberikan contoh bagaimana schrödinbug itu seperti (seperti dengan situasi fiksi / kehidupan nyata)?

Dalam pengalaman saya polanya adalah ini:

• Sistem bekerja, seringkali selama bertahun-tahun
• Kesalahan dilaporkan
• Pengembang menyelidiki kesalahan dan menemukan sedikit kode yang tampaknya benar-benar cacat dan menyatakan bahwa itu "tidak akan pernah berhasil"
• Bug diperbaiki dan legenda kode yang tidak akan pernah bisa berfungsi (tetapi tidak selama bertahun-tahun) tumbuh

Mari bersikap logis di sini. Kode yang tidak akan pernah berhasil ... tidak akan pernah bisa berfungsi . Jika melakukan pekerjaan maka pernyataan tersebut adalah palsu.

Jadi saya akan mengatakan bahwa bug persis seperti yang dijelaskan (yang mengamati kode cacat berhenti bekerja) jelas-jelas omong kosong.

Pada kenyataannya apa yang terjadi adalah satu dari dua hal:

1) Pengembang belum sepenuhnya memahami kodenya . Dalam hal ini kode biasanya berantakan dan di suatu tempat di dalamnya memiliki kepekaan besar tetapi tidak jelas untuk beberapa kondisi eksternal (katakanlah versi OS tertentu atau konfigurasi yang mengatur bagaimana beberapa fungsi bekerja dalam beberapa cara kecil namun signifikan). Kondisi eksternal ini diubah (misalnya dengan peningkatan atau perubahan server yang diyakini tidak terkait) dan dengan demikian menyebabkan kode rusak.

Pengembang kemudian melihat kode dan, tidak memahami konteks historis atau memiliki waktu untuk menelusuri setiap dependensi dan skenario yang mungkin, menyatakan bahwa itu tidak akan pernah berhasil dan menulis ulang.

Dalam situasi ini, hal yang perlu dipahami di sini adalah bahwa gagasan "itu tidak akan pernah berhasil" terbukti salah (karena memang benar).

Itu tidak berarti menulis ulang itu adalah hal yang buruk - itu sering tidak, sementara itu baik untuk tahu persis apa yang salah sering menghabiskan waktu dan menulis ulang bagian kode sering lebih cepat dan memungkinkan Anda untuk memastikan bahwa Anda telah memperbaiki hal-hal.

2) Sebenarnya itu tidak pernah berhasil, hanya saja tidak ada yang pernah memperhatikan . Ini sangat umum, terutama dalam sistem besar. Dalam hal ini seseorang baru mulai dan mulai melihat hal-hal dengan cara yang belum pernah dilakukan sebelumnya, atau proses bisnis berubah yang membawa beberapa kasus tepi kecil ke dalam proses utama, dan sesuatu yang tidak pernah benar-benar bekerja (atau bekerja beberapa tetapi tidak semua waktu) ditemukan dan dilaporkan.

Pengembang melihatnya dan menyatakan "itu tidak akan pernah berhasil" tetapi para pengguna mengatakan "omong kosong, kami telah menggunakannya selama bertahun-tahun" dan mereka agak benar tetapi sesuatu yang mereka anggap tidak relevan (dan biasanya gagal disebutkan sampai pengembang menemukan kondisi yang tepat pada titik mana mereka pergi "oh ya, kami melakukan itu sekarang dan tidak sebelumnya") telah berubah.

Di sini pengembangnya benar - itu tidak akan pernah berhasil dan tidak pernah berhasil.

Namun dalam kedua kasus tersebut salah satu dari dua hal itu benar:

• Klaim "itu tidak akan pernah berhasil" adalah benar dan itu tidak pernah berhasil - orang hanya berpikir itu berhasil
• Itu berhasil dan pernyataan "itu tidak akan pernah berhasil" adalah salah dan turun ke (biasanya masuk akal) kurangnya pemahaman tentang kode dan ketergantungannya

Karena semua orang menyebutkan kode yang seharusnya tidak pernah berfungsi, saya akan memberikan Anda contoh yang saya temui, sekitar 8 tahun yang lalu pada proyek VB3 yang sedang sekarat yang sedang dikonversi ke .net. Sayangnya proyek ini harus terus diperbarui hingga versi .net selesai - dan saya adalah satu-satunya yang bahkan memahami VB3 dari jarak jauh.

Ada satu fungsi yang sangat penting yang disebut ratusan kali untuk setiap perhitungan - menghitung bunga bulanan untuk program pensiun jangka panjang. Saya akan mereproduksi bagian yang menarik.

Function CalculateMonthlyInterest([...], IsYearlyInterestMode As Boolean, [...]) As Double
    [about 30 lines of code]
    If IsYearlyInterestMode Then
        [about 30 lines of code]
        If Not IsYearlyInterestMode Then
            [about 30 lines of code (*)]
        End If
    End If
End Function

Bagian yang ditandai dengan bintang memiliki kode paling penting; itu adalah satu-satunya bagian yang melakukan perhitungan aktual. Jelas ini seharusnya tidak berhasil, bukan?

Butuh banyak debugging, tetapi saya akhirnya menemukan penyebabnya: IsYearlyInterestModeadalah True, dan Not IsYearlyInterestModejuga benar. Itu karena di suatu tempat di sepanjang garis seseorang melemparkannya ke integer, maka dalam suatu fungsi yang seharusnya mengaturnya menjadi benar menambahkannya (jika 0 untuk Falseitu akan diatur ke 1, yaitu VB True, jadi saya bisa melihat logika di sana), lalu masukkan kembali ke boolean. Dan saya ditinggalkan dengan kondisi yang tidak pernah bisa terjadi dan belum terjadi setiap saat.

Tidak tahu contoh dunia nyata, tetapi untuk menyederhanakannya dengan contoh situasi:

• Bug tidak diperhatikan untuk sementara waktu, karena aplikasi tidak menjalankan kode dalam kondisi yang menyebabkannya gagal.
• Seseorang memperhatikannya dengan melakukan sesuatu di luar penggunaan normal (atau memeriksa sumbernya).
• Sekarang bug diperhatikan, aplikasi gagal sampai kondisi normal juga, sampai bug diperbaiki.

Ini mungkin terjadi karena bug akan merusak beberapa keadaan aplikasi yang menyebabkan kegagalan dalam kondisi normal sebelumnya.

Contoh kehidupan nyata. Saya tidak dapat menampilkan kode, tetapi kebanyakan orang akan terkait dengan ini.

Kami memiliki perpustakaan internal besar fungsi utilitas tempat saya bekerja. Suatu hari saya sedang mencari fungsi untuk melakukan hal tertentu, dan saya menemukan Frobnicate()mencoba menggunakannya. Uh-oh: ternyata Frobnicate()selalu mengembalikan kode kesalahan.

Menggali implementasi, saya menemukan beberapa kesalahan logika dasar Frobnicate()yang membuatnya selalu gagal. Dalam kontrol sumber saya dapat melihat bahwa fungsi tersebut belum dimodifikasi sejak ditulis, artinya fungsi tersebut tidak pernah berfungsi sebagaimana dimaksud. Kenapa tidak ada yang memperhatikan ini? Saya mencari melalui sisa sumber pendaftaran dan menemukan bahwa semua penelepon yang Frobnicate()ada mengabaikan nilai kembali (dan karena itu mengandung bug halus mereka sendiri). Jika saya mengubah fungsi-fungsi itu untuk memeriksa nilai kembali seperti seharusnya, maka mereka mulai gagal juga.

Ini adalah kasus umum kondisi # 2 yang disebutkan Jon Hopkins dalam jawabannya, dan itu sangat umum di perpustakaan internal besar.

Inilah Schrödinbug nyata yang saya lihat di beberapa kode sistem. Daemon root perlu berkomunikasi dengan modul kernel. Jadi kode kernel membuat beberapa deskriptor file:

int pipeFDs[1];

lalu atur komunikasi melalui pipa yang akan dilampirkan ke pipa bernama:

int pipeResult = pipe(pipeFDs);

Ini seharusnya tidak berhasil. pipe()menulis dua deskriptor file ke dalam array, tetapi hanya ada ruang untuk satu. Tapi selama sekitar tujuh tahun itu melakukan kerja; array kebetulan sebelum beberapa ruang yang tidak terpakai dalam memori yang dikooptasi menjadi deskriptor file.

Kemudian, suatu hari, saya harus mem-port-kan kode ke arsitektur baru. Itu berhenti bekerja, dan bug yang seharusnya tidak berhasil ditemukan.

Akibat wajar dari Schrödinbug adalah Heisenbug - yang menggambarkan bug yang hilang (atau kadang-kadang muncul) ketika mencoba untuk menyelidiki dan / atau memperbaikinya.

Heisenbugs adalah blighter pintar dan mitos yang berlari dan bersembunyi saat debugger dimuat, tetapi keluar dari kayu setelah Anda berhenti menonton.

Pada kenyataannya, ini biasanya disebabkan oleh salah satu dari yang berikut ini:

• dampak optimasi itu, di mana kode yang dikompilasi -DDEBUGdioptimalkan ke tingkat yang berbeda dari rilis rilis
• perbedaan waktu yang halus karena bus komunikasi dunia nyata atau interupsi yang agak berbeda dari beban tiruan "sempurna" yang disimulasikan

Keduanya menyoroti pentingnya pengujian kode rilis pada peralatan rilis, serta pengujian unit / modul / sistem menggunakan emulator.

Saya telah melihat beberapa Schödinbugs dan selalu karena alasan yang sama:

Kebijakan perusahaan mensyaratkan bahwa setiap orang seharusnya menggunakan program.
Tidak ada yang benar-benar menggunakannya (kebanyakan karena tidak ada pelatihan untuk itu.)
Tapi mereka tidak bisa memberi tahu manajemen ini. Jadi semua orang harus mengatakan "Saya telah menggunakan program ini selama 2 tahun dan tidak pernah menemukan bug ini sampai hari ini."
Program ini tidak pernah benar-benar berfungsi, kecuali sebagian kecil pengguna (termasuk pengembang yang menulisnya.)

Dalam satu kasus, program tersebut telah mengalami banyak pengujian, tetapi tidak pada database nyata (yang dianggap terlalu sensitif, sehingga versi palsu digunakan.)

Saya punya contoh dari sejarah saya sendiri, ini sekitar 25 tahun yang lalu. Saya adalah seorang anak yang melakukan pemrograman grafis dasar di Turbo Pascal. TP memiliki pustaka yang disebut BGI yang mencakup beberapa fungsi yang memungkinkan Anda menyalin wilayah layar ke dalam blok memori berbasis-pointer, dan kemudian memutarnya di tempat lain. Dikombinasikan dengan xor-blitting pada layar hitam-putih itu dapat digunakan untuk melakukan animasi sederhana.

Saya ingin melangkah lebih jauh dan membuat sprite. Saya menulis sebuah program yang menggambar blok besar dan kontrol untuk mewarnainya, seperti yang Anda buat itu mereproduksi ini sebagai piksel, menghasilkan program menggambar sederhana untuk membuat sprite, yang kemudian dapat menyalin ke memori. Hanya ada satu masalah, untuk menggunakan sprite blitted ini, mereka harus disimpan ke file sehingga program lain bisa membacanya. Tapi TP tidak punya cara mengalokasikan alokasi memori berbasis penunjuk. Buku pedoman menyatakan bahwa mereka tidak dapat ditulis ke file.

Saya datang dengan sepotong kode yang, berhasil, menulis ke file. Dan mulai menulis program pengujian yang menghapus sprite dari program menggambar saya di latar belakang - dalam perjalanan saya membuat game. Dan itu berhasil, dengan indah. Namun keesokan harinya, itu berhenti bekerja. Itu tidak menunjukkan apa-apa selain kekacauan berantakan. Tidak pernah berhasil lagi. Saya membuat sprite baru, dan berhasil, sempurna - sampai tidak, dan itu berantakan lagi.

Butuh waktu lama tetapi akhirnya saya menemukan apa yang terjadi. Program menggambar itu, seperti yang saya pikir, menyimpan data piksel yang disalin ke file - itu menyimpan pointer itu sendiri. Ketika program berikutnya membaca file, itu berakhir dengan pointer ke blok memori yang sama - yang masih berisi apa yang ditulis oleh program terakhir di sana (ini di MS-DOS, manajemen memori tidak ada). Tapi itu berhasil ... sampai Anda mem-boot ulang, atau telah menjalankan apa pun yang menggunakan kembali area memori yang sama, dan kemudian Anda mendapatkan kekacauan yang kacau karena Anda memuntahkan sekelompok data yang sama sekali tidak terkait ke blok video-memory.

Seharusnya tidak pernah bekerja, seharusnya tidak pernah bahkan tampaknya berfungsi (dan pada OS nyata tidak akan) tetapi tetap saja, dan setelah itu rusak - itu tetap rusak.

Ini terjadi setiap saat ketika orang menggunakan debugger.

Lingkungan debugging berbeda dari lingkungan produksi sebenarnya - tanpa debugger - produksi.

Menjalankan dengan debugger dapat menutupi hal-hal seperti stack overflows karena tumpukan debugger menutupi bug.

Saya belum pernah melihat schrodinbug sejati dan saya tidak berpikir mereka bisa ada - menemukan itu tidak akan merusak segalanya.

Sebaliknya, sesuatu berubah yang mengekspos bug yang sudah lama bersembunyi. Apa pun yang diubah masih berubah dan dengan demikian bug terus muncul sementara pada saat yang sama seseorang menemukan bug.