Cosmic Rays: ความน่าจะเป็นที่พวกเขาจะมีผลต่อโปรแกรมคืออะไร?

อีกครั้งที่ฉันอยู่ในการทบทวนการออกแบบและพบว่ามีความน่าจะเป็นของบางสถานการณ์คือ "น้อยกว่าความเสี่ยงของรังสีคอสมิก" ที่มีผลต่อโปรแกรมและมันเกิดขึ้นกับฉันว่าฉันไม่ได้มีความคิดที่ลึกซึ้งที่สุด ความน่าจะเป็นคือ

"ตั้งแต่ 2 ^-128คือ 1 จาก 340282366920938463463374607431768211456 ฉันคิดว่าเราเป็นธรรมในการใช้โอกาสของเราที่นี่แม้ว่าการคำนวณเหล่านี้จะถูกปิดด้วยปัจจัยไม่กี่พันล้าน ... เรามีความเสี่ยงมากสำหรับรังสีคอสมิก เชื่อเรา

โปรแกรมเมอร์นี้ถูกต้องหรือไม่? ความน่าจะเป็นที่รังสีคอสมิคชนกับคอมพิวเตอร์และมีผลกระทบต่อการทำงานของโปรแกรมอย่างไร

จากWikipedia :

การศึกษาโดย IBM ในปี 1990 แนะนำว่าโดยทั่วไปแล้วคอมพิวเตอร์จะมีข้อผิดพลาดเกี่ยวกับคอสมิค - เรย์ที่เกิดจากข้อผิดพลาดต่อ RAM ขนาด 256 เมกะไบต์ต่อเดือน ^[15]

นี่หมายถึงความน่าจะเป็น 3.7 × 10 ^-9ต่อไบต์ต่อเดือนหรือ 1.4 × 10 ^-15ต่อไบต์ต่อวินาที หากโปรแกรมของคุณทำงานเป็นเวลา 1 นาทีและมี RAM ขนาด 20 MB แสดงว่ามีโอกาสเกิดความล้มเหลวได้

                 60 × 20 × 1024²
1 - (1 - 1.4e-15)                = 1.8e-6 a.k.a. "5 nines"

การตรวจสอบข้อผิดพลาดสามารถช่วยลดผลพวงจากความล้มเหลวได้ นอกจากนี้เนื่องจากชิปมีขนาดกะทัดรัดมากขึ้นตามที่แสดงความคิดเห็นโดย Joe อัตราความล้มเหลวอาจแตกต่างจากเมื่อ 20 ปีก่อน

เห็นได้ชัดว่าไม่สำคัญ จากบทความนักวิทยาศาสตร์ใหม่ใบเสนอราคาจากคำขอรับสิทธิบัตรของ Intel

"การล่มของคอมพิวเตอร์ Cosmic ray เกิดขึ้นและคาดว่าจะเพิ่มขึ้นตามความถี่ในขณะที่อุปกรณ์ (ตัวอย่างเช่นทรานซิสเตอร์) ลดขนาดในชิปปัญหานี้คาดว่าจะกลายเป็นข้อ จำกัด ที่สำคัญของความน่าเชื่อถือของคอมพิวเตอร์ในทศวรรษหน้า"

คุณสามารถอ่านสิทธิบัตรเต็มได้ที่นี่

หมายเหตุ: คำตอบนี้ไม่เกี่ยวกับฟิสิกส์ แต่เกี่ยวกับข้อผิดพลาดของหน่วยความจำเงียบด้วยโมดูลหน่วยความจำที่ไม่ใช่ ECC ข้อผิดพลาดบางอย่างอาจมาจากพื้นที่รอบนอกและบางส่วน - จากพื้นที่ด้านในของเดสก์ท็อป

มีการศึกษาหลายครั้งเกี่ยวกับความล้มเหลวของหน่วยความจำ ECC ในเซิร์ฟเวอร์ฟาร์มขนาดใหญ่เช่น CERN clusters และ Google datacenters ฮาร์ดแวร์ระดับเซิร์ฟเวอร์ที่มี ECC สามารถตรวจจับและแก้ไขข้อผิดพลาดบิตเดียวทั้งหมดและตรวจสอบข้อผิดพลาดหลายบิตจำนวนมาก

เราสามารถสรุปได้ว่ามีเดสก์ท็อปที่ไม่ใช่ ECC จำนวนมาก (และสมาร์ทโฟนมือถือที่ไม่ใช่ ECC) หากเราตรวจสอบเอกสารสำหรับอัตราความผิดพลาดที่แก้ไขได้ ECC (บิตเดียว) เราสามารถทราบอัตราความเสียหายของหน่วยความจำที่เงียบในหน่วยความจำที่ไม่ใช่ ECC

• การศึกษาขนาดใหญ่ของ CERN 2007 "Data integrity" : ผู้จำหน่ายประกาศว่า " Bit Error Rate 10 ^-12 สำหรับโมดูลหน่วยความจำ ", " อัตราความผิดพลาดที่สังเกตได้คือ 4 ออเดอร์ที่มีขนาดต่ำกว่าที่คาด " สำหรับงานที่ต้องใช้ข้อมูลมาก (8 GB / s ของการอ่านหน่วยความจำ) หมายความว่าการพลิกบิตเดียวอาจเกิดขึ้นทุก ๆ นาที ( ผู้ขาย10 ^-12 BER) หรือหนึ่งครั้งในสองวัน ( ^10-16 BER)

• บทความ 2009 ของ Google "ข้อผิดพลาด DRAM ในป่า: การศึกษาภาคสนามขนาดใหญ่"กล่าวว่าสามารถมี FIT หนึ่งบิตต่อ 25,000-75000 บิตต่อ Mbit ( ความล้มเหลวในเวลาต่อพันล้านชั่วโมง ) ซึ่งเท่ากับ 1 - 5 บิต ข้อผิดพลาดต่อชั่วโมงสำหรับ RAM 8GB หลังจากการคำนวณของฉัน Paper กล่าวเช่นเดียวกัน: " หมายถึงอัตราข้อผิดพลาดที่แก้ไขได้ของ 2000–6000 ต่อ GB ต่อปี "

• รายงาน Sandia ประจำปี 2555 "การตรวจจับและแก้ไขความผิดพลาดของข้อมูลเงียบสำหรับคอมพิวเตอร์ขนาดใหญ่ที่มีประสิทธิภาพสูง" : "การพลิกบิตสองเท่าถือว่าไม่น่าเป็นไปได้" แต่ที่ Cray XT5 หนาแน่นของ ORNL "ในอัตราหนึ่งต่อวันสำหรับ 75,000+ DIMMs" กับ ECC และข้อผิดพลาดบิตเดียวควรจะสูงกว่า

ดังนั้นหากโปรแกรมมีชุดข้อมูลขนาดใหญ่ (หลาย GB) หรือมีอัตราการอ่านหรือการเขียนหน่วยความจำสูง (GB / s หรือมากกว่า) และทำงานเป็นเวลาหลายชั่วโมงเราสามารถคาดหวังได้ถึงบิตเงียบเงียบ ๆ บนฮาร์ดแวร์เดสก์ท็อป อัตรานี้ไม่สามารถตรวจพบได้โดย memtest และโมดูล DRAM นั้นดี

คลัสเตอร์แบบยาวที่ทำงานบนพีซีที่ไม่ใช่ ECC หลายพันเครื่องเช่นการคำนวณแบบกริดทั้งเครือข่ายอินเทอร์เน็ตของ BOINC จะมีข้อผิดพลาดจากบิตการพลิกหน่วยความจำและจากข้อผิดพลาดแบบเงียบของดิสก์และเครือข่าย

และสำหรับเครื่องที่มีขนาดใหญ่กว่า (เซิร์ฟเวอร์นับหมื่น) แม้จะมีการป้องกัน ECC จากข้อผิดพลาดแบบบิตเดียวดังที่เราเห็นในรายงานปี 2012 ของ Sandia อาจมีการเปิดสองครั้งทุกวันดังนั้นคุณจะไม่มีโอกาสทำงานขนาดเต็มขนาน โปรแกรมเป็นเวลาหลายวัน (ไม่มีจุดตรวจปกติและเริ่มต้นใหม่จากจุดตรวจสอบที่ดีในกรณีที่ข้อผิดพลาดสองครั้ง) เครื่องจักรขนาดใหญ่จะได้รับบิตพลิกในแคชและการลงทะเบียน cpu ของพวกเขา (ทริกเกอร์ทั้งสถาปัตยกรรมและภายในเช่นใน ALU datapath) เพราะไม่ใช่ทั้งหมดได้รับการคุ้มครองโดย ECC

PS: ทุกอย่างจะเลวร้ายยิ่งกว่าถ้าโมดูล DRAM ไม่ดี ตัวอย่างเช่นฉันติดตั้ง DRAM ใหม่ลงในแล็ปท็อปซึ่งเสียชีวิตไปหลายสัปดาห์ต่อมา มันเริ่มให้ข้อผิดพลาดของหน่วยความจำมากมาย สิ่งที่ฉันได้รับ: แล็ปท็อปแฮงค์รีบูต linux รัน fsck ค้นหาข้อผิดพลาดในระบบไฟล์รูทและบอกว่าต้องการรีบูตหลังจากแก้ไขข้อผิดพลาด แต่ทุกครั้งที่ทำการรีบูทครั้งต่อไป (ฉันทำประมาณ 5-6 ตัว) ยังมีข้อผิดพลาดที่พบในระบบไฟล์รูท

Wikipediaอ้างถึงการศึกษาโดย IBMใน 90s แนะนำว่า "โดยทั่วไปแล้วคอมพิวเตอร์จะพบกับข้อผิดพลาดที่เกิดจากรังสีคอสมิกหนึ่งตัวต่อ 256 เมกะไบต์ของ RAM ต่อเดือน" น่าเสียดายที่การอ้างถึงเป็นบทความใน Scientific American ซึ่งไม่ได้ให้การอ้างอิงเพิ่มเติมใด ๆ โดยส่วนตัวแล้วฉันพบว่าตัวเลขนั้นสูงมาก แต่บางทีข้อผิดพลาดของหน่วยความจำส่วนใหญ่ที่เกิดจากรังสีคอสมิกไม่ก่อให้เกิดปัญหาจริงหรือสังเกตเห็นได้

ในทางกลับกันคนที่พูดถึงความน่าจะเป็นเมื่อพูดถึงสถานการณ์ซอฟต์แวร์โดยทั่วไปจะไม่มีเงื่อนงำอะไรที่พวกเขาพูดถึง

เห็นได้ชัดว่ารังสีคอสมิกทำให้อุปกรณ์อิเล็กทรอนิกส์ในรถยนต์โตโยต้าผิดปกติดังนั้นฉันจะบอกว่าความน่าจะเป็นนั้นสูงมาก :)

รังสีคอสมิคทำให้โตโยต้าเศร้าโศกจริงๆหรือ?

ด้วย ECC คุณสามารถแก้ไขข้อผิดพลาด 1 บิตของ Cosmic Rays เพื่อหลีกเลี่ยง 10% ของกรณีที่รังสีคอสมิคส่งผลให้เกิดข้อผิดพลาดแบบ 2 บิตเซลล์ ECC มักจะมีการแทรกข้ามชิปดังนั้นจึงไม่มีเซลล์สองเซลล์ติดกัน เหตุการณ์รังสีคอสมิกที่มีผลต่อเซลล์สองเซลล์จะส่งผลให้เกิดข้อผิดพลาด 1 บิตที่แก้ไขได้สองข้อ

รัฐอาทิตย์: (หมายเลข 816-5053-10 เมษายน 2545)

โดยทั่วไปแล้วข้อผิดพลาด soft cosmic ray เกิดขึ้นในหน่วยความจำ DRAM ในอัตรา ~ 10 ถึง 100 FIT / MB (1 FIT = 1 อุปกรณ์ล้มเหลวใน 1 พันล้านชั่วโมง) ดังนั้นระบบที่มีหน่วยความจำ 10 GB ควรแสดงเหตุการณ์ ECC ทุกๆ 1,000 ถึง 10,000 ชั่วโมงและระบบที่มี 100 GB จะแสดงเหตุการณ์ทุกๆ 100 ถึง 1,000 ชั่วโมง อย่างไรก็ตามนี่เป็นการประมาณคร่าวๆที่จะเปลี่ยนเมื่อฟังก์ชั่นของเอฟเฟกต์ที่ระบุไว้ข้างต้น

ข้อผิดพลาดของหน่วยความจำเป็นจริงและหน่วยความจำ ECC ช่วย หน่วยความจำ ECC ดำเนินการอย่างถูกต้องจะแก้ไขข้อผิดพลาดบิตเดียวและตรวจสอบข้อผิดพลาดบิตคู่ (ลังเลระบบถ้าเช่นข้อผิดพลาดในการตรวจพบ.) คุณสามารถดูจากวิธีการอย่างสม่ำเสมอคนบ่นเกี่ยวกับสิ่งที่ดูเหมือนจะเป็นปัญหาซอฟต์แวร์ที่ได้รับการแก้ไขโดยการเรียกใช้Memtest86และ ค้นพบความทรงจำที่ไม่ดี แน่นอนความล้มเหลวชั่วคราวที่เกิดจากรังสีคอสมิกนั้นแตกต่างจากหน่วยความจำที่ล้มเหลวอย่างต่อเนื่อง แต่มันเกี่ยวข้องกับคำถามที่กว้างขึ้นว่าคุณควรไว้วางใจหน่วยความจำของคุณให้ทำงานอย่างถูกต้องหรือไม่

การวิเคราะห์โดยใช้ขนาดที่พำนัก 20 MB อาจเหมาะสำหรับแอพพลิเคชั่นเล็กน้อย แต่ระบบขนาดใหญ่มักมีเซิร์ฟเวอร์หลายเครื่องที่มีหน่วยความจำหลักขนาดใหญ่เป็นประจำ

ลิงค์ที่น่าสนใจ: http://cr.yp.to/hardware/ecc.html

ลิงก์ Corsair ในหน้าเว็บน่าเสียดายที่ดูเหมือนว่าจะตาย

นี่เป็นปัญหาจริงและนั่นคือสาเหตุที่หน่วยความจำ ECC ถูกใช้ในเซิร์ฟเวอร์และระบบฝังตัว และทำไมระบบการบินจึงแตกต่างจากระบบภาคพื้นดิน

ตัวอย่างเช่นโปรดทราบว่าชิ้นส่วนของ Intel ที่กำหนดไว้สำหรับการใช้งาน "ฝังตัว" มักจะเพิ่ม ECC ไปยังแผ่นข้อมูลจำเพาะ Bay Trail สำหรับแท็บเล็ตขาดเนื่องจากจะทำให้หน่วยความจำมีราคาแพงขึ้นเล็กน้อยและอาจช้ากว่า และหากแท็บเล็ตขัดข้องโปรแกรมทุกครั้งในดวงจันทร์สีน้ำเงินผู้ใช้จะไม่สนใจมาก ตัวซอฟต์แวร์เองนั้นมีความน่าเชื่อถือน้อยกว่า HW อยู่ดี แต่สำหรับ SKU ที่มีไว้สำหรับใช้ในเครื่องจักรอุตสาหกรรมและยานยนต์ ECC เป็นสิ่งจำเป็น เนื่องจากที่นี่เราคาดหวังว่า SW จะเชื่อถือได้มากขึ้นและข้อผิดพลาดจากการสุ่มอัปเดตจะเป็นปัญหาที่แท้จริง

ระบบที่ได้รับการรับรองมาตรฐาน IEC 61508 และมาตรฐานที่คล้ายคลึงกันมักจะมีการทดสอบการบู๊ตที่ตรวจสอบว่า RAM ทั้งหมดทำงานได้ (ไม่มีบิตติดอยู่ที่ศูนย์หรือหนึ่ง) รวมถึงการจัดการข้อผิดพลาดที่รันไทม์ที่พยายามกู้คืนจากข้อผิดพลาดที่ตรวจพบโดย ECC และ บ่อยครั้งที่หน่วยความจำเครื่องขัดถูที่ทำหน้าที่อ่านและเขียนหน่วยความจำอย่างต่อเนื่องเพื่อให้แน่ใจว่ามีข้อผิดพลาดเกิดขึ้น

แต่สำหรับซอฟต์แวร์พีซีหลัก? ไม่ใช่เรื่องใหญ่. สำหรับเซิร์ฟเวอร์ที่มีอายุการใช้งานนาน ใช้ ECC และตัวจัดการความผิด หากข้อผิดพลาดที่แก้ไขไม่ได้ฆ่าเคอร์เนลดังนั้นไม่ว่าจะเป็น หรือคุณจะหวาดระแวงและใช้ระบบสำรองที่มีการดำเนินการล็อคขั้นตอนเพื่อที่ว่าหากแกนประมวลผลอันใดอันหนึ่งเสียหายแกนอีกอันก็สามารถเข้ามาแทนที่แกนหลักอันแรกได้

หากโปรแกรมมีความสำคัญต่อชีวิต (โปรแกรมนี้จะฆ่าผู้อื่นหากล้มเหลว) จะต้องมีการเขียนโปรแกรมในลักษณะที่จะทำให้ระบบไม่ปลอดภัยหรือกู้คืนโดยอัตโนมัติจากความล้มเหลวดังกล่าว โปรแกรมอื่น ๆ ทั้งหมด YMMV

Toyotas เป็นจุดในกรณี พูดในสิ่งที่คุณต้องการเกี่ยวกับสายคันเร่ง แต่ไม่ใช่ซอฟต์แวร์

ดูเพิ่มเติมที่http://en.wikipedia.org/wiki/Therac-25

ฉันเคยตั้งโปรแกรมอุปกรณ์ที่จะบินไปในอวกาศและจากนั้นคุณ (สมมุติไม่มีใครเคยแสดงให้ฉันเห็นกระดาษเกี่ยวกับเรื่องนี้ แต่มันบอกว่าเป็นความรู้ทั่วไปในธุรกิจ) อาจคาดหวังว่ารังสีคอสมิกจะทำให้เกิดข้อผิดพลาดตลอดเวลา

"เหตุการณ์คอสมิคเรย์" ได้รับการพิจารณาว่ามีการแจกแจงที่เหมือนกันในหลายคำตอบที่นี่สิ่งนี้อาจไม่เป็นจริงเสมอไป (เช่นซุปเปอร์โนวา) ถึงแม้ว่า "รังสีคอสมิก" ตามคำจำกัดความ (อย่างน้อยตามวิกิพีเดีย) มาจากนอกโลกฉันคิดว่ามันยุติธรรมที่จะรวมพายุสุริยะในพื้นที่ (อาคาออกมาเป็นหมู่มวลโคโรนาภายใต้ร่มเดียวกันฉันเชื่อว่ามันอาจทำให้หลาย ๆ ช่วงเวลาสั้น ๆ อาจเพียงพอที่จะทำให้เสียหายแม้หน่วยความจำที่เปิดใช้งาน ECC

เป็นที่ทราบกันดีว่าพายุสุริยะนั้นอาจทำให้ระบบไฟฟ้าเสียหาย (เช่นไฟฟ้าดับในควิเบกในเดือนมีนาคม 1989 ) อาจเป็นไปได้ว่าระบบคอมพิวเตอร์อาจได้รับผลกระทบ

ประมาณ 10 ปีก่อนฉันนั่งถัดจากคนอื่นเรานั่งอยู่กับแล็ปท็อปแต่ละเครื่องในช่วงเวลาที่มีสภาพอากาศสุริยะ "พายุ" (นั่งอยู่ในอาร์กติกเราสามารถสังเกตได้ทางอ้อม - ออโรร่า borealis จำนวนมาก จะเห็น) ทันใดนั้น - ในทันทีเดียวกัน - แล็ปท็อปของเราทั้งสองล้มเหลว เขาใช้ OS X และฉันใช้งาน Linux พวกเราทั้งคู่ไม่เคยชินกับแล็ปท็อปที่หยุดทำงาน - เป็นสิ่งที่ค่อนข้างหายากบน Linux และ OS X ข้อผิดพลาดทั่วไปของซอฟต์แวร์สามารถตัดออกได้มากหรือน้อยเนื่องจากเราใช้ระบบปฏิบัติการที่แตกต่างกัน (และไม่เกิดขึ้นระหว่างการกระโดด วินาที) ฉันมาที่เหตุการณ์นี้เพื่อ "รังสีคอสมิก"

ต่อมา "รังสีคอสมิก" ได้กลายเป็นเรื่องตลกภายในที่ทำงานของฉัน เมื่อใดก็ตามที่มีสิ่งใดเกิดขึ้นกับเซิร์ฟเวอร์ของเราและเราไม่สามารถหาคำอธิบายใด ๆ ได้เราจะกล่าวอ้างถึงความผิดของ "รังสีคอสมิค" :-)

บ่อยครั้งที่สัญญาณรบกวนอาจทำให้ข้อมูลเสียหายได้ Checksumsใช้ในการต่อสู้ในหลายระดับ ในสายเคเบิลข้อมูลโดยทั่วไปจะมีบิตพาริตี้ที่เดินทางไปพร้อมกับข้อมูล สิ่งนี้ช่วยลดความน่าจะเป็นของการทุจริตได้อย่างมาก จากนั้นในระดับการแยกวิเคราะห์ข้อมูลไร้สาระมักจะถูกละเว้นดังนั้นแม้ว่าความเสียหายบางอย่างจะผ่านบิตพาริตีหรือเช็คซัมอื่น ๆ ในกรณีส่วนใหญ่ก็จะถูกละเว้น

นอกจากนี้ส่วนประกอบบางส่วนได้รับการป้องกันด้วยไฟฟ้าเพื่อป้องกันเสียงรบกวน (อาจไม่ใช่รังสีคอสมิคที่ฉันเดา)

แต่ท้ายที่สุดอย่างที่ผู้ตอบคำถามคนอื่น ๆ บอกไว้มีบิตหรือไบต์เป็นครั้งคราวที่มีสัญญาณรบกวนและมันก็เหลือที่จะมีโอกาสไม่ว่าจะเป็นไบต์ที่สำคัญหรือไม่ กรณีของกรณีที่ดีที่สุดรังสีคอสมิกจะแย่งชิงหนึ่งในบิตที่ว่างเปล่าและไม่มีผลกระทบใด ๆ หรือเกิดปัญหากับคอมพิวเตอร์ (นี่เป็นสิ่งที่ดี แต่กรณีที่เลวร้ายที่สุดดีฉันแน่ใจว่าคุณสามารถจินตนาการ

ฉันได้รับประสบการณ์นี้ - มันไม่ได้ยากสำหรับรังสีคอสมิกที่จะพลิกหนึ่งบิต แต่ก็ไม่น่าเป็นไปได้มากที่คนจะสังเกตเห็นสิ่งนี้

ฉันกำลังทำงานกับเครื่องมือบีบอัดสำหรับตัวติดตั้งในปี 2547 ข้อมูลทดสอบของฉันคือไฟล์การติดตั้ง Adobe บางไฟล์ที่มีขนาดประมาณ 500 MB หรือมากกว่านั้นถูกแตกไฟล์

หลังจากการบีบอัดที่น่าเบื่อและการคลายการบีบอัดเพื่อทดสอบความสมบูรณ์ FC / B แสดงให้เห็นว่าไบต์หนึ่งแตกต่างกัน

ภายในหนึ่งไบต์ MSB ก็พลิกกลับ ฉันพลิกตัวด้วยเช่นกันกังวลว่าฉันมีข้อผิดพลาดบ้า ๆ ที่จะปรากฏภายใต้เงื่อนไขที่เฉพาะเจาะจงมาก - ฉันไม่รู้ด้วยซ้ำว่าจะเริ่มมองหาที่ไหน

แต่มีบางอย่างบอกให้ฉันทำการทดสอบอีกครั้ง ฉันวิ่งแล้วก็ผ่านไป ฉันตั้งค่าสคริปต์เพื่อให้ทดสอบ 5 ครั้งข้ามคืน ในตอนเช้าทั้ง 5 คนผ่านไปแล้ว

นั่นคือการบิตของรังสีคอสมิกแน่นอน

คุณอาจต้องการดูฮาร์ดแวร์ Fault Tolerant เช่นกัน

ตัวอย่างเช่น Stratus Technology สร้างเซิร์ฟเวอร์ Wintel ที่เรียกว่า ftServer ซึ่งมี 2 หรือ 3 "เมนบอร์ด" ในขั้นตอนล็อคการเปรียบเทียบผลลัพธ์ของการคำนวณ (สิ่งนี้สามารถทำได้ในยานอวกาศด้วย)

เซิร์ฟเวอร์ Stratus วิวัฒนาการมาจากชิปเซ็ตที่กำหนดเองเพื่อล็อคขั้นตอนที่ backplane

ระบบที่คล้ายกันมาก (แต่ซอฟต์แวร์) คือล็อค VMWare Fault Tolerance ตาม Hypervisor

ในฐานะที่เป็นจุดข้อมูลสิ่งนี้เกิดขึ้นกับงานสร้างของเรา:

02:13:00,465 WARN  - In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/ostream:133:
02:13:00,465 WARN  - /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/locale:3180:65: error: use of undeclared identifier '_'
02:13:00,465 WARN  - for (unsigned __i = 1; __i < __trailing_sign->size(); ++_^i, ++__b)
02:13:00,465 WARN  - ^
02:13:00,465 WARN  - /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/locale:3180:67: error: use of undeclared identifier 'i'
02:13:00,465 WARN  - for (unsigned __i = 1; __i < __trailing_sign->size(); ++_^i, ++__b)
02:13:00,465 WARN  - ^

ซึ่งดูเหมือนว่าจะเกิดการพลิกขึ้นเล็กน้อยระหว่างการคอมไพล์ในสถานที่ที่สำคัญมากในไฟล์ต้นฉบับโดยบังเอิญ

ฉันไม่จำเป็นต้องบอกว่านี่คือ "รังสีคอสมิก" แต่อาการตรงกับ