Ito ay isang seleksyon ng mga kuwento mula sa Internet tungkol sa kung paano ang mga bug minsan ay may ganap na hindi kapani-paniwalang mga pagpapakita. Baka may sasabihin ka rin.
Allergy sa kotse sa vanilla ice cream
Isang kuwento para sa mga inhinyero na nauunawaan na ang halata ay hindi palaging ang sagot, at na kahit gaano kalalim ang mga katotohanan ay maaaring mukhang, sila pa rin ang mga katotohanan. Nakatanggap ng reklamo ang Pontiac Division ng General Motors Corporation:
Ito ang pangalawang beses na sumusulat ako sa iyo, at hindi kita masisi kung hindi mo sinasagot, dahil parang baliw. Ang aming pamilya ay may tradisyon ng pagkain ng ice cream tuwing gabi pagkatapos ng hapunan. Ang mga uri ng ice cream sa bawat oras, at pagkatapos ng hapunan, ang buong pamilya ay pumili kung aling ice cream ang bibilhin, pagkatapos ay pumunta ako sa tindahan. Kamakailan lang ay bumili ako ng bagong Pontiac at mula noon naging problema na ang mga biyahe ko para kumuha ng ice cream. Kita mo, tuwing bibili ako ng vanilla ice cream at babalik mula sa tindahan, hindi umaandar ang sasakyan. Kung magdadala ako ng anumang iba pang ice cream, ang sasakyan ay umaandar nang walang anumang problema. Nais kong magtanong ng isang seryosong tanong, gaano man ito katanga: "Ano ang tungkol sa Pontiac na hindi nagsisimula kapag nagdala ako ng vanilla ice cream, ngunit madaling nagsisimula kapag nagdala ako ng isa pang lasa ng ice cream?" "
Gaya ng maiisip mo, may pag-aalinlangan ang pangulo ng dibisyon tungkol sa liham. Gayunpaman, kung sakali, nagpadala ako ng isang engineer upang suriin. Nagulat siya na may nakilala siyang isang mayaman at edukadong lalaki na nakatira sa isang magandang lugar. Napagkasunduan nilang magkita kaagad pagkatapos ng hapunan para pumunta silang dalawa sa tindahan para bumili ng ice cream. Nang gabing iyon ay vanilla, at nang bumalik sila sa kotse, hindi ito umaandar.
Tatlong gabi pang dumating ang engineer. Ang unang pagkakataon na ang ice cream ay tsokolate. Umandar na ang sasakyan. Sa pangalawang pagkakataon ay nagkaroon ng strawberry ice cream. Umandar na ang sasakyan. Sa ikatlong gabi hiniling niyang uminom ng banilya. Hindi umandar ang sasakyan.
Sa makatwirang pangangatwiran, tumanggi ang inhinyero na maniwala na ang kotse ay allergic sa vanilla ice cream. Kaya naman, sumang-ayon ako sa may-ari ng sasakyan na ipagpapatuloy niya ang kanyang pagbisita hanggang sa makahanap siya ng solusyon sa problema. At sa daan, nagsimula siyang kumuha ng mga tala: isinulat niya ang lahat ng impormasyon, oras ng araw, uri ng gasolina, oras ng pagdating at pagbabalik mula sa tindahan, atbp.
Hindi nagtagal ay napagtanto ng inhinyero na ang may-ari ng kotse ay gumugol ng mas kaunting oras sa pagbili ng vanilla ice cream. Ang dahilan ay ang layout ng mga paninda sa tindahan. Ang vanilla ice cream ang pinakasikat at inilagay sa hiwalay na freezer sa harap ng tindahan para mas madaling mahanap. At ang lahat ng iba pang mga varieties ay nasa likod ng tindahan, at tumagal ng mas maraming oras upang mahanap ang tamang varieties at magbayad.
Ngayon ang tanong ay para sa inhinyero: bakit hindi nagsimula ang kotse kung mas kaunting oras ang lumipas mula noong pinatay ang makina? Dahil oras ang problema, hindi vanilla ice cream, mabilis na nahanap ng engineer ang sagot: ito ay isang gas lock. Nangyayari ito tuwing gabi, ngunit nang gumugol ng mas maraming oras ang may-ari ng kotse sa paghahanap ng ice cream, sapat na lumamig ang makina at madaling umandar. At nang bumili ang lalaki ng vanilla ice cream, sobrang init pa ng makina at walang oras na matunaw ang gas lock.
Moral: Kahit na ang ganap na nakakabaliw na mga problema ay minsan totoo.
Crash bandikut
Masakit maranasan ito. Bilang isang programmer, nasanay kang sisihin ang iyong code sa una, pangalawa, pangatlo... at sa isang lugar sa ika-sampung libong lugar ay sinisisi mo ang compiler. At sa ibaba ng listahan ay sinisisi mo na ang kagamitan.
Narito ang aking kwento tungkol sa hardware bug.
Para sa larong Crash Bandicoot, nagsulat ako ng code para i-load at i-save sa isang memory card. Para sa isang mapagmataas na developer ng laro, ito ay tulad ng isang paglalakad sa parke: Akala ko ang trabaho ay tatagal ng ilang araw. Gayunpaman, natapos ko ang pag-debug ng code sa loob ng anim na linggo. Sa daan, nalutas ko ang iba pang mga problema, ngunit bawat ilang araw ay bumalik ako sa code na ito sa loob ng ilang oras. Ito ay paghihirap.
Ganito ang hitsura ng sintomas: kapag na-save mo ang kasalukuyang playthrough ng laro at na-access ang memory card, halos palaging maayos ang lahat... Ngunit kung minsan ay nag-timeout ang read o write operation nang walang malinaw na dahilan. Ang isang maikling pag-record ay kadalasang nakakasira sa memory card. Kapag sinubukan ng isang manlalaro na mag-save, hindi lamang siya nabigo sa pag-save, ngunit sinisira din ang mapa. Crap.
Pagkaraan ng ilang sandali, nagsimulang mag-panic ang producer namin sa Sony, si Connie Bus. Hindi namin maipadala ang laro gamit ang bug na ito, at pagkalipas ng anim na linggo hindi ko naintindihan kung ano ang sanhi ng problema. Sa pamamagitan ni Connie, nakipag-ugnayan kami sa iba pang mga developer ng PS1: may nakatagpo ba ng anumang katulad? Hindi. Walang nagkaproblema sa memory card.
Kapag wala kang ideya para sa pag-debug, ang tanging paraan na natitira ay ang "hatiin at lupigin": alisin ang parami nang paraming code mula sa maling programa hanggang sa may natitira pang maliit na fragment na nagdudulot pa rin ng problema. Iyon ay, pinutol mo ang programa nang paisa-isa hanggang sa mananatili ang bahaging naglalaman ng bug.
Ngunit ang bagay ay, napakahirap na putulin ang mga piraso ng isang video game. Paano ito patakbuhin kung tinanggal mo ang code na gumagaya sa gravity? O pagguhit ng mga character?
Samakatuwid, kailangan nating palitan ang buong module ng mga stub na nagpapanggap na gumagawa ng isang bagay na kapaki-pakinabang, ngunit sa katunayan ay gumawa ng isang bagay na napakasimple na hindi maaaring maglaman ng mga error. Kailangan nating magsulat ng mga saklay para gumana man lang ang laro. Ito ay isang mabagal at masakit na proseso.
In short, ginawa ko. Nag-alis ako ng parami nang parami ng mga piraso ng code hanggang sa naiwan ako sa paunang code na nagko-configure sa system para patakbuhin ang laro, sinisimulan ang pag-render ng hardware, atbp. Siyempre, sa yugtong ito hindi ako makakagawa ng save at load menu, dahil kailangan kong gumawa ng stub para sa lahat ng graphics code. Ngunit maaari akong magpanggap na isang user gamit ang (invisible) save at load screen at hilingin na i-save at pagkatapos ay sumulat sa memory card.
Nag-iwan ito sa akin ng isang maliit na piraso ng code na mayroon pa ring problema sa itaas - ngunit nangyayari pa rin ito nang random! Kadalasan ang lahat ay gumagana nang maayos, ngunit paminsan-minsan ay may mga glitches. Inalis ko ang halos lahat ng code ng laro, ngunit buhay pa rin ang bug. Ito ay nakakalito: ang natitirang code ay walang ginawa.
Sa isang punto, marahil bandang alas-tres ng umaga, may naisip ako. Ang mga operasyon sa pagbasa at pagsulat (input/output) ay nagsasangkot ng tumpak na mga oras ng pagpapatupad. Kapag nagtatrabaho ka gamit ang isang hard drive, memory card o Bluetooth module, ang mababang antas na code na responsable para sa pagbabasa at pagsusulat ay naaayon sa mga pulso ng orasan.
Sa tulong ng isang orasan, ang isang aparato na hindi direktang konektado sa processor ay naka-synchronize sa code na nagpapatupad sa processor. Tinutukoy ng orasan ang baud rateβang bilis ng paglilipat ng data. Kung may pagkalito sa mga timing, kung gayon ang hardware o ang software, o pareho, ay nalilito din. At ito ay napakasama, dahil ang data ay maaaring masira.
Paano kung ang isang bagay sa aming code ay nakalilito sa mga timing? Sinuri ko ang lahat ng nauugnay dito sa test program code at napansin na itinakda namin ang programmable timer sa PS1 sa 1 kHz (1000 ticks bawat segundo). Ito ay medyo marami; bilang default, kapag nagsimula ang console, ito ay tumatakbo sa 100 Hz. At karamihan sa mga laro ay gumagamit ng dalas na ito.
Itinakda ni Andy, ang developer ng laro, ang timer sa 1 kHz upang mas tumpak na makalkula ang mga paggalaw. Si Andy ay may posibilidad na lumampas sa dagat, at kung tutularan natin ang gravity, ginagawa natin ito nang tumpak hangga't maaari!
Ngunit paano kung ang pagpapabilis ng timer sa paanuman ay nakaapekto sa pangkalahatang timing ng programa, at samakatuwid ang orasan na kumokontrol sa baud rate para sa memory card?
Nagkomento ako ng timer code. Hindi na naulit ang pagkakamali. Ngunit hindi ito nangangahulugan na naayos na namin ito, dahil random na nangyari ang pagkabigo. Paano kung sinuwerte lang ako?
Pagkalipas ng ilang araw, nag-eksperimento akong muli sa programa ng pagsubok. Ang bug ay hindi naulit. Bumalik ako sa buong codebase ng laro at binago ang save at load code upang ang programmable timer ay mag-reset sa orihinal nitong halaga (100Hz) bago i-access ang memory card, at pagkatapos ay i-reset pabalik sa 1kHz. Wala nang mga pag-crash.
Ngunit bakit ito nangyari?
Bumalik ulit ako sa test program. Sinubukan kong maghanap ng ilang pattern sa paglitaw ng isang error na may 1 kHz timer. Sa kalaunan ay napansin ko na ang error ay nangyayari kapag may naglalaro ng PS1 controller. Dahil bihira kong gawin ito sa aking sarili - bakit kailangan ko ng controller kapag sinusubukan ang pag-save at pag-load ng code? - Hindi ko napansin ang pag-asa na ito. Ngunit isang araw ang isa sa aming mga artista ay naghihintay para sa akin na matapos ang pagsubok - malamang na nagmumura ako sa sandaling iyon - at kinakabahan na inikot ang controller sa kanyang mga kamay. May nangyaring pagakamali. "Ano nga ulit?!" Sige, gawin mo ulit!"
Nang mapagtanto ko na ang dalawang kaganapang ito ay magkakaugnay, madali kong nagawang kopyahin ang error: Nagsimula akong mag-record sa memory card, inilipat ang controller, at sinira ang memory card. Para sa akin ito ay mukhang isang hardware bug.
Lumapit ako kay Connie at sinabi sa kanya ang tungkol sa aking natuklasan. Ipinadala niya ang impormasyon sa isa sa mga inhinyero na nagdisenyo ng PS1. "Imposible," sagot niya, "Hindi ito maaaring maging problema sa hardware." I asked Connie to arrange a conversation for us.
Tinawag ako ng engineer at nagtalo kami sa kanyang basag na English at sa aking (sobrang) sira na Japanese. Sa wakas ay sinabi ko, "Hayaan mo lang akong ipadala ang aking 30 line test program kung saan ang paglipat ng controller ay nagdudulot ng bug." Pumayag naman siya. Sinabi na ito ay isang pag-aaksaya ng oras at na siya ay masyadong abala sa paggawa ng isang bagong proyekto, ngunit susuko dahil kami ay isang napakahalagang developer para sa Sony. Nilinis ko ang aking test program at ipinadala ito sa kanya.
Kinabukasan (nasa Los Angeles kami at nasa Tokyo siya) tinawagan niya ako at humihingi ng tawad. Ito ay isang problema sa hardware.
Hindi ko alam kung ano ang eksaktong bug, ngunit mula sa narinig ko sa punong-tanggapan ng Sony, kung itatakda mo ang timer sa sapat na mataas na halaga, nakakasagabal ito sa mga bahagi sa motherboard sa paligid ng kristal ng timer. Ang isa sa mga ito ay isang baud rate controller para sa memory card, na nagtatakda din ng baud rate para sa mga controllers. Hindi ako engineer, kaya baka may nagulo ako.
Ngunit ang ilalim na linya ay mayroong pagkagambala sa pagitan ng mga bahagi sa motherboard. At kapag nagpapadala ng data nang sabay-sabay sa pamamagitan ng controller port at ang memory card port na may timer na tumatakbo sa 1 kHz, nawala ang mga bit, nawala ang data, at nasira ang card.
Masamang baka
Noong 1980s, sumulat ang aking mentor na si Sergei ng software para sa SM-1800, isang Soviet clone ng PDP-11. Ang microcomputer na ito ay na-install lamang sa isang istasyon ng tren malapit sa Sverdlovsk, isang mahalagang transport hub sa USSR. Ang bagong sistema ay idinisenyo upang iruta ang mga bagon at trapiko ng kargamento. Ngunit naglalaman ito ng nakakainis na bug na humantong sa mga random na pag-crash at pag-crash. Palaging nangyayari ang talon kapag may umuwi sa gabi. Ngunit sa kabila ng masusing pagsisiyasat kinabukasan, gumana nang tama ang computer sa lahat ng manu-mano at awtomatikong pagsubok. Ito ay kadalasang nagpapahiwatig ng kundisyon ng lahi o ilang iba pang mapagkumpitensyang bug na nangyayari sa ilalim ng ilang partikular na kundisyon. Pagod sa mga tawag sa gabi, nagpasya si Sergei na makarating sa ilalim nito, at una sa lahat, maunawaan kung anong mga kondisyon sa bakuran ng marshalling ang humantong sa pagkasira ng computer.
Una, nakolekta niya ang mga istatistika ng lahat ng hindi maipaliwanag na pagbagsak at lumikha ng isang graph ayon sa petsa at oras. Ang pattern ay halata. Matapos mag-obserba ng ilang araw, napagtanto ni Sergei na madali niyang mahulaan ang oras ng mga pagkabigo ng system sa hinaharap.
Hindi nagtagal ay nalaman niya na ang mga pagkagambala ay nangyari lamang kapag ang istasyon ay nag-uuri ng mga kargamento ng mga baka mula sa hilagang Ukraine at kanlurang Russia patungo sa isang malapit na katayan. Ito mismo ay kakaiba, dahil ang slaughterhouse ay ibinibigay ng mga bukid na matatagpuan mas malapit, sa Kazakhstan.
Ang Chernobyl nuclear power plant ay sumabog noong 1986, at ang radioactive fallout ay naging dahilan upang hindi matirhan ang mga nakapaligid na lugar. Ang malalawak na lugar sa hilagang Ukraine, Belarus at kanlurang Russia ay nahawahan. Sa paghihinala ng mataas na antas ng radiation sa mga paparating na karwahe, si Sergei ay bumuo ng isang paraan upang subukan ang teoryang ito. Ang populasyon ay ipinagbabawal na magkaroon ng mga dosimeter, kaya inirehistro ni Sergei ang kanyang sarili sa ilang mga militar na lalaki sa istasyon ng tren. Pagkatapos ng ilang inumin ng vodka, nagawa niyang kumbinsihin ang isang sundalo na sukatin ang antas ng radiation sa isa sa mga kahina-hinalang karwahe. Ito ay lumabas na ang antas ay ilang beses na mas mataas kaysa sa mga normal na halaga.
Ang mga baka ay hindi lamang naglabas ng maraming radiation, ang antas nito ay napakataas na humantong sa random na pagkawala ng mga piraso sa memorya ng SM-1800, na matatagpuan sa isang gusali sa tabi ng istasyon.
Nagkaroon ng kakulangan sa pagkain sa USSR, at nagpasya ang mga awtoridad na ihalo ang karne ng Chernobyl sa karne mula sa ibang mga rehiyon ng bansa. Ginawa nitong posible na bawasan ang kabuuang antas ng radyaktibidad nang hindi nawawala ang mahahalagang mapagkukunan. Nang malaman ang tungkol dito, agad na pinunan ni Sergei ang mga dokumento para sa paglipat. At ang mga pag-crash ng computer ay tumigil sa kanilang sarili nang bumaba ang antas ng radiation sa paglipas ng panahon.
Sa pamamagitan ng mga tubo
Noong unang panahon, lumikha ang Movietech Solutions ng software para sa mga sinehan, na idinisenyo para sa accounting, pagbebenta ng ticket at pangkalahatang pamamahala. Ang bersyon ng DOS ng flagship app ay medyo sikat sa maliliit at katamtamang laki ng mga sinehan sa North America. Kaya't hindi nakakagulat na kapag ang isang bersyon ng Windows 95 ay inihayag, isinama sa pinakabagong mga touch screen at self-service kiosk, at nilagyan ng lahat ng uri ng mga tool sa pag-uulat, mabilis din itong naging popular. Kadalasan ang pag-update ay napunta nang walang mga problema. Ang lokal na kawani ng IT ay nag-install ng mga bagong kagamitan, nag-migrate ng data, at nagpatuloy ang negosyo. Maliban kapag hindi ito tumagal. Kapag nangyari ito, ipapadala ng kumpanya si James, na binansagang "The Cleaner."
Bagama't ang palayaw ay nagmumungkahi ng isang kasuklam-suklam na uri, ang tagapaglinis ay kumbinasyon lamang ng instructor, installer at jack-of-all-trades. Gumugugol si James ng ilang araw sa site ng kliyente sa pagsasama-sama ng lahat ng mga bahagi, at pagkatapos ay gugugol ng isa pang dalawang araw sa pagtuturo sa mga tauhan kung paano gamitin ang bagong system, paglutas ng anumang mga problema sa hardware na lumitaw at mahalagang tinutulungan ang software hanggang sa simula nito.
Kaya naman, hindi kataka-taka na sa mga panahong ito, dumating si James sa opisina sa umaga, at bago niya maabot ang kanyang mesa, binati siya ng manager, na puno ng caffeine na higit sa karaniwan.
"Natatakot ako na kailangan mong pumunta sa Annapolis, Nova Scotia, sa lalong madaling panahon." Bumagsak ang kanilang buong sistema, at pagkatapos ng isang gabing pakikipagtulungan sa kanilang mga inhinyero, hindi namin maisip kung ano ang nangyari. Mukhang nabigo ang network sa server. Ngunit pagkatapos lamang na tumakbo ang system ng ilang minuto.
β Hindi ba sila bumalik sa dating sistema? - Seryosong sagot ni James, bagama't sa pag-iisip ay nanlaki ang mga mata niya sa pagtataka.
β Eksakto: ang kanilang IT specialist ay "nagpalit ng mga priyoridad" at nagpasyang umalis kasama ang kanilang lumang server. James, na-install nila ang system sa anim na site at nagbayad lang para sa premium na suporta, at tumatakbo na ngayon ang kanilang negosyo tulad noong 1950s.
Bahagyang umayos si James.
- Ibang usapan yan. Okay, simulan na natin.
Pagdating niya sa Annapolis, ang una niyang ginawa ay hanapin ang unang teatro ng customer na may problema. Sa mapa na kinuha sa paliparan, ang lahat ay mukhang disente, ngunit ang lugar sa paligid ng nais na address ay mukhang kahina-hinala. Hindi ghetto, ngunit nakapagpapaalaala sa film noir. Habang pumarada si James sa gilid ng bangketa sa downtown, nilapitan siya ng isang puta. Dahil sa laki ng Annapolis, malamang na isa lang ito sa buong lungsod. Ang kanyang hitsura ay agad na naalala ang sikat na karakter na nag-aalok ng sex para sa pera sa malaking screen. Hindi, hindi tungkol kay Julia Roberts, kundi tungkol kay Jon Voight [parunggit sa pelikulang "Midnight Cowboy" - approx. lane].
Matapos ipadala ang puta, pumunta si James sa sinehan. Naging mas maayos na ang paligid, ngunit nagbigay pa rin ito ng impresyon na nasagasaan. Hindi naman sa masyadong nag-aalala si James. Nakapunta na siya sa mga kawawang lugar noon. At ito ang Canada, kung saan kahit ang mga mugger ay magalang na magsabi ng "salamat" pagkatapos kunin ang iyong wallet.
Ang gilid na pasukan sa sinehan ay nasa isang dank alley. Pumunta si James sa pinto at kumatok. Maya-maya ay tumikhim ito at bahagyang bumukas.
-Ikaw ba ay isang tagapaglinis? - paos na boses ang nagmula sa loob.
- Oo, ako ito... naparito ako para ayusin ang lahat.
Pumasok si James sa lobby ng sinehan. Tila walang ibang pagpipilian, sinimulan ng mga kawani ang pamimigay ng mga tiket sa papel sa mga bisita. Pinahirapan nito ang pag-uulat sa pananalapi, pabayaan ang higit pang mga kawili-wiling detalye. Pero maluwag na sinalubong ng staff si James at agad itong dinala sa server room.
Sa unang tingin, maayos ang lahat. Nag-log in si James sa server at tiningnan ang mga karaniwang kahina-hinalang lugar. Walang problema. Gayunpaman, dahil sa labis na pag-iingat, isinara ni James ang server, pinalitan ang network card, at ibinalik ang system. Agad siyang nagsimulang magtrabaho nang buo. Nagsimula na namang magbenta ng ticket ang staff.
Tinawagan ni James si Mark at ipinaalam ang sitwasyon. Hindi mahirap isipin na baka gusto ni James na manatili at tingnan kung may hindi inaasahang mangyayari. Bumaba siya ng hagdan at nagsimulang magtanong sa mga empleyado kung ano ang nangyari. Malinaw na ang sistema ay tumigil sa paggana. In-off nila ito at, gumana ang lahat. Ngunit pagkatapos ng 10 minuto ang sistema ay nahulog.
Sa sandaling ito ay may nangyaring katulad nito. Biglang nagsimulang maglabas ng mga error ang sistema ng ticketing. Napabuntong-hininga ang staff at kinuha ang mga papel na ticket, at si James ay nagmamadaling pumunta sa server room. Ang lahat ay mukhang maganda sa server.
Pagkatapos ay pumasok ang isa sa mga empleyado.
β Ang sistema ay gumagana muli.
Nataranta si James dahil wala naman siyang nagawa. Mas tiyak, walang makakapagpagana sa system. Nag-log out siya, kinuha ang kanyang telepono, at tinawagan ang linya ng suporta ng kanyang kumpanya. Hindi nagtagal ay pumasok ang parehong empleyado sa silid ng server.
- Ang sistema ay down.
Napatingin si James sa server. Isang kawili-wili at pamilyar na pattern ng maraming kulay na mga hugis ang sumayaw sa screen - magulong namimilipit at magkakaugnay na mga tubo. Nakita na nating lahat ang screensaver na ito minsan. Ito ay maganda ang pagkaka-render at literal na nakaka-hypnotize.
Pinindot ni James ang isang button at nawala ang pattern. Nagmamadali siyang pumunta sa ticket office at sa daan ay nakasalubong niya ang isang empleyadong bumabalik sa kanya.
β Ang sistema ay gumagana muli.
Kung makapag-mental facepalm, ganyan talaga ang ginawa ni James. Screensaver. Gumagamit ito ng OpenGL. At samakatuwid, sa panahon ng operasyon, ginagamit nito ang lahat ng mga mapagkukunan ng processor ng server. Bilang resulta, ang bawat tawag sa server ay nagtatapos sa isang timeout.
Bumalik si James sa server room, nag-log in, at pinalitan ang screensaver ng magagandang pipe na may blangkong screen. Ibig sabihin, sa halip na isang screensaver na kumukonsumo ng 100% ng mga mapagkukunan ng processor, nag-install ako ng isa pang hindi kumukonsumo ng mga mapagkukunan. Pagkatapos ay naghintay ako ng 10 minuto upang suriin ang aking hula.
Pagdating ni James sa susunod na sinehan, iniisip niya kung paano ipapaliwanag sa manager niya na 800 km lang ang byahe niya para patayin ang screen saver.
Pag-crash sa isang tiyak na yugto ng buwan
Totoong kwento. Isang araw, lumitaw ang isang software bug na nakasalalay sa yugto ng buwan. Mayroong isang maliit na gawain na karaniwang ginagamit sa iba't ibang mga programa ng MIT upang kalkulahin ang approximation sa tunay na yugto ng Buwan. Binuo ng GLS ang routine na ito sa isang LISP program na, kapag nagsusulat ng file, ay maglalabas ng linya na may timestamp na halos 80 character ang haba. Napakabihirang na ang unang linya ng isang mensahe ay magiging masyadong mahaba at hahantong sa susunod na linya. At nang basahin ng programa ang file na ito sa ibang pagkakataon, sumpain ito. Ang haba ng unang linya ay nakadepende sa eksaktong petsa at oras, pati na rin ang haba ng detalye ng phase sa oras na na-print ang timestamp. Ibig sabihin, literal na nakadepende ang bug sa yugto ng buwan!
Unang edisyon ng papel (Steele-1983) ay naglalaman ng isang halimbawa ng ganoong linya na humantong sa inilarawang bug, ngunit ang typesetter ay "naayos" ito. Ito ay mula noon ay inilarawan bilang isang "moon phase bug".
Gayunpaman, mag-ingat sa mga pagpapalagay. Ilang taon na ang nakalilipas, ang mga inhinyero mula sa CERN (European Center for Nuclear Research) ay nakatagpo ng mga pagkakamali sa mga eksperimento na isinagawa sa Large Electron-Positron Collider. Dahil aktibong pinoproseso ng mga computer ang napakalaking dami ng data na nabuo ng device na ito bago ipakita ang resulta sa mga siyentipiko, marami ang nag-isip na ang software ay kahit papaano ay sensitibo sa yugto ng buwan. Ilang desperadong inhinyero ang nakarating sa ilalim ng katotohanan. Ang pagkakamali ay lumitaw dahil sa isang bahagyang pagbabago sa geometry ng 27 km na haba ng singsing dahil sa pagpapapangit ng Earth sa panahon ng pagpasa ng Buwan! Ang kuwentong ito ay pumasok sa physics folklore bilang "Newton's Revenge on Particle Physics" at isang halimbawa ng koneksyon sa pagitan ng pinakasimple at pinakalumang batas ng physics at ang pinaka-advanced na mga konseptong siyentipiko.
Ang pag-flush sa banyo ay huminto sa tren
Ang pinakamagandang hardware bug na narinig ko ay nasa isang high speed na tren sa France. Ang bug ay humantong sa emergency braking ng tren, ngunit kung may mga pasaherong sakay. Sa bawat ganoong kaso, ang tren ay inalis sa serbisyo, sinuri, ngunit walang natagpuan. Pagkatapos ay pinabalik siya sa linya, at agad siyang napahinto.
Sa panahon ng isa sa mga tseke, isang inhinyero na naglalakbay sa tren ang pumunta sa banyo. Hindi nagtagal ay naghugas siya, BOOM! Emergency stop.
Nakipag-ugnayan ang engineer sa driver at nagtanong:
β Ano ang ginagawa mo bago magpreno?
- Buweno, binagalan ko ang pagbaba...
Ito ay kakaiba, dahil sa normal na operasyon ang tren ay bumagal sa pagbaba ng dose-dosenang beses. Nagpatuloy ang tren, at sa susunod na pagbaba ay nagbabala ang tsuper:
- Magdahan-dahan ako.
Walang nangyari.
β Ano ang ginawa mo noong huling pagpreno? - tanong ng driver.
- Well... nasa banyo ako...
- Well, pagkatapos ay pumunta sa banyo at gawin kung ano ang ginawa mo kapag bumaba tayo muli!
Nagpunta ang inhinyero sa banyo, at nang magbabala ang tsuper: βBinabagal ko ang takbo,β nag-flush siya ng tubig. Syempre, huminto agad ang tren.
Ngayon ay maaari nilang kopyahin ang problema at kailangan nilang hanapin ang dahilan.
Pagkaraan ng dalawang minuto, napansin nilang ang remote control cable ng brake ng engine (ang tren ay may isang makina sa bawat dulo) ay nakadiskonekta sa dingding ng electrical cabinet at nakahiga sa relay na kumokontrol sa toilet plug solenoid... Kapag ang relay ay naka-on, lumikha ito ng interference sa brake cable, at ang proteksyon ng system laban sa mga pagkabigo ay kasama lang ang emergency braking.
Ang gateway na kinasusuklaman ang FORTRAN
Ilang buwan na ang nakalipas, napansin namin na ang mga koneksyon sa network sa mainland [ito ay nasa Hawaii] ay nagiging napakabagal. Ito ay maaaring tumagal ng 10-15 minuto at pagkatapos ay biglang mangyari muli. Pagkaraan ng ilang oras, ang aking kasamahan ay nagreklamo sa akin na ang mga koneksyon sa network sa mainland sa pangkalahatan hindi gumagana. Mayroon siyang ilang FORTRAN code na kailangang kopyahin sa isang makina sa mainland, ngunit hindi ito magawa dahil "hindi natagalan ang network para makumpleto ang pag-upload ng FTP."
Oo, lumabas na ang mga pagkabigo sa network ay nangyari nang sinubukan ng isang kasamahan na i-FTP ang isang file na may source code sa FORTRAN sa isang makina sa mainland. Sinubukan naming i-archive ang file: pagkatapos ay kinopya ito nang maayos (ngunit ang target na makina ay walang unpacker, kaya hindi nalutas ang problema). Sa wakas ay "hinati" namin ang FORTRAN code sa napakaliit na piraso at ipinadala ang mga ito nang paisa-isa. Karamihan sa mga fragment ay kinopya nang walang problema, ngunit ang ilang piraso ay hindi pumasa, o lumipas pagkatapos marami mga pagtatangka.
Nang suriin namin ang mga may problemang sipi, natuklasan namin na may pagkakatulad ang mga ito: lahat sila ay naglalaman ng mga bloke ng komento na nagsimula at nagtatapos sa mga linya na binubuo ng capital C (bilang isang kasamahan ay ginustong magkomento sa FORTRAN). Nag-email kami sa mga eksperto sa network sa mainland at humingi ng tulong. Siyempre, gusto nilang makakita ng mga sample ng aming mga file na hindi mailipat sa pamamagitan ng FTP... ngunit hindi nakarating sa kanila ang aming mga sulat. Sa wakas nakabuo kami ng isang simple ilarawankung ano ang hitsura ng mga hindi naililipat na file. Nagtrabaho ito :) [Maglakas-loob ba akong magdagdag ng isang halimbawa ng isa sa mga problemang komento ng FORTRAN dito? Malamang hindi sulit!]
Sa huli ay napag-isipan namin ito. Isang bagong gateway ang na-install kamakailan sa pagitan ng aming bahagi ng campus at ng mainland network. Ito ay nagkaroon ng malaking kahirapan sa pagpapadala ng mga packet na naglalaman ng paulit-ulit na piraso ng uppercase na C! Ang ilan lamang sa mga packet na ito ay maaaring kunin ang lahat ng mga mapagkukunan ng gateway at maiwasan ang karamihan sa iba pang mga packet na makapasok. Nagreklamo kami sa tagagawa ng gateway... at sumagot sila: βOh, oo, nahaharap ka sa isang bug ng paulit-ulit na C! Alam na natin ang tungkol sa kanya.β Sa kalaunan ay nalutas namin ang problema sa pamamagitan ng pagbili ng bagong gateway mula sa isa pang tagagawa (sa depensa ng una, ang kawalan ng kakayahang maglipat ng mga programa ng FORTRAN ay maaaring maging isang kalamangan para sa ilan!).
Mahirap na panahon
Ilang taon na ang nakalilipas, habang gumagawa ng ETL system sa Perl para bawasan ang mga gastos sa phase 40 na mga klinikal na pagsubok, kailangan kong iproseso ang humigit-kumulang 000 petsa. Dalawa sa kanila ang hindi nakapasa sa pagsusulit. Hindi ito masyadong nag-abala sa akin dahil ang mga petsang ito ay kinuha mula sa data na ibinigay ng kliyente na kadalasan, sasabihin ba nating, nakakagulat. Ngunit nang suriin ko ang orihinal na data, lumabas na ang mga petsang ito ay Enero 1, 2011 at Enero 1, 2007. Akala ko ang bug ay nakapaloob sa program na aking sinulat, ngunit ito ay naging 30 taon na. luma. Ito ay maaaring mukhang mahiwaga sa mga hindi pamilyar sa software ecosystem. Dahil sa matagal nang desisyon ng isa pang kumpanya na kumita ng pera, binayaran ako ng aking kliyente para ayusin ang isang bug na aksidenteng ipinakilala ng isang kumpanya at sinasadya ng isa pa. Para maintindihan mo ang sinasabi ko, kailangan kong pag-usapan ang kumpanyang nagdagdag ng feature na naging bug, pati na rin ang ilang iba pang kawili-wiling kaganapan na nag-ambag sa misteryosong bug na naayos ko.
Noong unang panahon, ang mga Apple computer ay kusang nagre-reset ng kanilang petsa sa Enero 1, 1904. Simple lang ang dahilan: gumamit ito ng "system clock" na pinapagana ng baterya para subaybayan ang petsa at oras. Ano ang nangyari noong namatay ang baterya? Ang mga computer ay nagsimulang subaybayan ang petsa sa pamamagitan ng bilang ng mga segundo mula noong simula ng isang panahon. Sa pamamagitan ng kapanahunan, sinadya namin ang orihinal na petsa ng sanggunian, at para sa Macintoshes ito ay Enero 1, 1904. At pagkatapos mamatay ang baterya, ang kasalukuyang petsa ay na-reset sa tinukoy na isa. Ngunit bakit ito nangyari?
Noong nakaraan, gumamit ang Apple ng 32 bits upang iimbak ang bilang ng mga segundo mula noong orihinal na petsa. Ang isang bit ay maaaring mag-imbak ng isa sa dalawang halaga - 1 o 0. Dalawang bit ay maaaring mag-imbak ng isa sa apat na halaga: 00, 01, 10, 11. Tatlong bits - isang halaga sa walong: 000, 001, 010, 011, 100 , 101, 110, 111, atbp. At ang 32 ay maaaring mag-imbak ng isa sa 232 na halaga, iyon ay, 4 segundo. Para sa mga petsa ng Apple, ito ay katumbas ng humigit-kumulang 294 na taon, kaya ang mga mas lumang Mac ay hindi maaaring humawak ng mga petsa pagkatapos ng 967. At kung mamatay ang baterya ng system, ire-reset ang petsa sa 296 segundo mula noong simula ng panahon, at kailangan mong manu-manong itakda ang petsa sa tuwing bubuksan mo ang computer (o hanggang sa bumili ka ng bagong baterya).
Gayunpaman, ang desisyon ng Apple na mag-imbak ng mga petsa bilang mga segundo mula noong panahon ay nangangahulugan na hindi namin mahawakan ang mga petsa bago ang kapanahunan, na may malalayong kahihinatnan, gaya ng makikita natin. Ipinakilala ng Apple ang isang tampok, hindi isang bug. Sa iba pang mga bagay, nangangahulugan ito na ang Macintosh operating system ay immune sa "millennium bug" (na hindi masasabi tungkol sa maraming mga Mac application na may sariling mga sistema ng petsa upang iwasan ang mga paghihigpit).
Sige lang. Ginamit namin ang Lotus 1-2-3, ang "killer application" ng IBM na tumulong sa paglunsad ng PC revolution, bagama't may VisiCalc ang mga Apple computer, na naging matagumpay sa personal na computer. In fairness, kung hindi lumabas ang 1-2-3, halos hindi mag-alis ang mga PC, at ang kasaysayan ng mga personal na computer ay maaaring magkaiba. Mali ang pagtrato ng Lotus 1-2-3 noong 1900 bilang isang leap year. Nang inilabas ng Microsoft ang unang spreadsheet nito, ang Multiplan, nakuha nito ang isang maliit na bahagi ng merkado. At nang ilunsad nila ang proyektong Excel, nagpasya silang hindi lamang kopyahin ang scheme ng pagpapangalan ng row at column mula sa Lotus 1-2-3, kundi pati na rin upang matiyak ang compatibility ng bug sa pamamagitan ng sadyang pagtrato sa 1900 bilang isang leap year. Ang problemang ito ay umiiral pa rin hanggang ngayon. Iyon ay, sa 1-2-3 ito ay isang bug, ngunit sa Excel ito ay isang malay na desisyon na tinitiyak na ang lahat ng 1-2-3 na mga gumagamit ay maaaring mag-import ng kanilang mga talahanayan sa Excel nang hindi binabago ang data, kahit na ito ay mali.
Ngunit may isa pang problema. Una, inilabas ng Microsoft ang Excel para sa Macintosh, na hindi nakilala ang mga petsa bago ang Enero 1, 1904. At sa Excel, ang Enero 1, 1900 ay itinuturing na simula ng panahon. Samakatuwid, ang mga developer ay gumawa ng pagbabago upang makilala ng kanilang programa ang uri ng panahon at nag-imbak ng data sa loob mismo alinsunod sa nais na panahon. Sumulat pa nga ang Microsoft ng isang paliwanag na artikulo tungkol dito. At ang desisyong ito ay humantong sa aking bug.
Nakatanggap ang aking ETL system ng mga Excel spreadsheet mula sa mga customer na ginawa sa Windows, ngunit maaari ding gawin sa Mac. Samakatuwid, ang simula ng panahon sa talahanayan ay maaaring alinman sa Enero 1, 1900, o Enero 1, 1904. Paano malalaman? Ang format ng Excel file ay nagpapakita ng kinakailangang impormasyon, ngunit ang parser na ginamit ko ay hindi nagpakita nito (ngayon ay ginagawa na), at ipinapalagay na alam mo ang panahon para sa isang partikular na talahanayan. Malamang na gumugol ako ng mas maraming oras sa pag-unawa sa Excel binary format at pagpapadala ng patch sa parser author, ngunit marami pa akong dapat gawin para sa kliyente, kaya mabilis akong nagsulat ng heuristic upang matukoy ang panahon. Simple lang siya.
Sa Excel, ang petsang Hulyo 5, 1998 ay maaaring katawanin sa format na "07-05-98" (walang silbing sistemang Amerikano), "Hul 5, 98", "Hulyo 5, 1998", "5-Hul-98" o ibang format.isa pang walang kwentang format (ironically, isa sa mga format na hindi inaalok ng version ko ng Excel ay ISO 8601). Gayunpaman, sa loob ng talahanayan, ang hindi na-format na petsa ay inimbak bilang alinman sa "35981" para sa epoch-1900 o "34519" para sa epoch-1904 (ang mga numero ay kumakatawan sa bilang ng mga araw mula noong panahon). Gumamit lang ako ng simpleng parser para kunin ang taon mula sa na-format na petsa, at pagkatapos ay ginamit ang Excel parser para kunin ang taon mula sa hindi na-format na petsa. Kung ang parehong mga halaga ay naiiba ng 4 na taon, alam ko na gumagamit ako ng isang sistema na may epoch-1904.
Bakit hindi na lang ako gumamit ng mga naka-format na petsa? Dahil ang Hulyo 5, 1998 ay maaaring i-format bilang "Hulyo, 98" na nawala ang araw ng buwan. Nakatanggap kami ng mga talahanayan mula sa napakaraming kumpanya na lumikha ng mga ito sa napakaraming iba't ibang paraan na nasa amin (sa kasong ito, ako) upang malaman ang mga petsa. At saka, kung tama ang nakuha ng Excel, dapat din tayo!
Kasabay nito ay nakatagpo ako ng 39082. Hayaan mong ipaalala ko sa iyo na itinuturing ng Lotus 1-2-3 ang 1900 bilang isang leap year, at ito ay matapat na inulit sa Excel. At dahil nagdagdag ito ng isang araw sa taong 1900, maraming mga function ng pagkalkula ng petsa ang maaaring mali para sa mismong araw na iyon. Ibig sabihin, ang 39082 ay maaaring noong Enero 1, 2011 (sa mga Mac) o Disyembre 31, 2006 (sa Windows). Kung kinuha ng aking "year parser" ang taong 2011 mula sa naka-format na halaga, kung gayon ang lahat ay maayos. Ngunit dahil hindi alam ng Excel parser kung anong epoch ang ginagamit, nagde-default ito sa epoch-1900, na ibinabalik ang taong 2006. Nakita ng aking aplikasyon na ang pagkakaiba ay 5 taon, itinuring itong isang error, na-log ito, at nagbalik ng hindi na-format na halaga.
Upang makalibot dito, isinulat ko ito (pseudocode):
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
At pagkatapos lahat ng 40 petsa ay na-parse ng tama.
Sa gitna ng malalaking print job
Noong unang bahagi ng 1980s, nagtrabaho ang aking ama sa Storage Technology, isang hindi na gumaganang dibisyon na lumikha ng mga tape drive at pneumatic system para sa high-speed tape feeding.
Idinisenyo nilang muli ang mga drive upang magkaroon sila ng isang sentral na "A" na drive na konektado sa pitong "B" na mga drive, at ang maliit na OS sa RAM na kumokontrol sa "A" na drive ay maaaring magtalaga ng mga operasyon sa pagbasa at pagsulat sa lahat ng "B" na mga drive.
Sa tuwing sinimulan ang drive na "A", kinakailangan na magpasok ng floppy disk sa peripheral drive na konektado sa "A" upang mai-load ang operating system sa memorya nito. Ito ay napaka-primitive: computing power ay ibinigay ng isang 8-bit microcontroller.
Ang target na audience para sa naturang kagamitan ay mga kumpanyang may napakalaking data warehouse - mga bangko, retail chain, atbp. - na kailangang mag-print ng maraming address label o bank statement.
Nagkaroon ng problema ang isang kliyente. Sa gitna ng isang pag-print, ang isang partikular na drive na "A" ay maaaring huminto sa paggana, na magiging sanhi ng pagtigil ng buong trabaho. Upang maibalik ang pagpapatakbo ng drive, kailangang i-reboot ng staff ang lahat. At kung nangyari ito sa gitna ng isang anim na oras na gawain, kung gayon ang isang malaking halaga ng mamahaling oras ng computer ay nawala at ang iskedyul ng buong operasyon ay nagambala.
Ipinadala ang mga technician mula sa Storage Technologies. Ngunit sa kabila ng kanilang pinakamahusay na pagsisikap, hindi nila nagawang kopyahin ang bug sa ilalim ng mga kondisyon ng pagsubok: tila nangyari ito sa gitna ng malalaking pag-print. Ang problema ay hindi ang hardware, pinalitan nila ang lahat ng kanilang makakaya: RAM, microcontroller, floppy drive, bawat naiisip na bahagi ng tape drive - nagpatuloy ang problema.
Pagkatapos ay tinawag ng mga technician ang punong tanggapan at tinawag ang Eksperto.
Ang dalubhasa ay kumuha ng upuan at isang tasa ng kape, naupo sa silid ng kompyuterβnoong mga panahong iyon ay may mga silid na nakatuon sa mga kompyuterβat pinanood ang mga tauhan habang nakapila sa isang malaking print job. Ang eksperto ay naghihintay para sa isang kabiguan na mangyari - at nangyari ito. Napatingin ang lahat sa Eksperto, ngunit wala siyang ideya kung bakit nangyari ito. Kaya inutusan niyang ipila muli ang trabaho, at bumalik sa trabaho ang lahat ng staff at technician.
Ang eksperto ay muling umupo sa upuan at nagsimulang maghintay para sa isang kabiguan. Humigit-kumulang anim na oras ang lumipas at nangyari ang kabiguan. Ang Eksperto muli ay walang ideya, maliban na ang lahat ay nangyari sa isang silid na puno ng mga tao. Iniutos niya na i-restart ang misyon, umupo muli at naghintay.
Sa ikatlong kabiguan, may napansin ang Eksperto. Ang kabiguan ay nangyari nang ang mga tauhan ay nagpalit ng mga teyp sa isang dayuhang biyahe. Bukod dito, ang pagkabigo ay naganap sa sandaling ang isa sa mga empleyado ay lumakad sa isang tiyak na tile sa sahig.
Ang nakataas na sahig ay gawa sa aluminum tiles na inilatag sa taas na 6 hanggang 8 pulgada. Maraming mga wire mula sa mga computer ang tumakbo sa ilalim ng nakataas na palapag upang maiwasan ang sinuman na aksidenteng matapakan ang isang mahalagang cable. Ang mga tile ay inilatag nang napakahigpit upang maiwasan ang mga labi na makapasok sa ilalim ng nakataas na sahig.
Napagtanto ng eksperto na ang isa sa mga tile ay deformed. Nang tumapak ang isang empleyado sa sulok nito, ang mga gilid ng tile ay nagkuskos sa mga katabing tile. Ang mga plastik na bahagi na nakakonekta sa mga tile ay kuskusin din sa kanila, na nagdulot ng mga static na microdischarge na lumikha ng interference sa dalas ng radyo.
Ngayon, ang RAM ay mas mahusay na protektado mula sa radio frequency interference. Ngunit sa mga taong iyon ay hindi ito ang kaso. Napagtanto ng eksperto na ang pagkagambala na ito ay nakakagambala sa memorya, at kasama nito ang pagpapatakbo ng operating system. Tumawag siya sa serbisyo ng suporta, nag-order ng mga bagong tile, nag-install mismo ng mga ito, at nawala ang problema.
High tide na!
Ang kwento ay naganap sa isang silid ng server, sa ikaapat o ikalimang palapag ng isang opisina sa Portsmouth (sa tingin ko), sa lugar ng pantalan.
Isang araw nag-crash ang Unix server na may pangunahing database. Ni-reboot nila siya, ngunit masaya siyang nagpatuloy sa pagbagsak nang paulit-ulit. Nagpasya kaming tumawag sa isang tao mula sa serbisyo ng suporta.
Yung support guy... Mark yata ang pangalan niya, but that doesn't matter... Parang hindi ko siya kilala. Hindi mahalaga, talaga. Manatili tayo kay Mark, okay? Malaki.
Kaya, makalipas ang ilang oras ay dumating si Mark (ito ay hindi malayo mula sa Leeds hanggang Portsmouth, alam mo), na-on ang server at lahat ay gumana nang walang problema. Karaniwang mapahamak na suporta, ang kliyente ay nababahala tungkol dito. Tinitingnan ni Mark ang mga log file at walang nakitang hindi maganda. Kaya't bumalik si Mark sa tren (o anumang paraan ng transportasyon na kanyang narating, maaaring ito ay isang pilay na baka para sa lahat ng alam ko ... gayon pa man, hindi mahalaga, okay?) at bumalik sa Leeds, na nasayang. ang araw.
Nang gabi ring iyon, nag-crash muli ang server. Ang kwento ay pareho... ang server ay hindi tumataas. Sinusubukang tumulong ni Mark nang malayuan, ngunit hindi masimulan ng kliyente ang server.
Isa pang tren, bus, lemon meringue o iba pang kalokohan, at bumalik si Mark sa Portsmouth. Tingnan mo, nagbo-boot ang server nang walang anumang problema! Himala. Si Mark ay gumugugol ng ilang oras sa pag-check kung ang lahat ay maayos sa operating system o software at nag-set off para sa Leeds.
Sa bandang kalagitnaan ng araw nag-crash ang server (dahan-dahan lang!). Sa pagkakataong ito, tila makatwirang dalhin ang mga taong sumusuporta sa hardware upang palitan ang server. Pero hindi, after mga 10 hours bumagsak din.
Naulit ang sitwasyon sa loob ng ilang araw. Gumagana ang server, nag-crash pagkatapos ng humigit-kumulang 10 oras at hindi magsisimula sa susunod na 2 oras. Sinuri nila ang paglamig, paglabas ng memorya, sinuri nila ang lahat, ngunit walang nakita. Pagkatapos ay tumigil ang mga pag-crash.
Lumipas ang linggong walang pakialam... masaya ang lahat. Masaya hanggang sa magsimula muli ang lahat. Ang larawan ay pareho. 10 oras ng trabaho, 2-3 oras ng downtime...
At pagkatapos ay isang tao (sa tingin ko ay sinabi nila sa akin na ang taong ito ay walang kinalaman sa IT) ang nagsabi:
"Ito ay ang tubig!"
Ang tandang ay sinalubong ng mga blangkong titig, at ang kamay ng isang tao ay malamang na nag-alinlangan sa pindutan ng tawag sa seguridad.
"Ito ay huminto sa pagtatrabaho sa tubig."
Ito ay tila isang ganap na dayuhang konsepto sa mga manggagawang sumusuporta sa IT, na malamang na hindi magbasa ng Tide Yearbook habang nakaupo para magkape. Ipinaliwanag nila na hindi ito maaaring nauugnay sa pagtaas ng tubig sa anumang paraan, dahil ang server ay nagtatrabaho nang isang linggo nang walang pagkabigo.
"Noong nakaraang linggo ay mababa ang tubig, ngunit ngayong linggo ito ay mataas."
Isang maliit na terminolohiya para sa mga walang lisensya ng yate. Ang pagtaas ng tubig ay nakasalalay sa ikot ng buwan. At habang umiikot ang Earth, bawat 12,5 oras ang gravitational pull ng Araw at Buwan ay lumilikha ng tidal wave. Sa simula ng 12,5-hour cycle ay may high tide, sa gitna ng cycle ay may ebb, at sa dulo ay high tide na naman. Ngunit habang nagbabago ang orbit ng buwan, nagbabago rin ang pagkakaiba ng low at high tide. Kapag ang Buwan ay nasa pagitan ng Araw at ng Earth o sa kabilang panig ng Earth (full moon o walang buwan), nakakakuha tayo ng Syzygyn tides - ang pinakamataas na high tides at ang pinakamababang low tides. Sa kalahating buwan nakakakuha tayo ng quadrature tides - ang lowest tides. Ang pagkakaiba sa pagitan ng dalawang sukdulan ay lubhang nababawasan. Ang lunar cycle ay tumatagal ng 28 araw: syzygian - quadrature - syzygian - quadrature.
Nang ipaliwanag sa mga technician ang esensya ng tidal forces, agad nilang naisip na kailangan nilang tumawag ng pulis. At medyo lohikal. Ngunit lumalabas na tama ang dude. Dalawang linggo bago nito, isang maninira ang dumaong hindi kalayuan sa opisina. Sa bawat oras na itinaas ito ng tubig sa isang tiyak na taas, ang radar post ng barko ay napupunta sa antas ng sahig ng server room. At ang radar (o electronic warfare equipment, o iba pang laruang militar) ay lumikha ng kaguluhan sa mga computer.
Misyon ng paglipad para sa rocket
Ako ay naatasang mag-port ng isang malaking (mga 400 libong linya) na rocket launch control at monitoring system sa mga bagong bersyon ng operating system, compiler at wika. Mas tiyak, mula sa Solaris 2.5.1 hanggang Solaris 7, at mula sa Verdix Ada Development System (VADS), na nakasulat sa Ada 83, hanggang sa Rational Apex Ada system, na nakasulat sa Ada 95. Ang VADS ay binili ng Rational, at ang produkto nito ay hindi na ginagamit, bagama't sinubukan ng Rational na ipatupad ang mga katugmang bersyon ng mga pakete na partikular sa VADS upang mapagaan ang paglipat sa Apex compiler.
Tatlong tao ang tumulong sa akin na mai-compile nang malinis ang code. Tumagal ng dalawang linggo. At pagkatapos ay nagtrabaho ako sa aking sarili upang gumana ang system. Sa madaling salita, ito ang pinakamasamang arkitektura at pagpapatupad ng isang software system na naranasan ko, kaya tumagal ng isa pang dalawang buwan upang makumpleto ang port. Pagkatapos ay isinumite ang system para sa pagsubok, na tumagal ng ilang buwan. Agad kong itinama ang mga bug na natagpuan sa panahon ng pagsubok, ngunit ang kanilang bilang ay mabilis na nabawasan (ang source code ay isang sistema ng produksyon, kaya ang pag-andar nito ay gumana nang lubos, kailangan ko lang alisin ang mga bug na lumitaw sa panahon ng pagbagay sa bagong compiler). Sa kalaunan, kapag ang lahat ay gumagana ayon sa nararapat, inilipat ako sa ibang proyekto.
At noong Biyernes bago ang Thanksgiving, nag-ring ang telepono.
Ang paglulunsad ng rocket ay dapat na masuri sa halos tatlong linggo, at sa panahon ng mga pagsubok sa laboratoryo ng countdown, ang pagkakasunud-sunod ng mga utos ay naharang. Sa totoong buhay, aabort nito ang pagsubok, at kung ang pagbara ay nangyari sa loob ng ilang segundo ng pagsisimula ng makina, maraming hindi maibabalik na aksyon ang magaganap sa mga auxiliary system, na mangangailangan ng mahaba - at mahal na kahandaan ng rocket. Hindi sana ito magsisimula, ngunit maraming mga tao ang nalungkot sa pagkawala ng oras at maraming, maraming pera. Huwag hayaan ang sinuman na sabihin sa iyo na ang Kagawaran ng Depensa ay gumagastos ng pera nang walang ingatβhindi pa ako nakatagpo ng isang contracting manager na hindi inuna ang badyet o pangalawa, na sinusundan ng iskedyul.
Sa mga nakaraang buwan, ang hamon ng countdown na ito ay pinatakbo nang daan-daang beses sa maraming mga variation, na may kaunting mga hiccups lang. Kaya't ang posibilidad na mangyari ito ay napakababa, ngunit ang mga kahihinatnan nito ay lubhang makabuluhan. I-multiply ang parehong mga salik na ito, at mauunawaan mo na ang balita ay hinulaang isang nasirang linggo ng bakasyon para sa akin at sa dose-dosenang mga inhinyero at tagapamahala.
At nabigyan ako ng pansin bilang taong nag-port ng sistema.
Tulad ng karamihan sa mga sistemang kritikal sa seguridad, maraming mga parameter ang na-log, kaya medyo madaling matukoy ang ilang linya ng code na naisakatuparan bago nag-crash ang system. At siyempre, walang ganap na kakaiba sa kanila; ang parehong mga expression ay matagumpay na naisakatuparan nang literal libu-libong beses sa parehong pagtakbo.
Tinawag namin ang mga tao mula sa Apex sa Rational dahil sila ang bumuo ng compiler at ang ilan sa mga nakagawiang ginawa nila ay tinawag sa kahina-hinalang code. Sila (at lahat ng iba pa) ay humanga na may pangangailangang makarating sa ugat ng isang problemang literal na pambansang kahalagahan.
Dahil walang interesante sa mga journal, nagpasya kaming subukang kopyahin ang problema sa isang lokal na laboratoryo. Ito ay hindi isang madaling gawain dahil ang kaganapan ay naganap nang humigit-kumulang isang beses sa bawat 1000 na pagtakbo. Ang isang pinaghihinalaang dahilan ay ang isang tawag sa isang function na mutex na binuo ng vendor (bahagi ng package ng paglipat ng VADS) Unlock hindi humantong sa pag-unlock. Ang processing thread na tinatawag na function ay nagproseso ng mga mensahe ng heartbeat, na karaniwang dumarating bawat segundo. Itinaas namin ang dalas sa 10 Hz, iyon ay, 10 beses bawat segundo, at nagsimulang tumakbo. Makalipas ang halos isang oras ay nag-lock ang system mismo. Sa log, nakita namin na ang pagkakasunud-sunod ng mga naitala na mensahe ay pareho sa panahon ng nabigong pagsubok. Gumawa kami ng ilang higit pang mga pagtakbo, ang system ay patuloy na na-block 45-90 minuto pagkatapos ng pagsisimula, at sa bawat oras na ang log ay naglalaman ng parehong ruta. Kahit na kami ay teknikal na nagpapatakbo ng iba't ibang code - ang dalas ng mensahe ay naiiba - ang pag-uugali ng system ay pareho, kaya kami ay kumpiyansa na ang senaryo ng pag-load na ito ay nagdudulot ng parehong problema.
Ngayon kailangan naming malaman kung saan eksaktong naganap ang pagharang sa pagkakasunud-sunod ng mga expression.
Ginamit ng pagpapatupad na ito ng system ang Ada task system, at ginamit ito nang hindi maganda. Ang mga gawain ay isang mataas na antas na sabay-sabay na maipapatupad na konstruksyon sa Ada, tulad ng mga thread ng pagpapatupad, na binuo lamang sa mismong wika. Kapag ang dalawang gawain ay kailangang makipag-usap, sila ay "nagtakda ng isang pagtatagpo", nagpapalitan ng kinakailangang data, at pagkatapos ay itinigil ang pagtatagpo at bumalik sa kanilang mga independiyenteng pagpapatupad. Gayunpaman, ang sistema ay ipinatupad nang iba. Matapos ang isang target na gawain ay nakipagtagpo, ang target na gawain ay nakipagtagpo sa isa pang gawain, na pagkatapos ay nakipagtagpo sa isang pangatlong gawain, at iba pa hanggang sa makumpleto ang ilang pagproseso. Pagkatapos nito, natapos ang lahat ng pagtatagpo na ito at ang bawat gawain ay kailangang bumalik sa pagpapatupad nito. Ibig sabihin, kinakaharap namin ang pinakamahal na function call system sa mundo, na huminto sa buong proseso ng "multitasking" habang pinoproseso nito ang bahagi ng input data. At bago ito ay hindi humantong sa mga problema lamang dahil ang throughput ay napakababa.
Inilarawan ko ang mekanismo ng gawaing ito dahil kapag hiniling o inaasahang makumpleto ang isang pagtatagpo, maaaring magkaroon ng "task switch". Iyon ay, ang processor ay maaaring magsimulang magproseso ng isa pang gawain na handa nang isagawa. Lumalabas na kapag ang isang gawain ay handa nang makipagtagpo sa isa pang gawain, ang isang ganap na naiibang gawain ay maaaring magsimulang magsagawa, at kalaunan ay bumalik ang kontrol sa unang pagtatagpo. At maaaring mangyari ang iba pang mga kaganapan na nagiging sanhi ng paglipat ng gawain; ang isang ganoong kaganapan ay isang tawag sa isang function ng system, tulad ng pag-print o pagpapatupad ng isang mutex.
Upang maunawaan kung aling linya ng code ang nagdulot ng problema, kailangan kong humanap ng paraan upang maitala ang pag-unlad sa pamamagitan ng pagkakasunud-sunod ng mga pahayag nang hindi nagti-trigger ng switch ng gawain, na mapipigilan ang pag-crash na mangyari. Kaya hindi ko na-take advantage Put_Line()upang maiwasan ang pagsasagawa ng mga operasyon ng I/O. Maaari akong magtakda ng counter variable o katulad nito, ngunit paano ko makikita ang halaga nito kung hindi ko ito maipakita sa screen?
Gayundin, kapag sinusuri ang log, lumabas na, sa kabila ng pag-freeze sa pagproseso ng mga mensahe ng tibok ng puso, na humarang sa lahat ng mga operasyon ng I/O ng proseso at pumigil sa iba pang pagproseso na maisagawa, ang iba pang mga independiyenteng gawain ay patuloy na naisakatuparan. Iyon ay, ang gawain ay hindi ganap na na-block, isang (kritikal) lamang na hanay ng mga gawain.
Ito ang clue na kailangan upang suriin ang pagharang ng expression.
Gumawa ako ng isang package ng Ada na naglalaman ng isang gawain, isang enumerated na uri, at isang pandaigdigang variable ng ganoong uri. Ang mga enumerable na literal ay nakatali sa mga partikular na expression ng problemang pagkakasunod-sunod (hal. Incrementing_Buffer_Index, Locking_Mutex, Mutex_Unlocked), at pagkatapos ay nagpasok ng mga expression ng pagtatalaga dito na nagtalaga ng kaukulang enumeration sa isang global variable. Dahil ang object code ng lahat ng ito ay nag-imbak lamang ng isang pare-pareho sa memorya, ang paglipat ng gawain bilang resulta ng pagpapatupad nito ay lubhang hindi malamang. Pangunahing pinaghihinalaan namin ang mga expression na maaaring lumipat sa gawain, dahil ang pagharang ay naganap sa pagpapatupad sa halip na bumalik kapag ibinalik ang gawain pabalik (sa ilang mga kadahilanan).
Ang gawain sa pagsubaybay ay tumakbo lamang sa isang loop at pana-panahong sinusuri upang makita kung ang halaga ng pandaigdigang variable ay nagbago. Sa bawat pagbabago, ang halaga ay na-save sa isang file. Pagkatapos ay isang maikling paghihintay at isang bagong tseke. Isinulat ko ang variable sa file dahil ang gawain ay naisakatuparan lamang kapag pinili ito ng system para sa pagpapatupad kapag inililipat ang gawain sa lugar ng problema. Anuman ang nangyari sa gawaing ito ay hindi makakaapekto sa iba, hindi nauugnay na mga naka-block na gawain.
Inaasahan na kapag naabot ng system ang punto ng pagpapatupad ng problemang code, ang global variable ay ire-reset kapag lumipat sa bawat susunod na expression. Pagkatapos ay may mangyayari na nagiging sanhi ng paglipat ng gawain, at dahil ang dalas ng pagpapatupad nito (10 Hz) ay mas mababa kaysa sa gawain sa pagsubaybay, maaaring makuha ng monitor ang halaga ng global variable at isulat ito. Sa isang normal na sitwasyon, maaari akong makakuha ng paulit-ulit na pagkakasunud-sunod ng isang subset ng mga enumerasyon: ang mga huling halaga ng variable sa oras ng paglipat ng gawain. Kapag nakabitin, hindi na dapat magbago ang global variable, at ang huling value na nakasulat ay magsasaad kung aling expression ang hindi nakumpleto.
Pinatakbo ko ang code na may pagsubaybay. Nanlamig siya. At ang pagsubaybay ay gumana tulad ng orasan.
Ang log ay naglalaman ng inaasahang pagkakasunud-sunod, na naantala ng isang halaga na nagpapahiwatig na ang isang mutex ay tinawag Unlock, at ang gawain ay hindi nakumpleto - tulad ng kaso sa libu-libong nakaraang mga tawag.
Lagnat na sinusuri ng mga inhinyero ng Apex ang kanilang code sa oras na ito at nakahanap ng lugar sa mutex kung saan, ayon sa teorya, maaaring magkaroon ng lock. Ngunit ang posibilidad nito ay napakababa, dahil ang isang tiyak na pagkakasunud-sunod ng mga kaganapan na nagaganap sa isang tiyak na oras ay maaaring humantong sa pagharang. Murphy's Law, guys, ito ay Murphy's Law.
Upang protektahan ang piraso ng code na kailangan ko, pinalitan ko ang mga mutex function na tawag (na binuo sa ibabaw ng OS mutex functionality) ng isang maliit na native na Ada mutex package para makontrol ang mutex access sa pirasong iyon.
Ipinasok ko ito sa code at pinatakbo ang pagsubok. Makalipas ang pitong oras gumagana pa rin ang code.
Ang aking code ay isinumite sa Rational, kung saan nila ito pinagsama-sama, binuwag ito, at sinuri na hindi ito gumamit ng parehong diskarte na ginamit sa may problemang mutex function.
Ito ang pinakamasikip na pagsusuri ng code sa aking karera π May humigit-kumulang sampung inhinyero at tagapamahala sa silid na kasama ko, isa pang sampung tao ang nasa isang conference call - at lahat sila ay nagsuri ng humigit-kumulang 20 linya ng code.
Ang code ay nasuri, ang mga bagong executable na file ay binuo at isinumite para sa pormal na pagsusuri ng regression. Makalipas ang ilang linggo, matagumpay ang countdown test at nag-take off ang rocket.
Okay, lahat ng iyon ay mabuti at mabuti, ngunit ano ang punto ng kuwento?
Ito ay isang ganap na kasuklam-suklam na problema. Daan-daang libong linya ng code, parallel execution, mahigit isang dosenang mga prosesong nakikipag-ugnayan, hindi magandang arkitektura at hindi magandang pagpapatupad, mga interface para sa mga naka-embed na system at milyun-milyong dolyar na ginastos. Walang pressure, tama.
Hindi lang ako ang gumagawa sa problemang ito, bagama't nasa spotlight ako habang ginagawa ko ang porting. Ngunit kahit na ginawa ko ito, hindi iyon nangangahulugan na naunawaan ko ang lahat ng daan-daang libong linya ng code, o kahit na sinagap ang mga ito. Ang code at mga log ay sinuri ng mga inhinyero sa buong bansa, ngunit nang sabihin nila sa akin ang kanilang mga hypotheses tungkol sa mga sanhi ng pagkabigo, tumagal lang ako ng kalahating minuto upang pabulaanan ang mga ito. At kapag hiniling sa akin na mag-analyze ng mga teorya, ipapasa ko ito sa iba, dahil halata sa akin na mali ang landas ng mga inhinyero na ito. Tunog mapangahas? Oo, totoo ito, ngunit tinanggihan ko ang mga hypotheses at kahilingan para sa isa pang dahilan.
Naunawaan ko ang kalikasan ng problema. Hindi ko alam kung saan ito nangyayari o bakit, ngunit alam ko kung ano ang nangyayari.
Sa paglipas ng mga taon, marami akong naipon na kaalaman at karanasan. Isa ako sa mga pioneer ng paggamit ng Ada at naunawaan ang mga pakinabang at disadvantage nito. Alam ko kung paano pinangangasiwaan ng mga library ng Ada runtime ang mga gawain at nakikitungo sa parallel execution. At naiintindihan ko ang mababang antas ng programming sa antas ng memorya, mga rehistro at assembler. Sa madaling salita, mayroon akong malalim na kaalaman sa aking larangan. At ginamit ko sila para hanapin ang dahilan ng problema. Hindi ko lang inayos ang bug, naunawaan ko kung paano hanapin ito sa isang napakasensitibong runtime na kapaligiran.
Ang ganitong mga kwento ng pakikibaka sa code ay hindi masyadong kawili-wili para sa mga hindi pamilyar sa mga tampok at kondisyon ng naturang pakikibaka. Ngunit ang mga kuwentong ito ay tumutulong sa amin na maunawaan kung ano ang kinakailangan upang malutas ang talagang mahihirap na problema.
Upang malutas ang talagang mahihirap na problema, kailangan mong maging higit pa sa isang programmer. Kailangan mong maunawaan ang "kapalaran" ng code, kung paano ito nakikipag-ugnayan sa kapaligiran nito, at kung paano gumagana ang kapaligiran mismo.
At pagkatapos ay magkakaroon ka ng sarili mong nasirang holiday week.
Upang magpatuloy.
Pinagmulan: www.habr.com