Ini adalah pilihan cerita dari Internet tentang bagaimana pepijat kadangkala mempunyai manifestasi yang luar biasa. Mungkin anda mempunyai sesuatu untuk diberitahu juga.
Alahan kereta kepada aiskrim vanila
Kisah untuk jurutera yang memahami bahawa perkara yang jelas tidak selalu menjadi jawapan, dan tidak kira betapa jauhnya fakta yang kelihatan, mereka tetap fakta. Bahagian Pontiac General Motors Corporation menerima aduan:
Ini adalah kali kedua saya menulis kepada anda, dan saya tidak menyalahkan anda kerana tidak menjawab, kerana ia kedengaran gila. Kami sekeluarga mempunyai tradisi makan aiskrim setiap malam selepas makan malam. Jenis aiskrim berubah setiap kali, dan selepas makan malam, seisi keluarga memilih aiskrim yang mana untuk dibeli, selepas itu saya pergi ke kedai. Saya baru-baru ini membeli Pontiac baru dan sejak itu perjalanan saya untuk mendapatkan aiskrim telah menjadi masalah. Maklumlah, setiap kali saya membeli aiskrim vanila dan balik dari kedai, kereta tidak boleh hidup. Jika saya membawa apa-apa aiskrim lain, kereta dihidupkan tanpa sebarang masalah. Saya ingin bertanya soalan yang serius, tidak kira betapa bodohnya bunyinya: "Apa yang berlaku dengan Pontiac yang menjadikannya tidak bermula apabila saya membawa ais krim vanila, tetapi bermula dengan mudah apabila saya membawa rasa ais krim yang lain?" "
Seperti yang anda boleh bayangkan, presiden bahagian itu ragu-ragu tentang surat itu. Namun, untuk berjaga-jaga, saya menghantar jurutera untuk memeriksa. Dia terkejut apabila dia ditemui oleh seorang lelaki kaya dan berpendidikan tinggi yang tinggal di kawasan yang indah. Mereka bersetuju untuk berjumpa segera selepas makan malam supaya mereka berdua pergi ke kedai untuk membeli aiskrim. Petang itu adalah vanila, dan apabila mereka kembali ke kereta, ia tidak akan dihidupkan.
Jurutera itu datang tiga petang lagi. Kali pertama aiskrim adalah coklat. Kereta dihidupkan. Kali kedua ada aiskrim strawberry. Kereta dihidupkan. Pada petang ketiga dia meminta untuk mengambil vanila. Kereta tidak dihidupkan.
Menaakul secara rasional, jurutera itu enggan mempercayai bahawa kereta itu alah kepada aiskrim vanila. Oleh itu, saya bersetuju dengan pemilik kereta itu bahawa dia akan meneruskan lawatannya sehingga dia menemui jalan penyelesaian kepada masalah tersebut. Dan di sepanjang jalan, dia mula mencatat: dia menulis semua maklumat, masa hari, jenis petrol, masa ketibaan dan pulang dari kedai, dll.
Jurutera itu tidak lama kemudian menyedari bahawa pemilik kereta itu menghabiskan lebih sedikit masa untuk membeli aiskrim vanila. Sebabnya susun atur barang dalam kedai. Ais krim vanila adalah yang paling popular dan disimpan di dalam peti sejuk berasingan di hadapan kedai untuk memudahkan pencarian. Dan semua varieti lain berada di belakang kedai, dan memerlukan lebih banyak masa untuk mencari varieti yang sesuai dan membayar.
Sekarang persoalannya adalah untuk jurutera: mengapa kereta tidak dihidupkan jika masa yang kurang telah berlalu sejak saat enjin dimatikan? Memandangkan masalahnya adalah masa, bukan ais krim vanila, jurutera itu dengan cepat menemui jawapannya: ia adalah kunci gas. Ia berlaku setiap petang, tetapi apabila pemilik kereta menghabiskan lebih banyak masa mencari ais krim, enjin berjaya menjadi cukup sejuk dan dihidupkan dengan mudah. Dan apabila lelaki itu membeli aiskrim vanila, enjin masih terlalu panas dan kunci gas tidak sempat larut.
Moral: Masalah gila pun kadangkala nyata.
Crash Bandicoot
Memang menyakitkan untuk mengalami ini. Sebagai pengaturcara, anda terbiasa menyalahkan kod anda pertama, kedua, ketiga... dan di tempat yang sepuluh ribu anda menyalahkan pengkompil. Dan lebih jauh ke bawah senarai anda sudah menyalahkan peralatan.
Inilah cerita saya tentang pepijat perkakasan.
Untuk permainan Crash Bandicoot, saya menulis kod untuk memuatkan dan menyimpan ke kad memori. Bagi pembangun permainan yang sombong, ia seperti berjalan-jalan di taman: Saya fikir kerja itu akan mengambil masa beberapa hari. Walau bagaimanapun, saya akhirnya menyahpepijat kod selama enam minggu. Sepanjang perjalanan, saya menyelesaikan masalah lain, tetapi setiap beberapa hari saya kembali ke kod ini selama beberapa jam. Ia adalah penderitaan.
Gejalanya kelihatan seperti ini: apabila anda menyimpan permainan semasa permainan dan mengakses kad memori, semuanya hampir sentiasa berjalan lancar... Tetapi kadangkala tamat masa operasi baca atau tulis tanpa sebab yang jelas. Rakaman pendek sering merosakkan kad memori. Apabila pemain cuba menyelamatkan, dia bukan sahaja gagal menyelamatkan, tetapi juga memusnahkan peta. Crap.
Selepas beberapa ketika, penerbit kami di Sony, Connie Bus, mula panik. Kami tidak dapat menghantar permainan dengan pepijat ini, dan enam minggu kemudian saya tidak faham apa yang menyebabkan masalah itu. Melalui Connie, kami menghubungi pembangun PS1 yang lain: adakah sesiapa yang mengalami perkara serupa? Tidak. Tiada siapa yang mempunyai masalah dengan kad memori.
Apabila anda tidak mempunyai idea untuk penyahpepijatan, satu-satunya pendekatan yang tinggal ialah "membahagi dan menakluki": alih keluar semakin banyak kod daripada program yang rosak sehingga terdapat serpihan yang agak kecil yang masih menyebabkan masalah. Iaitu, anda memotong program sekeping demi sekeping sehingga bahagian yang mengandungi pepijat kekal.
Tetapi masalahnya, sangat sukar untuk memotong sebahagian daripada permainan video. Bagaimana untuk menjalankannya jika anda mengalih keluar kod yang meniru graviti? Atau melukis watak?
Oleh itu, kita perlu menggantikan keseluruhan modul dengan stub yang berpura-pura melakukan sesuatu yang berguna, tetapi sebenarnya melakukan sesuatu yang sangat mudah yang tidak boleh mengandungi ralat. Kami perlu menulis tongkat sedemikian untuk permainan sekurang-kurangnya berfungsi. Ini adalah proses yang perlahan dan menyakitkan.
Pendek kata, saya melakukannya. Saya mengeluarkan lebih banyak keping kod sehingga saya ditinggalkan dengan kod awal yang mengkonfigurasi sistem untuk menjalankan permainan, memulakan perkakasan rendering, dsb. Sudah tentu, pada peringkat ini saya tidak boleh mencipta menu simpan dan muatkan, kerana saya perlu membuat stub untuk semua kod grafik. Tetapi saya boleh berpura-pura menjadi pengguna menggunakan skrin simpan dan muat (tidak kelihatan) dan meminta untuk menyimpan dan kemudian menulis ke kad memori.
Ini meninggalkan saya dengan sekeping kecil kod yang masih mempunyai masalah di atas - tetapi ia masih berlaku secara rawak! Selalunya semuanya berfungsi dengan baik, tetapi kadangkala terdapat gangguan. Saya mengeluarkan hampir semua kod permainan, tetapi pepijat itu masih hidup. Ini membingungkan: kod yang tinggal sebenarnya tidak melakukan apa-apa.
Pada satu ketika, mungkin sekitar pukul tiga pagi, saya terfikir. Operasi baca dan tulis (input/output) melibatkan masa pelaksanaan yang tepat. Apabila anda bekerja dengan cakera keras, kad memori atau modul Bluetooth, kod peringkat rendah yang bertanggungjawab untuk membaca dan menulis melakukannya mengikut denyutan jam.
Dengan bantuan jam, peranti yang tidak disambungkan terus kepada pemproses disegerakkan dengan kod yang dilaksanakan pada pemproses. Jam menentukan kadar baudβkelajuan di mana data dihantar. Jika terdapat kekeliruan dengan pemasaan, maka sama ada perkakasan atau perisian, atau kedua-duanya, juga keliru. Dan ini sangat buruk, kerana data boleh rosak.
Bagaimana jika sesuatu dalam kod kami mengelirukan pemasaan? Saya menyemak semua yang berkaitan dengan ini dalam kod program ujian dan mendapati bahawa kami menetapkan pemasa boleh atur cara dalam PS1 kepada 1 kHz (1000 kutu sesaat). Ini agak banyak; secara lalai, apabila konsol bermula, ia berjalan pada 100 Hz. Dan kebanyakan permainan menggunakan frekuensi ini.
Andy, pembangun permainan, menetapkan pemasa kepada 1 kHz supaya pergerakan akan dikira dengan lebih tepat. Andy cenderung untuk melampaui batas, dan jika kita mencontohi graviti, kita melakukannya setepat mungkin!
Tetapi bagaimana jika mempercepatkan pemasa entah bagaimana menjejaskan pemasaan keseluruhan program, dan oleh itu jam yang mengawal kadar baud untuk kad memori?
Saya mengulas keluar kod pemasa. Ralat tidak berlaku lagi. Tetapi ini tidak bermakna kami membetulkannya, kerana kegagalan berlaku secara rawak. Bagaimana jika saya hanya bernasib baik?
Beberapa hari kemudian saya bereksperimen lagi dengan program ujian. Pepijat tidak berulang. Saya kembali ke pangkalan kod permainan penuh dan mengubah suai kod simpan dan muatkan supaya pemasa boleh atur cara akan ditetapkan semula kepada nilai asalnya (100Hz) sebelum mengakses kad memori, dan kemudian tetapkan semula kepada 1kHz. Tiada lagi kemalangan.
Tetapi mengapa ini berlaku?
Saya kembali ke program ujian semula. Saya cuba mencari beberapa corak dalam berlakunya ralat dengan pemasa 1 kHz. Akhirnya saya perasan bahawa ralat berlaku apabila seseorang bermain dengan pengawal PS1. Oleh kerana saya jarang melakukan ini sendiri - mengapa saya memerlukan pengawal semasa menguji simpan dan memuatkan kod? - Saya tidak perasan pergantungan ini. Tetapi pada suatu hari salah seorang artis kami sedang menunggu saya untuk menyelesaikan ujian - saya mungkin sedang mengutuk pada masa itu - dan dengan gementar memutar-mutar pengawal di tangannya. Ralat telah berlaku. "Tunggu apa?!" Baik, buat lagi!β
Apabila saya menyedari bahawa kedua-dua peristiwa ini saling berkaitan, saya dapat menghasilkan semula ralat dengan mudah: Saya mula merakam ke kad memori, mengalihkan pengawal dan merosakkan kad memori. Bagi saya ia kelihatan seperti pepijat perkakasan.
Saya datang kepada Connie dan memberitahunya tentang penemuan saya. Dia menyampaikan maklumat itu kepada salah seorang jurutera yang mereka bentuk PS1. "Mustahil," dia menjawab, "Ia tidak boleh menjadi masalah perkakasan." Saya meminta Connie mengaturkan perbualan untuk kami.
Jurutera itu menelefon saya dan kami berhujah dalam bahasa Inggerisnya yang rosak dan bahasa Jepun saya (amat sangat). Akhirnya saya berkata, "Biar saya hantar program ujian 30 baris saya di mana mengalihkan pengawal menyebabkan pepijat." Dia bersetuju. Mengatakan ia membuang masa dan bahawa dia sangat sibuk mengerjakan projek baharu, tetapi akan mengalah kerana kami adalah pembangun yang sangat penting untuk Sony. Saya membersihkan program ujian saya dan menghantarnya kepadanya.
Petang berikutnya (kami berada di Los Angeles dan dia berada di Tokyo) dia menelefon saya dan meminta maaf dengan malu-malu. Ia adalah masalah perkakasan.
Saya tidak tahu apa sebenarnya pepijat itu, tetapi daripada apa yang saya dengar di ibu pejabat Sony, jika anda menetapkan pemasa kepada nilai yang cukup tinggi, ia mengganggu komponen pada papan induk di sekitar kristal pemasa. Salah satu daripadanya ialah pengawal kadar baud untuk kad memori, yang juga menetapkan kadar baud untuk pengawal. Saya bukan seorang jurutera, jadi saya mungkin telah mengacaukan sesuatu.
Tetapi kesimpulannya ialah terdapat gangguan antara komponen pada motherboard. Dan apabila menghantar data secara serentak melalui port pengawal dan port kad memori dengan pemasa berjalan pada 1 kHz, bit hilang, data hilang, dan kad itu rosak.
lembu jahat
Pada tahun 1980-an, mentor saya Sergei menulis perisian untuk SM-1800, klon Soviet PDP-11. Komputer mikro ini baru sahaja dipasang di stesen kereta api berhampiran Sverdlovsk, hab pengangkutan penting di USSR. Sistem baharu itu direka bentuk untuk mengarahkan gerabak dan trafik barang. Tetapi ia mengandungi pepijat menjengkelkan yang membawa kepada ranap dan ranap sistem rawak. Jatuh selalu berlaku apabila seseorang pulang ke rumah pada waktu petang. Tetapi walaupun penyiasatan menyeluruh pada keesokan harinya, komputer berfungsi dengan betul dalam semua ujian manual dan automatik. Ini biasanya menunjukkan keadaan perlumbaan atau beberapa pepijat kompetitif lain yang berlaku dalam keadaan tertentu. Bosan dengan panggilan larut malam, Sergei memutuskan untuk menyelesaikannya, dan pertama sekali, fahami keadaan di halaman marshalling yang membawa kepada kerosakan komputer.
Pertama, dia mengumpul statistik semua kejatuhan yang tidak dapat dijelaskan dan mencipta graf mengikut tarikh dan masa. Corak itu jelas. Selepas memerhati selama beberapa hari lagi, Sergei menyedari bahawa dia boleh dengan mudah meramalkan masa kegagalan sistem masa depan.
Dia tidak lama kemudian mengetahui bahawa gangguan hanya berlaku apabila stesen itu sedang menyusun kereta api lembu dari utara Ukraine dan barat Rusia menuju ke pusat penyembelihan berhampiran. Ini sendiri adalah pelik, kerana rumah penyembelihan itu dibekalkan oleh ladang yang terletak lebih dekat, di Kazakhstan.
Loji kuasa nuklear Chernobyl meletup pada tahun 1986, dan kejatuhan radioaktif menyebabkan kawasan sekitar tidak dapat didiami. Kawasan yang luas di utara Ukraine, Belarus dan barat Rusia telah tercemar. Mengesyaki tahap radiasi yang tinggi dalam gerabak yang tiba, Sergei membangunkan kaedah untuk menguji teori ini. Penduduk dilarang daripada mempunyai dosimeter, jadi Sergei mendaftarkan dirinya dengan beberapa orang tentera di stesen kereta api. Selepas beberapa minuman vodka, dia berjaya meyakinkan seorang askar untuk mengukur tahap radiasi di salah satu gerabak yang mencurigakan. Ternyata tahap itu beberapa kali lebih tinggi daripada nilai biasa.
Bukan sahaja lembu itu mengeluarkan banyak sinaran, tahapnya sangat tinggi sehingga menyebabkan kehilangan rawak bit dalam ingatan SM-1800, yang terletak di bangunan bersebelahan stesen.
Terdapat kekurangan makanan di USSR, dan pihak berkuasa memutuskan untuk mencampurkan daging Chernobyl dengan daging dari wilayah lain di negara ini. Ini memungkinkan untuk mengurangkan tahap keseluruhan radioaktiviti tanpa kehilangan sumber yang berharga. Setelah mengetahui tentang ini, Sergei segera mengisi dokumen untuk berhijrah. Dan ranap komputer berhenti dengan sendirinya apabila tahap sinaran menurun dari semasa ke semasa.
Melalui paip
Suatu ketika dahulu, Movietech Solutions mencipta perisian untuk pawagam, direka untuk perakaunan, penjualan tiket dan pengurusan am. Versi DOS apl perdana agak popular di kalangan rangkaian teater filem bersaiz kecil dan sederhana di Amerika Utara. Jadi tidak menghairankan apabila versi Windows 95 diumumkan, disepadukan dengan skrin sentuh terkini dan kiosk layan diri, dan dilengkapi dengan semua jenis alat pelaporan, ia juga menjadi popular dengan cepat. Selalunya kemas kini berjalan tanpa masalah. Kakitangan IT tempatan memasang peralatan baharu, memindahkan data dan perniagaan diteruskan. Kecuali apabila ia tidak bertahan. Apabila ini berlaku, syarikat itu akan menghantar James, yang digelar "The Cleaner."
Walaupun nama panggilan itu mencadangkan jenis jahat, pembersih itu hanyalah gabungan pengajar, pemasang dan jack-of-all-trades. James akan menghabiskan beberapa hari di tapak pelanggan untuk meletakkan semua komponen bersama-sama, dan kemudian menghabiskan beberapa hari lagi untuk mengajar kakitangan cara menggunakan sistem baharu, menyelesaikan sebarang masalah perkakasan yang timbul dan pada dasarnya membantu perisian itu sejak permulaannya.
Oleh itu, tidak menghairankan bahawa pada waktu sibuk ini, James tiba di pejabat pada waktu pagi, dan sebelum dia sampai ke mejanya, dia disambut oleh pengurus, dipenuhi dengan kafein melebihi kebiasaan.
βSaya takut anda perlu pergi ke Annapolis, Nova Scotia, secepat mungkin.β Keseluruhan sistem mereka rosak, dan selepas semalam bekerja dengan jurutera mereka, kami tidak dapat mengetahui apa yang berlaku. Nampaknya rangkaian telah gagal pada pelayan. Tetapi hanya selepas sistem telah berjalan selama beberapa minit.
β Mereka tidak kembali kepada sistem lama? - James menjawab dengan serius, walaupun secara mental dia membesarkan matanya kerana terkejut.
β Tepat sekali: pakar IT mereka "menukar keutamaan" dan memutuskan untuk pergi dengan pelayan lama mereka. James, mereka memasang sistem di enam tapak dan hanya membayar untuk sokongan premium, dan perniagaan mereka kini dijalankan seperti pada tahun 1950-an.
James menegakkan badan sedikit.
- Itu perkara lain. Baiklah, mari kita mulakan.
Apabila dia tiba di Annapolis, perkara pertama yang dia lakukan ialah mencari teater pertama pelanggan yang mempunyai masalah. Pada peta yang diambil di lapangan terbang, semuanya kelihatan baik, tetapi kawasan sekitar alamat yang dikehendaki kelihatan mencurigakan. Bukan ghetto, tetapi mengingatkan filem noir. Ketika James meletak kereta di tepi jalan di pusat bandar, seorang pelacur menghampirinya. Memandangkan saiz Annapolis, kemungkinan besar ia adalah satu-satunya di seluruh bandar. Penampilannya segera mengingatkan watak terkenal yang menawarkan seks untuk wang di skrin besar. Tidak, bukan tentang Julia Roberts, tetapi tentang Jon Voight [kiasan kepada filem "Midnight Cowboy" - lebih kurang. lorong].
Setelah menghantar pelacur itu dalam perjalanan, James pergi ke pawagam. Kawasan sekitar telah menjadi lebih baik, tetapi ia masih memberi kesan seperti lari ke bawah. Bukannya James terlalu risau. Dia pernah pergi ke tempat yang celaka sebelum ini. Dan ini adalah Kanada, di mana perompak pun cukup sopan untuk mengatakan "terima kasih" selepas mengambil dompet anda.
Pintu masuk ke pawagam adalah di lorong yang lembap. James berjalan ke pintu dan mengetuk. Tidak lama kemudian ia berderit dan terbuka sedikit.
-Adakah anda seorang pembersih? - kedengaran suara garau dari dalam.
- Ya, ini saya... Saya datang untuk membetulkan segala-galanya.
James berjalan ke lobi panggung wayang. Nampaknya tiada pilihan lain, kakitangan mula mengedarkan tiket kertas kepada pengunjung. Ini menyukarkan pelaporan kewangan, apatah lagi butiran yang lebih menarik. Tetapi kakitangan menyambut James dengan lega dan segera membawanya ke bilik pelayan.
Pada pandangan pertama, semuanya baik-baik saja. James melog masuk ke pelayan dan memeriksa tempat-tempat yang biasa mencurigakan. Tiada masalah. Walau bagaimanapun, kerana banyak berhati-hati, James menutup pelayan, menggantikan kad rangkaian, dan melancarkan sistem. Dia segera mula bekerja sepenuhnya. Kakitangan mula menjual tiket semula.
James menelefon Mark dan memaklumkan keadaannya. Tidak sukar untuk membayangkan bahawa James mungkin mahu bertahan dan melihat jika sesuatu yang tidak dijangka berlaku. Dia menuruni tangga dan mula bertanya kepada pekerja apa yang berlaku. Jelas sekali sistem telah berhenti berfungsi. Mereka mematikannya dan hidupkan, semuanya berfungsi. Tetapi selepas 10 minit sistem itu jatuh.
Hanya pada masa ini sesuatu yang serupa berlaku. Tiba-tiba, sistem tiket mula membuang ralat. Kakitangan mengeluh dan mengambil tiket kertas, dan James bergegas ke bilik pelayan. Semuanya kelihatan baik dengan pelayan.
Kemudian salah seorang pekerja masuk.
β Sistem berfungsi semula.
James hairan kerana dia tidak melakukan apa-apa. Lebih tepat lagi, tiada apa yang akan membuat sistem berfungsi. Dia log keluar, mengambil telefonnya, dan menghubungi talian sokongan syarikatnya. Tidak lama kemudian pekerja yang sama memasuki bilik pelayan.
- Sistem tidak berfungsi.
James memandang ke arah pelayan. Corak bentuk pelbagai warna yang menarik dan biasa menari pada skrin - paip menggeliat kelam kabut dan berjalin. Kita semua telah melihat penyelamat skrin ini pada satu ketika. Ia dibuat dengan cantik dan betul-betul menghipnotis.
James menekan butang dan corak itu hilang. Dia bergegas ke pejabat tiket dan dalam perjalanan bertemu dengan seorang pekerja yang kembali kepadanya.
β Sistem berfungsi semula.
Jika anda boleh melakukan facepalm mental, itulah yang James lakukan. Gambar skrin. Ia menggunakan OpenGL. Dan oleh itu, semasa operasi, ia menggunakan semua sumber pemproses pelayan. Akibatnya, setiap panggilan ke pelayan berakhir dengan tamat masa.
James kembali ke bilik pelayan, log masuk, dan menggantikan penyelamat skrin dengan paip yang cantik dengan skrin kosong. Iaitu, bukannya penyelamat skrin yang menggunakan 100% sumber pemproses, saya memasang satu lagi yang tidak menggunakan sumber. Kemudian saya menunggu 10 minit untuk menyemak tekaan saya.
Apabila James tiba di pawagam seterusnya, dia tertanya-tanya bagaimana untuk menjelaskan kepada pengurusnya bahawa dia baru sahaja terbang sejauh 800 km untuk mematikan penyelamat skrin.
Terhempas semasa fasa bulan tertentu
Kisah benar. Suatu hari timbul bug perisian yang bergantung pada fasa bulan. Terdapat sedikit rutin yang biasa digunakan dalam pelbagai program MIT untuk mengira anggaran kepada fasa sebenar Bulan. GLS membina rutin ini ke dalam program LISP yang, apabila menulis fail, akan mengeluarkan baris dengan cap masa hampir 80 aksara panjang. Jarang sekali baris pertama mesej akan menjadi terlalu panjang dan membawa kepada baris seterusnya. Dan apabila program kemudian membaca fail ini, ia mengutuk. Panjang baris pertama bergantung pada tarikh dan masa yang tepat, serta panjang spesifikasi fasa pada masa cap masa dicetak. Iaitu, pepijat benar-benar bergantung pada fasa bulan!
Edisi kertas pertama (Steele-1983) mengandungi contoh baris sedemikian yang membawa kepada pepijat yang diterangkan, tetapi penaip "membetulkannya". Ini telah digambarkan sebagai "pepijat fasa bulan".
Walau bagaimanapun, berhati-hati dengan andaian. Beberapa tahun yang lalu, jurutera dari CERN (Pusat Penyelidikan Nuklear Eropah) menemui ralat dalam eksperimen yang dijalankan di Large Electron-Positron Collider. Memandangkan komputer secara aktif memproses sejumlah besar data yang dijana oleh peranti ini sebelum menunjukkan hasilnya kepada saintis, ramai yang membuat spekulasi bahawa perisian itu entah bagaimana sensitif kepada fasa bulan. Beberapa jurutera yang terdesak sampai ke dasar kebenaran. Kesilapan itu timbul kerana sedikit perubahan dalam geometri cincin sepanjang 27 km akibat ubah bentuk Bumi semasa laluan Bulan! Kisah ini telah memasuki cerita rakyat fizik sebagai "Balas Dendam Newton terhadap Fizik Zarah" dan contoh hubungan antara undang-undang fizik yang paling mudah dan tertua dan konsep saintifik yang paling maju.
Membilas tandas menghentikan kereta api
Pepijat perkakasan terbaik yang pernah saya dengar ialah pada kereta api berkelajuan tinggi di Perancis. Pepijat itu membawa kepada brek kecemasan kereta api, tetapi hanya jika terdapat penumpang di dalamnya. Dalam setiap kes sedemikian, kereta api telah dibawa keluar dari perkhidmatan, diperiksa, tetapi tiada apa yang ditemui. Kemudian dia dihantar semula ke barisan, dan dia serta-merta terhenti.
Semasa salah satu pemeriksaan, seorang jurutera yang menaiki kereta api pergi ke tandas. Dia segera hanyut, BOOM! Hentian kecemasan.
Jurutera itu menghubungi pemandu dan bertanya:
β Apa yang anda lakukan sebelum membrek?
- Baiklah, saya memperlahankan penurunan...
Ini adalah pelik, kerana semasa operasi biasa kereta api perlahan menuruni berpuluh-puluh kali. Kereta api bergerak, dan pada penurunan seterusnya pemandu memberi amaran:
- Saya akan perlahan.
Tiada apa yang berlaku.
β Apakah yang anda lakukan semasa brek terakhir? - tanya pemandu itu.
- Nah... Saya berada di dalam tandas...
- Nah, kemudian pergi ke tandas dan lakukan apa yang anda lakukan apabila kita turun semula!
Jurutera itu pergi ke tandas, dan apabila pemandu memberi amaran: "Saya perlahan," dia menyiram air. Sudah tentu, kereta api berhenti serta-merta.
Kini mereka boleh mengeluarkan semula masalah itu dan perlu mencari puncanya.
Selepas dua minit, mereka menyedari bahawa kabel kawalan jauh brek enjin (kereta api mempunyai satu enjin pada setiap hujung) telah diputuskan dari dinding kabinet elektrik dan terletak di atas geganti yang mengawal solenoid palam tandas... Apabila geganti telah dihidupkan, ia mewujudkan gangguan dalam kabel brek, dan perlindungan sistem terhadap kegagalan hanya termasuk brek kecemasan.
Pintu masuk yang membenci FORTRAN
Beberapa bulan yang lalu kami mendapati bahawa sambungan rangkaian di tanah besar [ini di Hawaii] menjadi sangat, sangat perlahan. Ini boleh berlangsung selama 10-15 minit dan kemudian tiba-tiba berlaku lagi. Selepas beberapa lama, rakan sekerja saya mengadu kepada saya bahawa sambungan rangkaian di tanah besar secara umum tidak berfungsi. Dia mempunyai beberapa kod FORTRAN yang perlu disalin ke mesin di tanah besar, tetapi ia tidak boleh kerana "rangkaian tidak bertahan cukup lama untuk muat naik FTP selesai."
Ya, ternyata kegagalan rangkaian berlaku apabila rakan sekerja cuba FTP fail dengan kod sumber dalam FORTRAN ke mesin di tanah besar. Kami cuba mengarkibkan fail: kemudian ia disalin dengan lancar (tetapi mesin sasaran tidak mempunyai pembongkar, jadi masalahnya tidak diselesaikan). Akhirnya kami "memecahkan" kod FORTRAN kepada kepingan yang sangat kecil dan menghantarnya satu demi satu. Kebanyakan serpihan telah disalin tanpa masalah, tetapi beberapa keping tidak lulus, atau lulus selepas itu banyak percubaan.
Apabila kami meneliti petikan yang bermasalah, kami mendapati bahawa mereka mempunyai persamaan: kesemuanya mengandungi blok ulasan yang bermula dan berakhir dengan baris yang terdiri daripada modal C (sebagai rakan sekerja lebih suka mengulas dalam FORTRAN). Kami menghantar e-mel kepada pakar rangkaian di tanah besar dan meminta bantuan. Sudah tentu, mereka mahu melihat sampel fail kami yang tidak boleh dipindahkan melalui FTP... tetapi surat kami tidak sampai kepada mereka. Akhirnya kami mendapat yang mudah memerihalkanrupa fail yang tidak boleh dipindah milik. Ia berkesan :) [Beranikah saya menambah contoh salah satu komen FORTRAN yang bermasalah di sini? Mungkin tidak berbaloi!]
Akhirnya kami berjaya memikirkannya. Gerbang baharu telah dipasang baru-baru ini antara bahagian kampus kami dan rangkaian tanah besar. Ia mengalami kesukaran yang BESAR untuk menghantar paket yang mengandungi bit berulang huruf besar C! Hanya beberapa paket ini boleh menggunakan semua sumber get laluan dan menghalang kebanyakan paket lain daripada masuk. Kami mengadu kepada pengilang pintu masuk... dan mereka menjawab: βOh, ya, anda berhadapan dengan pepijat C berulang! Kami sudah tahu tentang dia.β Kami akhirnya menyelesaikan masalah dengan membeli pintu masuk baharu daripada pengeluar lain (dalam pembelaan yang terdahulu, ketidakupayaan untuk memindahkan program FORTRAN mungkin merupakan kelebihan bagi sesetengah orang!).
Masa sukar
Beberapa tahun yang lalu, semasa berusaha mencipta sistem ETL di Perl untuk mengurangkan kos ujian klinikal fasa 40, saya perlu memproses kira-kira 000 tarikh. Dua daripadanya tidak lulus ujian. Ini tidak terlalu mengganggu saya kerana tarikh-tarikh ini diambil daripada data yang disediakan oleh pelanggan yang selalunya, boleh kita katakan, mengejutkan. Tetapi apabila saya menyemak data asal, ternyata tarikh ini adalah 1 Januari 2011 dan 1 Januari 2007. Saya fikir pepijat itu terkandung dalam program yang saya tulis tadi, tetapi ternyata ia sudah 30 tahun. tua. Ini mungkin terdengar misteri bagi mereka yang tidak biasa dengan ekosistem perisian. Kerana keputusan lama syarikat lain untuk menjana wang, pelanggan saya membayar saya untuk membetulkan pepijat yang telah diperkenalkan oleh satu syarikat secara tidak sengaja dan yang lain dengan sengaja. Untuk anda memahami perkara yang saya maksudkan, saya perlu bercakap tentang syarikat yang menambah ciri yang akhirnya menjadi pepijat, serta beberapa acara menarik lain yang menyumbang kepada pepijat misteri yang saya tetapkan.
Pada zaman dahulu, komputer Apple kadangkala secara spontan menetapkan semula tarikhnya kepada 1 Januari 1904. Alasannya mudah: ia menggunakan "jam sistem" berkuasa bateri untuk menjejaki tarikh dan masa. Apa yang berlaku apabila bateri mati? Komputer mula menjejak tarikh mengikut bilangan saat sejak permulaan zaman. Mengikut zaman yang kami maksudkan adalah tarikh asal rujukan, dan untuk Macintosh ialah 1 Januari 1904. Dan selepas bateri mati, tarikh semasa ditetapkan semula kepada yang ditentukan. Tetapi mengapa ini berlaku?
Sebelum ini, Apple menggunakan 32 bit untuk menyimpan bilangan saat sejak tarikh asal. Satu bit boleh menyimpan satu daripada dua nilai - 1 atau 0. Dua bit boleh menyimpan satu daripada empat nilai: 00, 01, 10, 11. Tiga bit - satu nilai daripada lapan: 000, 001, 010, 011, 100 , 101, 110, 111, dsb. Dan 32 boleh menyimpan satu daripada 232 nilai, iaitu, 4 saat. Untuk tarikh Apple, ini bersamaan dengan kira-kira 294 tahun, jadi Mac yang lebih lama tidak boleh mengendalikan tarikh selepas 967. Dan jika bateri sistem mati, tarikh ditetapkan semula kepada 296 saat sejak permulaan zaman, dan anda perlu menetapkan tarikh secara manual setiap kali anda menghidupkan komputer (atau sehingga anda membeli bateri baharu).
Walau bagaimanapun, keputusan Apple untuk menyimpan tarikh sebagai saat sejak zaman itu bermakna kami tidak dapat mengendalikan tarikh sebelum zaman itu, yang mempunyai akibat yang meluas, seperti yang akan kita lihat. Apple memperkenalkan ciri, bukan pepijat. Antara lain, ini bermakna sistem pengendalian Macintosh kebal terhadap "pepijat milenium" (yang tidak boleh dikatakan tentang banyak aplikasi Mac yang mempunyai sistem tarikh mereka sendiri untuk memintas sekatan).
Teruskan. Kami menggunakan Lotus 1-2-3, "aplikasi pembunuh" IBM yang membantu melancarkan revolusi PC, walaupun komputer Apple mempunyai VisiCalc, yang menjadikan komputer peribadi itu berjaya. Sejujurnya, jika 1-2-3 tidak muncul, PC tidak akan dilepaskan, dan sejarah komputer peribadi boleh berkembang dengan sangat berbeza. Lotus 1-2-3 salah menganggap 1900 sebagai tahun lompat. Apabila Microsoft mengeluarkan hamparan pertamanya, Multiplan, ia menguasai sebahagian kecil pasaran. Dan apabila mereka melancarkan projek Excel, mereka memutuskan bukan sahaja untuk menyalin skema penamaan baris dan lajur daripada Lotus 1-2-3, tetapi juga untuk memastikan keserasian pepijat dengan sengaja menganggap 1900 sebagai tahun lompat. Masalah ini masih wujud sehingga kini. Iaitu, dalam 1-2-3 ini adalah pepijat, tetapi dalam Excel ia adalah keputusan sedar yang memastikan semua pengguna 1-2-3 boleh mengimport jadual mereka ke dalam Excel tanpa mengubah data, walaupun ia tidak betul.
Tetapi ada masalah lain. Pertama, Microsoft mengeluarkan Excel untuk Macintosh, yang tidak mengenali tarikh sebelum 1 Januari 1904. Dan dalam Excel, 1 Januari 1900 dianggap sebagai permulaan era. Oleh itu, pembangun membuat perubahan supaya program mereka mengenali jenis era dan menyimpan data dalam dirinya mengikut era yang dikehendaki. Microsoft juga menulis artikel penjelasan tentang perkara ini. Dan keputusan ini membawa kepada pepijat saya.
Sistem ETL saya menerima hamparan Excel daripada pelanggan yang dibuat pada Windows, tetapi juga boleh dibuat pada Mac. Oleh itu, permulaan era dalam jadual boleh sama ada 1 Januari 1900, atau 1 Januari 1904. Bagaimana untuk mengetahui? Format fail Excel menunjukkan maklumat yang diperlukan, tetapi penghurai yang saya gunakan tidak menunjukkannya (kini ia menunjukkannya), dan menganggap bahawa anda mengetahui zaman untuk jadual tertentu. Saya mungkin boleh menghabiskan lebih banyak masa untuk memahami format binari Excel dan menghantar tampalan kepada pengarang penghurai, tetapi saya mempunyai banyak lagi yang perlu dilakukan untuk pelanggan, jadi saya dengan cepat menulis heuristik untuk menentukan zaman. Dia sederhana.
Dalam Excel, tarikh 5 Julai 1998 boleh diwakili dalam format "07-05-98" (sistem Amerika yang tidak berguna), "5 Jul 98", "5 Julai 1998", "5-Jul-98" atau beberapa format lain. format lain yang tidak berguna (ironinya, salah satu format versi Excel saya tidak tawarkan ialah ISO 8601). Walau bagaimanapun, dalam jadual, tarikh yang tidak diformat telah disimpan sebagai sama ada "35981" untuk zaman-1900 atau "34519" untuk zaman-1904 (nombor mewakili bilangan hari sejak zaman itu). Saya hanya menggunakan penghurai mudah untuk mengekstrak tahun daripada tarikh yang diformat, dan kemudian menggunakan penghurai Excel untuk mengekstrak tahun daripada tarikh yang tidak diformat. Jika kedua-dua nilai berbeza selama 4 tahun, maka saya tahu bahawa saya menggunakan sistem dengan epoch-1904.
Mengapa saya tidak menggunakan tarikh yang diformatkan sahaja? Kerana 5 Julai 1998 boleh diformatkan sebagai "July, 98" dengan hari bulan hilang. Kami menerima jadual daripada begitu banyak syarikat yang menciptanya dalam pelbagai cara yang berbeza sehingga terpulang kepada kami (dalam kes ini, saya) untuk mengetahui tarikhnya. Selain itu, jika Excel melakukannya dengan betul, maka kita juga harus!
Pada masa yang sama saya menemui 39082. Biar saya ingatkan anda bahawa Lotus 1-2-3 menganggap 1900 sebagai tahun lompat, dan ini telah diulangi dengan setia dalam Excel. Dan kerana ini menambah satu hari kepada tahun 1900, banyak fungsi pengiraan tarikh mungkin salah untuk hari itu. Iaitu, 39082 mungkin pada 1 Januari 2011 (pada Mac) atau 31 Disember 2006 (pada Windows). Jika "penghurai tahun" saya mengekstrak tahun 2011 daripada nilai yang diformatkan, maka semuanya baik-baik saja. Tetapi oleh kerana penghurai Excel tidak tahu zaman apa yang sedang digunakan, ia lalai kepada epoch-1900, mengembalikan tahun 2006. Permohonan saya melihat bahawa perbezaannya adalah 5 tahun, menganggapnya sebagai ralat, mencatatnya, dan mengembalikan nilai yang tidak diformat.
Untuk mengatasi ini, saya menulis ini (pseudokod):
diff = formatted_year - parsed_year
if 0 == diff
assume 1900 date system
if 4 == diff
assume 1904 date system
if 5 == diff and month is December and day is 31
assume 1904 date system
Dan kemudian kesemua 40 tarikh telah dihuraikan dengan betul.
Di tengah-tengah kerja cetakan besar
Pada awal 1980-an, ayah saya bekerja di Storage Technology, sebuah bahagian yang kini tidak berfungsi yang mencipta pemacu pita dan sistem pneumatik untuk penyusuan pita berkelajuan tinggi.
Mereka mereka bentuk semula pemacu supaya mereka boleh mempunyai satu pemacu "A" pusat yang disambungkan kepada tujuh pemacu "B", dan OS kecil dalam RAM yang mengawal pemacu "A" boleh mewakilkan operasi baca dan tulis kepada semua pemacu "B".
Setiap kali pemacu "A" dimulakan, adalah perlu untuk memasukkan cakera liut ke dalam pemacu persisian yang disambungkan ke "A" untuk memuatkan sistem pengendalian ke dalam memorinya. Ia sangat primitif: kuasa pengkomputeran disediakan oleh mikropengawal 8-bit.
Khalayak sasaran untuk peralatan tersebut ialah syarikat yang mempunyai gudang data yang sangat besar - bank, rangkaian runcit, dll. - yang perlu mencetak banyak label alamat atau penyata bank.
Seorang pelanggan mengalami masalah. Di tengah-tengah kerja cetakan, satu pemacu tertentu "A" boleh berhenti berfungsi, menyebabkan keseluruhan kerja terhenti. Untuk memulihkan operasi pemacu, kakitangan terpaksa but semula semuanya. Dan jika ini berlaku di tengah-tengah tugasan selama enam jam, maka sejumlah besar masa komputer yang mahal telah hilang dan jadual keseluruhan operasi terganggu.
Juruteknik dihantar dari Storage Technologies. Tetapi di sebalik usaha terbaik mereka, mereka tidak dapat menghasilkan semula pepijat di bawah keadaan ujian: ia seolah-olah berlaku di tengah-tengah kerja cetakan besar. Masalahnya bukan perkakasan, mereka menggantikan semua yang mereka boleh: RAM, mikropengawal, pemacu liut, setiap bahagian pemacu pita yang boleh difikirkan - masalah itu berterusan.
Kemudian juruteknik memanggil ibu pejabat dan memanggil Pakar.
Pakar itu meraih kerusi dan secawan kopi, duduk di dalam bilik komputerβpada masa itu terdapat bilik yang dikhaskan untuk komputerβdan memerhatikan ketika kakitangan beratur dalam kerja cetakan yang besar. Pakar sedang menunggu kegagalan berlaku - dan ia berlaku. Semua orang memandang ke arah Pakar, tetapi dia tidak tahu mengapa ini berlaku. Jadi dia mengarahkan kerja itu beratur semula, dan semua kakitangan dan juruteknik kembali bekerja.
Pakar itu kembali duduk di kerusi dan mula menunggu kegagalan. Kira-kira enam jam berlalu dan kegagalan itu berlaku. Pakar itu sekali lagi tidak mempunyai idea, kecuali semuanya berlaku di dalam bilik yang dipenuhi orang. Dia mengarahkan misi itu dimulakan semula, duduk semula dan menunggu.
Dengan kegagalan ketiga, Pakar menyedari sesuatu. Kegagalan berlaku apabila kakitangan menukar pita dalam pemacu asing. Lebih-lebih lagi, kegagalan itu berlaku sebaik salah seorang pekerja berjalan melalui jubin tertentu di atas lantai.
Lantai yang dibangkitkan itu diperbuat daripada jubin aluminium yang diletakkan pada ketinggian 6 hingga 8 inci. Banyak wayar dari komputer berlari di bawah lantai yang dinaikkan untuk menghalang sesiapa daripada terpijak kabel penting secara tidak sengaja. Jubin itu diletakkan sangat ketat untuk mengelakkan serpihan daripada masuk ke bawah lantai yang dinaikkan.
Pakar menyedari bahawa salah satu jubin telah cacat. Apabila seorang pekerja memijak sudutnya, tepi jubin itu bergesel dengan jubin bersebelahan. Bahagian plastik yang menyambungkan jubin juga bergesel dengannya, yang menyebabkan nyahcas mikro statik yang mencipta gangguan frekuensi radio.
Hari ini, RAM jauh lebih dilindungi daripada gangguan frekuensi radio. Tetapi pada tahun-tahun itu ini tidak berlaku. Pakar menyedari bahawa gangguan ini mengganggu memori, dan dengan itu operasi sistem pengendalian. Dia memanggil perkhidmatan sokongan, memesan jubin baharu, memasangnya sendiri, dan masalah itu hilang.
Air pasang!
Kisah itu berlaku di bilik pelayan, di tingkat empat atau lima pejabat di Portsmouth (saya rasa), di kawasan dok.
Suatu hari pelayan Unix dengan pangkalan data utama ranap. Mereka reboot dia, tetapi dia dengan senang hati terus jatuh berulang kali. Kami memutuskan untuk menghubungi seseorang daripada perkhidmatan sokongan.
Lelaki sokongan... Saya rasa namanya Mark, tetapi itu tidak penting... Saya rasa saya tidak mengenalinya. Tak kisah sangat. Mari kekal dengan Mark, okay? Hebat.
Jadi, beberapa jam kemudian Mark tiba (ia tidak jauh dari Leeds ke Portsmouth, anda tahu), menghidupkan pelayan dan semuanya berfungsi tanpa masalah. Sokongan biasa, pelanggan menjadi sangat kecewa tentang perkara ini. Mark melihat melalui fail log dan tidak menemui apa-apa yang tidak diingini. Jadi Mark naik semula ke kereta api (atau apa-apa jenis pengangkutan yang dia tiba, ia mungkin lembu pincang untuk semua yang saya tahu ... bagaimanapun, tidak mengapa, okay?) dan kembali ke Leeds, setelah membazir. hari itu.
Pada petang yang sama pelayan rosak lagi. Ceritanya sama... server tak naik. Mark cuba membantu dari jauh, tetapi pelanggan tidak dapat memulakan pelayan.
Satu lagi kereta api, bas, lemon meringue atau beberapa omong kosong lain, dan Mark kembali ke Portsmouth. Lihat, pelayan but tanpa sebarang masalah! Keajaiban. Mark menghabiskan beberapa jam untuk menyemak sama ada semuanya teratur dengan sistem pengendalian atau perisian dan berangkat ke Leeds.
Sekitar tengah hari pelayan ranap (bertenang!). Kali ini nampaknya munasabah untuk membawa masuk orang sokongan perkakasan untuk menggantikan pelayan. Tetapi tidak, selepas kira-kira 10 jam ia juga jatuh.
Keadaan itu berulang selama beberapa hari. Pelayan berfungsi, ranap selepas kira-kira 10 jam dan tidak bermula untuk 2 jam seterusnya. Mereka memeriksa penyejukan, kebocoran memori, mereka memeriksa segala-galanya, tetapi tidak menemui apa-apa. Kemudian kemalangan berhenti.
Minggu berlalu dengan riang... semua orang gembira. Bahagia sehingga semuanya bermula semula. Gambar pun sama. 10 jam kerja, 2-3 jam waktu rehat...
Dan kemudian seseorang (saya rasa mereka memberitahu saya bahawa orang ini tiada kaitan dengan IT) berkata:
"Ia air pasang!"
Seruan itu disambut dengan pandangan kosong, dan tangan seseorang mungkin teragak-agak pada butang panggilan keselamatan.
"Ia berhenti bekerja dengan air pasang."
Ini nampaknya konsep yang sama sekali asing kepada pekerja sokongan IT, yang tidak mungkin membaca Buku Tahunan Tide sambil duduk untuk minum kopi. Mereka menjelaskan bahawa ini tidak boleh dikaitkan dengan air pasang dalam apa-apa cara, kerana pelayan telah bekerja selama seminggu tanpa kegagalan.
"Minggu lepas air pasang surut, tetapi minggu ini tinggi."
Sedikit istilah untuk mereka yang tidak mempunyai lesen kapal layar. Pasang surut bergantung pada kitaran bulan. Dan semasa Bumi berputar, setiap 12,5 jam tarikan graviti Matahari dan Bulan mencipta gelombang pasang surut. Pada permulaan kitaran 12,5 jam air pasang, di tengah kitaran ada pasang surut, dan di penghujungnya air pasang lagi. Tetapi apabila orbit bulan berubah, begitu juga perbezaan antara air surut dan pasang surut. Apabila Bulan berada di antara Matahari dan Bumi atau di seberang Bumi (bulan penuh atau tiada bulan), kita mendapat pasang surut Syzygyn - pasang surut tertinggi dan surut terendah. Pada separuh bulan kita mendapat pasang surut kuadratur - pasang surut terendah. Perbezaan antara kedua-dua ekstrem berkurangan dengan ketara. Kitaran lunar berlangsung selama 28 hari: syzygian - quadrature - syzygian - quadrature.
Apabila juruteknik diterangkan tentang intipati kuasa pasang surut, mereka segera berfikir bahawa mereka perlu menghubungi polis. Dan agak logik. Tetapi ternyata lelaki itu betul. Dua minggu sebelum itu, sebuah kapal pemusnah berlabuh tidak jauh dari pejabat. Setiap kali air pasang menaikkannya ke ketinggian tertentu, tiang radar kapal berakhir di paras lantai bilik pelayan. Dan radar (atau peralatan peperangan elektronik, atau beberapa mainan ketenteraan lain) mencipta huru-hara dalam komputer.
Misi penerbangan untuk roket
Saya ditugaskan untuk mengalihkan sistem kawalan dan pemantauan pelancaran roket yang besar (kira-kira 400 ribu talian) kepada versi baharu sistem pengendalian, pengkompil dan bahasa. Lebih tepat lagi, daripada Solaris 2.5.1 hingga Solaris 7, dan daripada Verdix Ada Development System (VADS), yang ditulis dalam Ada 83, kepada sistem Rational Apex Ada, yang ditulis dalam Ada 95. VADS telah dibeli oleh Rational, dan produknya ialah usang, walaupun Rational cuba melaksanakan versi pakej khusus VADS yang serasi untuk memudahkan peralihan kepada pengkompil Apex.
Tiga orang membantu saya mendapatkan kod yang disusun dengan bersih. Ia mengambil masa dua minggu. Dan kemudian saya bekerja sendiri untuk membuat sistem berfungsi. Ringkasnya, ia adalah seni bina dan pelaksanaan sistem perisian yang paling teruk yang pernah saya temui, jadi ia mengambil masa dua bulan lagi untuk menyiapkan pelabuhan. Sistem itu kemudiannya diserahkan untuk ujian, yang mengambil masa beberapa bulan lagi. Saya segera membetulkan pepijat yang ditemui semasa ujian, tetapi bilangannya dengan cepat berkurangan (kod sumber adalah sistem pengeluaran, jadi fungsinya berfungsi dengan baik, saya hanya perlu mengalih keluar pepijat yang timbul semasa penyesuaian kepada pengkompil baru). Akhirnya, apabila semuanya berfungsi sebagaimana mestinya, saya telah dipindahkan ke projek lain.
Dan pada hari Jumaat sebelum Thanksgiving, telefon berdering.
Pelancaran roket itu sepatutnya diuji dalam masa kira-kira tiga minggu, dan semasa ujian makmal kira detik, urutan arahan telah disekat. Dalam kehidupan sebenar, ini akan membatalkan ujian, dan jika sekatan berlaku dalam beberapa saat selepas menghidupkan enjin, beberapa tindakan tidak dapat dipulihkan akan berlaku dalam sistem tambahan, yang memerlukan kesediaan roket yang panjang - dan mahal. Ia tidak akan bermula, tetapi ramai orang akan berasa sangat kecewa tentang kehilangan masa dan banyak, banyak wang. Jangan biarkan sesiapa memberitahu anda bahawa Jabatan Pertahanan membelanjakan wang secara meluluβsaya tidak pernah bertemu pengurus kontrak yang tidak meletakkan belanjawan di hadapan atau kedua, diikuti dengan jadual.
Pada bulan-bulan sebelumnya, cabaran kira detik ini telah dijalankan ratusan kali dalam pelbagai variasi, dengan hanya beberapa gangguan kecil. Jadi kemungkinan ini berlaku adalah sangat rendah, tetapi akibatnya sangat ketara. Gandakan kedua-dua faktor ini, dan anda akan faham bahawa berita itu meramalkan minggu percutian yang musnah untuk saya dan berpuluh-puluh jurutera dan pengurus.
Dan perhatian diberikan kepada saya sebagai orang yang mengalihkan sistem.
Seperti kebanyakan sistem kritikal keselamatan, banyak parameter telah dilog, jadi agak mudah untuk mengenal pasti beberapa baris kod yang telah dilaksanakan sebelum sistem ranap. Dan sudah tentu, tidak ada yang luar biasa tentang mereka; ungkapan yang sama telah berjaya dilaksanakan secara literal beribu-ribu kali semasa larian yang sama.
Kami memanggil orang dari Apex ke dalam Rasional kerana mereka adalah orang yang membangunkan pengkompil dan beberapa rutin yang mereka bangunkan dipanggil dalam kod yang mencurigakan. Mereka (dan semua orang lain) kagum bahawa terdapat keperluan untuk mendapatkan punca masalah yang mempunyai kepentingan nasional secara literal.
Memandangkan tiada apa-apa yang menarik dalam jurnal, kami memutuskan untuk cuba menghasilkan semula masalah di makmal tempatan. Ini bukanlah tugas yang mudah kerana acara itu berlaku kira-kira sekali setiap 1000 larian. Satu sebab yang disyaki ialah panggilan ke fungsi mutex yang dibangunkan vendor (sebahagian daripada pakej migrasi VADS) Unlock tidak membawa kepada membuka kunci. Urutan pemprosesan yang memanggil fungsi memproses mesej degupan jantung, yang secara nominal tiba setiap saat. Kami menaikkan frekuensi kepada 10 Hz, iaitu, 10 kali sesaat, dan mula berjalan. Kira-kira sejam kemudian sistem terkunci sendiri. Dalam log, kami melihat bahawa urutan mesej yang dirakam adalah sama seperti semasa ujian gagal. Kami membuat beberapa larian lagi, sistem telah disekat secara konsisten 45-90 minit selepas permulaan, dan setiap kali log mengandungi laluan yang sama. Walaupun kami secara teknikal menjalankan kod yang berbeza - kekerapan mesej adalah berbeza - gelagat sistem adalah sama, jadi kami yakin bahawa senario beban ini menyebabkan masalah yang sama.
Sekarang kita perlu memikirkan di mana sebenarnya penyekatan berlaku dalam urutan ungkapan.
Pelaksanaan sistem ini menggunakan sistem tugas Ada, dan menggunakannya dengan sangat teruk. Tugasan ialah binaan boleh laksana serentak peringkat tinggi dalam Ada, sesuatu seperti urutan pelaksanaan, hanya terbina dalam bahasa itu sendiri. Apabila dua tugasan perlu berkomunikasi, mereka "menetapkan pertemuan", bertukar-tukar data yang diperlukan, dan kemudian menghentikan pertemuan itu dan kembali ke pelaksanaan bebas mereka. Bagaimanapun, sistem itu dilaksanakan secara berbeza. Selepas tugas sasaran bertemu, tugas sasaran itu bertemu dengan tugas lain, yang kemudiannya bertemu dengan tugas ketiga, dan seterusnya sehingga beberapa pemprosesan selesai. Selepas ini, semua pertemuan ini telah selesai dan setiap tugas perlu kembali kepada pelaksanaannya. Iaitu, kami berurusan dengan sistem panggilan fungsi paling mahal di dunia, yang menghentikan keseluruhan proses "berbilang tugas" semasa ia memproses sebahagian daripada data input. Dan sebelum ini tidak membawa masalah hanya kerana daya pengeluarannya sangat rendah.
Saya menerangkan mekanisme tugas ini kerana apabila pertemuan diminta atau dijangka selesai, "suis tugas" boleh berlaku. Iaitu, pemproses boleh mula memproses tugas lain yang sedia untuk dilaksanakan. Ternyata apabila satu tugasan bersedia untuk bertemu dengan tugasan lain, tugasan yang sama sekali berbeza boleh mula dilaksanakan, dan akhirnya kawalan kembali ke pertemuan pertama. Dan peristiwa lain mungkin berlaku yang menyebabkan tugas bertukar; satu peristiwa sedemikian ialah panggilan ke fungsi sistem, seperti mencetak atau melaksanakan mutex.
Untuk memahami baris kod yang menyebabkan masalah, saya perlu mencari cara untuk merekodkan kemajuan melalui urutan pernyataan tanpa mencetuskan suis tugas, yang akan menghalang ranap daripada berlaku. Jadi saya tidak dapat mengambil kesempatan Put_Line()untuk mengelak daripada melakukan operasi I/O. Saya boleh menetapkan pembolehubah pembilang atau sesuatu yang serupa, tetapi bagaimana saya boleh melihat nilainya jika saya tidak dapat memaparkannya pada skrin?
Juga, apabila memeriksa log, ternyata, walaupun pemprosesan mesej degupan jantung tergantung, yang menyekat semua operasi I/O proses dan menghalang pemprosesan lain daripada dilakukan, tugas bebas lain terus dilaksanakan. Maksudnya, kerja itu tidak disekat sepenuhnya, hanya rantaian tugas (kritikal).
Ini adalah petunjuk yang diperlukan untuk menilai ungkapan menyekat.
Saya membuat pakej Ada yang mengandungi tugasan, jenis terhitung dan pembolehubah global jenis itu. Huruf terbilang terikat pada ungkapan khusus bagi urutan bermasalah (cth. Incrementing_Buffer_Index, Locking_Mutex, Mutex_Unlocked), dan kemudian memasukkan ungkapan tugasan ke dalamnya yang memberikan penghitungan yang sepadan kepada pembolehubah global. Memandangkan kod objek semua ini hanya menyimpan pemalar dalam ingatan, penukaran tugas akibat pelaksanaannya adalah sangat tidak mungkin. Kami terutamanya curiga terhadap ungkapan yang boleh menukar tugas, kerana penyekatan berlaku semasa pelaksanaan dan bukannya kembali apabila menukar tugas kembali (atas beberapa sebab).
Tugas penjejakan hanya berjalan dalam gelung dan menyemak secara berkala untuk melihat sama ada nilai pembolehubah global telah berubah. Dengan setiap perubahan, nilai telah disimpan ke fail. Kemudian menunggu sebentar dan cek baru. Saya menulis pembolehubah ke fail kerana tugas itu dilaksanakan hanya apabila sistem memilihnya untuk pelaksanaan apabila menukar tugas dalam kawasan masalah. Apa sahaja yang berlaku dalam tugasan ini tidak akan menjejaskan tugasan disekat lain yang tidak berkaitan.
Dijangkakan bahawa apabila sistem mencapai tahap melaksanakan kod bermasalah, pembolehubah global akan ditetapkan semula apabila beralih ke setiap ungkapan seterusnya. Kemudian sesuatu akan berlaku yang menyebabkan tugas bertukar, dan memandangkan kekerapan pelaksanaannya (10 Hz) lebih rendah daripada tugas pemantauan, monitor boleh menangkap nilai pembolehubah global dan menulisnya. Dalam keadaan biasa, saya boleh mendapatkan urutan berulang subset penghitungan: nilai terakhir pembolehubah pada masa suis tugas. Apabila digantung, pembolehubah global seharusnya tidak lagi berubah, dan nilai terakhir yang ditulis akan menunjukkan ungkapan yang tidak lengkap.
Saya menjalankan kod dengan penjejakan. Dia terkaku. Dan pemantauan berfungsi seperti jam.
Log mengandungi urutan yang dijangkakan, yang diganggu oleh nilai yang menunjukkan bahawa mutex telah dipanggil Unlock, dan tugas itu tidak selesai - seperti yang berlaku dengan beribu-ribu panggilan sebelumnya.
Jurutera Apex sedang tergesa-gesa menganalisis kod mereka pada masa ini dan menemui tempat di mutex di mana, secara teorinya, kunci boleh berlaku. Tetapi kebarangkaliannya adalah sangat rendah, kerana hanya urutan peristiwa tertentu yang berlaku pada masa tertentu boleh menyebabkan penyekatan. Undang-undang Murphy, kawan-kawan, itu Undang-undang Murphy.
Untuk melindungi sekeping kod yang saya perlukan, saya menggantikan panggilan fungsi mutex (dibina di atas kefungsian mutex OS) dengan pakej Ada mutex asli yang kecil untuk mengawal akses mutex kepada sekeping itu.
Saya memasukkannya ke dalam kod dan menjalankan ujian. Tujuh jam kemudian kod itu masih berfungsi.
Kod saya telah diserahkan kepada Rational, di mana mereka menyusunnya, membongkarnya, dan menyemak bahawa ia tidak menggunakan pendekatan yang sama yang digunakan dalam fungsi mutex yang bermasalah.
Ini adalah semakan kod paling ramai dalam kerjaya saya π Terdapat kira-kira sepuluh jurutera dan pengurus di dalam bilik bersama saya, sepuluh orang lagi sedang membuat panggilan persidangan - dan mereka semua memeriksa kira-kira 20 baris kod.
Kod telah disemak, fail boleh laku baharu telah dipasang dan diserahkan untuk ujian regresi rasmi. Beberapa minggu kemudian, ujian kira detik berjaya dan roket itu berlepas.
Okay, itu semua baik dan bagus, tetapi apa gunanya cerita itu?
Ia adalah masalah yang sangat menjijikkan. Beratus-ratus ribu baris kod, pelaksanaan selari, lebih sedozen proses berinteraksi, seni bina yang lemah dan pelaksanaan yang lemah, antara muka untuk sistem terbenam dan berjuta-juta dolar yang dibelanjakan. Tiada tekanan, kan.
Saya bukan seorang sahaja yang menangani masalah ini, walaupun saya menjadi perhatian semasa saya melakukan pemindahan. Tetapi walaupun saya melakukannya, itu tidak bermakna saya memahami semua beratus-ratus ribu baris kod, atau membacanya. Kod dan log dianalisis oleh jurutera di seluruh negara, tetapi apabila mereka memberitahu saya hipotesis mereka tentang punca kegagalan, saya hanya mengambil masa setengah minit untuk menyangkalnya. Dan apabila saya diminta untuk menganalisis teori, saya akan menyampaikannya kepada orang lain, kerana jelas kepada saya bahawa jurutera ini pergi ke arah yang salah. Bunyi sombong? Ya, ini benar, tetapi saya menolak hipotesis dan permintaan atas sebab lain.
Saya faham sifat masalahnya. Saya tidak tahu dengan tepat di mana ia berlaku atau mengapa, tetapi saya tahu apa yang berlaku.
Selama bertahun-tahun, saya telah mengumpul banyak pengetahuan dan pengalaman. Saya adalah salah seorang perintis menggunakan Ada dan memahami kelebihan dan kekurangannya. Saya tahu bagaimana perpustakaan masa jalan Ada mengendalikan tugas dan menangani pelaksanaan selari. Dan saya memahami pengaturcaraan peringkat rendah pada tahap memori, daftar dan pemasang. Dengan kata lain, saya mempunyai pengetahuan yang mendalam dalam bidang saya. Dan saya menggunakannya untuk mencari punca masalah. Saya bukan sahaja menangani pepijat, saya memahami cara mencarinya dalam persekitaran masa jalan yang sangat sensitif.
Kisah perjuangan dengan kod sedemikian tidak begitu menarik bagi mereka yang tidak biasa dengan ciri-ciri dan keadaan perjuangan sedemikian. Tetapi cerita ini membantu kami memahami perkara yang diperlukan untuk menyelesaikan masalah yang sangat sukar.
Untuk menyelesaikan masalah yang sangat sukar, anda perlu menjadi lebih daripada sekadar pengaturcara. Anda perlu memahami "nasib" kod, cara ia berinteraksi dengan persekitarannya, dan cara persekitaran itu sendiri berfungsi.
Dan kemudian anda akan mempunyai minggu percutian anda yang hancur.
Untuk diteruskan.
Sumber: www.habr.com