פולקלור של מתכנתים ומהנדסים (חלק 1)

זהו מבחר של סיפורים מהאינטרנט על איך לבאגים יש לפעמים ביטויים מדהימים לחלוטין. אולי גם לך יש מה לספר.

אלרגיה לרכב לגלידת וניל

סיפור למהנדסים שמבינים שהברור מאליו הוא לא תמיד התשובה, ושלא משנה כמה העובדות עשויות להיראות מופרכות, הן עדיין העובדות. חטיבת פונטיאק של חברת ג'נרל מוטורס קיבלה תלונה:

זו הפעם השנייה שאני כותב לך, ואני לא מאשים אותך שלא ענית, כי זה נשמע מטורף. למשפחה שלנו יש מסורת לאכול גלידה כל ערב אחרי ארוחת הערב. סוגי הגלידה מתחלפים כל פעם ואחרי ארוחת הערב כל המשפחה בוחרת איזו גלידה לקנות ולאחר מכן אני הולכת לחנות. קניתי לאחרונה פונטיאק חדש ומאז הנסיעות שלי להשיג גלידה הפכו לבעיה. אתה מבין, בכל פעם שאני קונה גלידת וניל וחוזר מהחנות, האוטו לא מתניע. אם אני מביא גלידה אחרת, האוטו מתניע בלי שום בעיה. אני רוצה לשאול שאלה רצינית, לא משנה כמה טיפשי זה נשמע: "מה יש בפונטיאק שגורם לזה שהוא לא מתחיל כשאני מביא גלידת וניל, אלא מתחיל בקלות כשאני מביא עוד טעם של גלידה?"

כפי שאתה יכול לדמיין, נשיא החטיבה היה סקפטי לגבי המכתב. עם זאת, ליתר בטחון, שלחתי מהנדס לבדוק. הוא הופתע מכך שפגש אותו אדם אמיד ומשכיל המתגורר באזור יפהפה. הם הסכימו להיפגש מיד לאחר ארוחת הערב כדי שהשניים יוכלו ללכת לחנות לגלידה. באותו ערב זה היה וניל, וכשהם חזרו למכונית, הוא לא התניע.

המהנדס הגיע עוד שלושה ערבים. הפעם הראשונה שהגלידה הייתה שוקולד. המכונית התניעה. בפעם השנייה הייתה גלידת תותים. המכונית התניעה. בערב השלישי ביקש לקחת וניל. המכונית לא התניעה.

בהיגיון רציונלי, המהנדס סירב להאמין שהמכונית אלרגית לגלידת וניל. לכן סיכמתי עם בעל הרכב שימשיך בביקוריו עד שימצא פתרון לבעיה. ובדרך הוא התחיל לרשום: הוא רשם את כל המידע, שעה ביום, סוג הבנזין, שעת הגעה והחזרה מהחנות וכו'.

המהנדס הבין עד מהרה שבעל המכונית השקיע פחות זמן בקניית גלידת וניל. הסיבה הייתה פריסת הסחורה בחנות. גלידת וניל הייתה הפופולרית ביותר ונשמרה במקפיא נפרד בחזית החנות כדי להקל על מציאתה. וכל שאר הזנים היו בחלק האחורי של החנות, ולקח הרבה יותר זמן למצוא את המגוון הנכון ולשלם.

כעת השאלה הייתה למהנדס: מדוע המכונית לא התניעה אם חלף פחות זמן מרגע כיבוי המנוע? מכיוון שהבעיה הייתה בזמן ולא בגלידת וניל, המהנדס מצא במהירות את התשובה: זה היה מנעול גז. זה התרחש מדי ערב, אבל כשבעל הרכב בילה יותר זמן בחיפוש אחר גלידה, המנוע הצליח להתקרר מספיק והתניע בקלות. וכשהאיש קנה גלידת וניל, המנוע עדיין היה חם מדי ומנעול הגז לא הספיק להתמוסס.

מוסרי: אפילו בעיות מטורפות לגמרי הן לפעמים אמיתיות.

קראש בנדיקוט

זה כואב לחוות את זה. בתור מתכנת אתה מתרגל להאשים את הקוד שלך ראשון, שני, שלישי... ואיפשהו במקום עשרת אלפים אתה מאשים את המהדר. ובהמשך הרשימה כבר מאשימים את הציוד.

הנה הסיפור שלי על באג החומרה.

למשחק Crash Bandicoot כתבתי קוד לטעינה ולשמירה בכרטיס זיכרון. עבור מפתח משחקים זחוח כזה, זה היה כמו טיול בפארק: חשבתי שהעבודה תיקח כמה ימים. עם זאת, בסופו של דבר ניפוי באגים בקוד במשך שישה שבועות. על הדרך פתרתי בעיות אחרות, אבל כל כמה ימים חזרתי לקוד הזה לכמה שעות. זה היה ייסורים.

הסימפטום נראה כך: כאשר אתה שומר את ההפעלה הנוכחית של המשחק וניגש לכרטיס הזיכרון, הכל כמעט תמיד הולך כשורה... אבל לפעמים פסקי הזמן של פעולת הקריאה או הכתיבה נפסקים ללא סיבה ברורה. הקלטה קצרה גורמת לרוב נזק לכרטיס הזיכרון. כששחקן מנסה להציל, הוא לא רק מצליח להציל, אלא גם הורס את המפה. שְׁטוּיוֹת.

לאחר זמן מה, המפיק שלנו בסוני, קוני באס, התחיל להיכנס לפאניקה. לא יכולנו לשלוח את המשחק עם הבאג הזה, ושישה שבועות לאחר מכן לא הבנתי מה גורם לבעיה. דרך קוני, יצרנו קשר עם מפתחי PS1 אחרים: האם מישהו נתקל במשהו דומה? לא. לאף אחד לא היו בעיות עם כרטיס הזיכרון.

כשאין לך רעיונות לניפוי באגים, הגישה היחידה שנותרה היא "הפרד ומשול": הסר עוד ועוד קוד מהתוכנית הפגומה עד שנשאר קטע קטן יחסית שעדיין גורם לבעיה. כלומר, אתה מנתק את התוכנית חלק אחר חלק עד שהחלק שמכיל את הבאג נשאר.

אבל העניין הוא שקשה מאוד לחתוך חלקים ממשחק וידאו. איך להפעיל את זה אם הסרת את הקוד שמחקה כוח משיכה? או לצייר דמויות?

לכן, עלינו להחליף מודולים שלמים בסטבים שמתיימרים לעשות משהו שימושי, אבל למעשה לעשות משהו מאוד פשוט שלא יכול להכיל שגיאות. אנחנו צריכים לכתוב קביים כאלה כדי שהמשחק לפחות יעבוד. זהו תהליך איטי וכואב.

בקיצור, עשיתי את זה. הסרתי עוד ועוד פיסות קוד עד שנשארתי עם הקוד הראשוני שמגדיר את המערכת להריץ את המשחק, מאתחל את חומרת העיבוד וכו'. כמובן, בשלב זה לא יכולתי ליצור תפריט שמירה וטעינה, כי אצטרך ליצור בדל עבור כל הקוד הגרפי. אבל יכולתי להעמיד פנים שאני משתמש המשתמש במסך השמירה והטעינה (הבלתי נראה) ולבקש לשמור ואז לכתוב לכרטיס הזיכרון.

זה השאיר אותי עם פיסת קוד קטנה שעדיין הייתה לה את הבעיה שלעיל - אבל זה עדיין קרה באקראי! לרוב הכל עבד בסדר, אבל מדי פעם היו תקלות. הסרתי כמעט את כל קוד המשחק, אבל הבאג עדיין חי. זה היה תמוה: הקוד שנותר למעשה לא עשה כלום.

בשלב מסוים, כנראה בסביבות שלוש לפנות בוקר, עלתה בי מחשבה. פעולות קריאה וכתיבה (קלט/פלט) כרוכות בזמני ביצוע מדויקים. כאשר אתה עובד עם כונן קשיח, כרטיס זיכרון או מודול בלוטות', הקוד ברמה נמוכה שאחראי על קריאה וכתיבה עושה זאת בהתאם לפולסי השעון.

בעזרת שעון, מכשיר שאינו מחובר ישירות למעבד מסונכרן עם הקוד המופעל על המעבד. השעון קובע את קצב הביאוד - המהירות שבה מועברים נתונים. אם יש בלבול עם תזמונים, אז גם החומרה או התוכנה, או שניהם, מבולבלים. וזה רע מאוד, כי הנתונים עלולים להינזק.

מה אם משהו בקוד שלנו מבלבל את התזמונים? בדקתי את כל מה שקשור לזה בקוד תוכנית הבדיקה ושמתי לב שהגדרנו את הטיימר הניתן לתכנות ב-PS1 ל-1 kHz (1000 טיקים לשנייה). זה די הרבה; כברירת מחדל, כשהקונסולה מתחילה, היא פועלת ב-100 הרץ. ורוב המשחקים משתמשים בתדר הזה.

אנדי, מפתח המשחק, קבע את הטיימר ל-1 kHz כדי שהתנועות יחושבו בצורה מדויקת יותר. אנדי נוטה להגזים, ואם אנו מחקים את כוח הכבידה, אנו עושים זאת בצורה מדויקת ככל האפשר!

אבל מה אם האצת הטיימר השפיעה איכשהו על התזמון הכללי של התוכנית, ולכן על השעון שמווסת את קצב ההחזרה של כרטיס הזיכרון?

הערתי את קוד הטיימר. השגיאה לא התרחשה שוב. אבל זה לא אומר שתיקנו את זה, כי הכשל התרחש באופן אקראי. מה אם רק היה לי מזל?

כמה ימים לאחר מכן התנסיתי שוב בתוכנית המבחן. הבאג לא חזר על עצמו. חזרתי לבסיס הקוד המלא של המשחק ושיניתי את קוד השמירה והטעינה כך שהטיימר הניתן לתכנות יתאפס לערך המקורי שלו (100Hz) לפני הגישה לכרטיס הזיכרון, ואז יתאפס בחזרה ל-1kHz. לא היו יותר קריסות.

אבל למה זה קרה?

חזרתי שוב לתוכנית המבחן. ניסיתי למצוא דפוס כלשהו בהתרחשות שגיאה עם טיימר של 1 קילו-הרץ. בסופו של דבר שמתי לב שהשגיאה מתרחשת כאשר מישהו משחק עם בקר PS1. מכיוון שרק לעתים רחוקות הייתי עושה זאת בעצמי - מדוע אצטרך בקר בעת בדיקת קוד שמירה וטעינה? - אפילו לא שמתי לב לתלות הזו. אבל יום אחד אחד האמנים שלנו חיכה שאסיים את הבדיקה - כנראה קיללתי באותו רגע - וסובב בעצבנות את הבקר בידיו. אירעה שגיאה. "רגע מה?!" ובכן, תעשה את זה שוב!"

כשהבנתי ששני האירועים האלה קשורים זה בזה, הצלחתי לשחזר בקלות את השגיאה: התחלתי להקליט לכרטיס הזיכרון, הזזתי את הבקר והרסתי את כרטיס הזיכרון. לי זה נראה כמו באג חומרה.

באתי לקוני וסיפרתי לה על הגילוי שלי. היא העבירה את המידע לאחד המהנדסים שתכנן את ה-PS1. "בלתי אפשרי," הוא ענה, "זו לא יכולה להיות בעיית חומרה." ביקשתי מקוני לארגן לנו שיחה.

המהנדס התקשר אליי והתווכחנו באנגלית השבורה שלו וביפנית השבורה שלי (הקיצונית). לבסוף אמרתי, "תן לי פשוט לשלוח את תוכנית הבדיקה של 30 השורות שלי שבה הזזת הבקר גורמת לבאג." הוא הסכים. אמר שזה בזבוז זמן ושהוא נורא עסוק בעבודה על פרויקט חדש, אבל ייכנע כי אנחנו מפתחים מאוד חשובים עבור סוני. ניקיתי את תוכנית המבחן שלי ושלחתי לו.

למחרת בערב (היינו בלוס אנג'לס והוא היה בטוקיו) הוא התקשר אליי והתנצל בבושה. זו הייתה בעיית חומרה.

אני לא יודע מה בדיוק היה הבאג, אבל ממה ששמעתי במטה סוני, אם הגדרתם את הטיימר לערך גבוה מספיק, זה הפריע לרכיבים בלוח האם בסביבת גביש הטיימר. אחד מהם היה בקר קצב העברת כרטיס הזיכרון, שגם קבע את קצב העברת הבקרים לבקרים. אני לא מהנדס, אז אולי פישלתי משהו.

אבל השורה התחתונה היא שהייתה הפרעה בין רכיבים בלוח האם. וכאשר משדרים נתונים בו-זמנית דרך יציאת הבקר ויציאת כרטיס הזיכרון עם טיימר הפועל ב-1 קילו-הרץ, ביטים אבדו, נתונים אבדו והכרטיס ניזוק.

פרות רעות

בשנות ה-1980, המנטור שלי סרגיי כתב תוכנה ל-SM-1800, שיבוט סובייטי של ה-PDP-11. המיקרו-מחשב הזה הותקן זה עתה בתחנת רכבת ליד סברדלובסק, מרכז תחבורה חשוב בברית המועצות. המערכת החדשה תוכננה לנתב עגלות ותנועת משא. אבל הוא הכיל באג מעצבן שהוביל לקריסות והתרסקויות אקראיות. נפילות תמיד התרחשו כשמישהו הלך הביתה בערב. אך למרות חקירה מעמיקה למחרת, המחשב פעל כשורה בכל הבדיקות הידניות והאוטומטיות. זה בדרך כלל מצביע על מצב מרוץ או באג תחרותי אחר שמתרחש בתנאים מסוימים. סרגיי, שמאס בשיחות מאוחרות בלילה, החליט לרדת לעומקו, וקודם כל להבין מה התנאים בחצר המסדרון שהובילו להתמוטטות המחשב.

ראשית, הוא אסף סטטיסטיקות של כל הנפילות הבלתי מוסברות ויצר גרף לפי תאריך ושעה. הדפוס היה ברור. לאחר התבוננות עוד כמה ימים, סרגיי הבין שהוא יכול בקלות לחזות את מועד תקלות המערכת העתידיות.

עד מהרה נודע לו ששיבושים התרחשו רק כאשר התחנה מיינה מטענים של בקר מצפון אוקראינה ומערב רוסיה לכיוון בית מטבחיים סמוך. זה כשלעצמו היה מוזר, כי לבית המטבחיים סיפקו חוות שנמצאות הרבה יותר קרוב, בקזחסטן.

תחנת הכוח הגרעינית בצ'רנוביל התפוצצה ב-1986, ונשורת רדיואקטיבית הפכה את האזורים שמסביב לבלתי ראויים למגורים. אזורים נרחבים בצפון אוקראינה, בלארוס ומערב רוסיה היו מזוהמים. בחשד לרמות גבוהות של קרינה בקרונות שהגיעו, פיתח סרגיי שיטה לבדיקת תיאוריה זו. נאסר על האוכלוסייה להחזיק במדדי דוסי, אז סרגיי רשם את עצמו עם כמה אנשי צבא בתחנת הרכבת. לאחר מספר משקאות וודקה, הוא הצליח לשכנע חייל למדוד את רמת הקרינה באחת הקרונות החשודים. התברר שהרמה הייתה גבוהה פי כמה מהערכים הרגילים.

לא רק שהבקר פלט קרינה רבה, רמתו הייתה כל כך גבוהה שהובילה לאובדן אקראי של ביטים בזיכרון של ה-SM-1800, שהיה ממוקם בבניין הסמוך לתחנה.

בברית המועצות היה מחסור במזון, והרשויות החליטו לערבב בשר צ'רנוביל עם בשר מאזורים אחרים במדינה. זה איפשר להפחית את הרמה הכוללת של הרדיואקטיביות מבלי לאבד משאבים יקרי ערך. לאחר שנודע על כך, מילא סרגיי מיד מסמכים להגירה. והתרסקות המחשב נעצרו מעצמן כאשר רמת הקרינה ירדה עם הזמן.

דרך הצינורות

פעם, Movietech Solutions יצרה תוכנה לבתי קולנוע, המיועדת להנהלת חשבונות, מכירת כרטיסים וניהול כללי. גרסת ה-DOS של אפליקציית הדגל הייתה פופולרית למדי בקרב רשתות בתי קולנוע קטנים ובינוניים בצפון אמריקה. אז זה לא מפתיע שכאשר הוכרזה גרסת Windows 95, משולבת במסכי המגע העדכניים ביותר ובקיוסקים בשירות עצמי, ומצוידת בכל מיני כלי דיווח, היא גם הפכה מהר מאוד לפופולרית. לרוב העדכון עבר ללא בעיות. צוות ה-IT המקומי התקין ציוד חדש, העביר נתונים והעסק נמשך. אלא כשזה לא נמשך. כשזה קרה, החברה הייתה שולחת את ג'יימס, שכונה "המנקה".

למרות שהכינוי מרמז על טיפוס מרושע, המנקה הוא רק שילוב של מדריך, מתקין וחובק-הכל. ג'יימס היה מבלה כמה ימים באתר הלקוח בחיבור כל הרכיבים, ואז מבלה עוד כמה ימים ללמד את הצוות כיצד להשתמש במערכת החדשה, לפתור בעיות חומרה שהתעוררו ולמעשה עוזר לתוכנה בחיתוליה.

לכן, אין זה מפתיע שבתקופות קדחתניות אלו, ג'יימס הגיע למשרד בבוקר, ולפני שהספיק להגיע לשולחנו, קיבל את פניו המנהל, מלא בקפאין מעבר לרגיל.

"אני חושש שאתה צריך לנסוע לאנאפוליס, נובה סקוטיה, בהקדם האפשרי." כל המערכת שלהם נפלה, ואחרי לילה של עבודה עם המהנדסים שלהם, אנחנו לא יכולים להבין מה קרה. נראה שהרשת נכשלה בשרת. אבל רק לאחר שהמערכת פעלה במשך מספר דקות.

- הם לא חזרו למערכת הישנה? – ענה ג'יימס ברצינות גמורה, אם כי מבחינה נפשית פתח את עיניו בהפתעה.

- בדיוק: מומחה ה-IT שלהם "שינה סדרי עדיפויות" והחליט לעזוב עם השרת הישן שלהם. ג'יימס, הם התקינו את המערכת בשישה אתרים ורק שילמו עבור תמיכת פרימיום, והעסק שלהם מתנהל כעת כמו שהיה בשנות החמישים.

ג'יימס הזדקף קלות.

- זה עניין אחר. אוקיי, בואו נתחיל.

כשהגיע לאנאפוליס, הדבר הראשון שעשה היה למצוא את התיאטרון הראשון של הלקוח שהיה לו בעיה. במפה שצולמה בשדה התעופה הכל נראה הגון, אבל האזור סביב הכתובת הרצויה נראה חשוד. לא גטו, אבל מזכיר סרט נואר. כשג'יימס חנה בשולי העיר, זונה ניגשה אליו. בהתחשב בגודלה של אנאפוליס, ככל הנראה היא הייתה היחידה בכל העיר. הופעתה העלתה מיד את הדמות המפורסמת שהציעה סקס תמורת כסף על המסך הגדול. לא, לא על ג'וליה רוברטס, אלא על ג'ון וייט [רמז לסרט "קאובוי חצות" - בערך. נתיב].

לאחר ששלחה את הזונה לדרכה, ג'יימס הלך לקולנוע. האזור שמסביב השתפר, אבל זה עדיין עשה רושם של מוזנח. לא שג'יימס היה מודאג מדי. הוא היה במקומות עלובים בעבר. וזו הייתה קנדה, שבה אפילו שודדים מנומסים מספיק כדי לומר "תודה" לאחר שלקחו את הארנק שלך.

הכניסה הצדדית לקולנוע הייתה בסמטה רטובה. ג'יימס ניגש לדלת ודפק. עד מהרה הוא חרק ונפתח מעט.

-אתה מנקה? – נשמע קול צרוד מבפנים.

- כן, זה אני... באתי לתקן הכל.

ג'יימס נכנס ללובי הקולנוע. ככל הנראה שלא הייתה ברירה אחרת, הצוות החל לחלק כרטיסי נייר למבקרים. זה הפך את הדיווח הכספי לקשה, שלא לדבר על פרטים מעניינים יותר. אבל הצוות בירך את ג'יימס בהקלה ולקח אותו מיד לחדר השרתים.

במבט ראשון הכל היה בסדר. ג'יימס נכנס לשרת ובדק את המקומות החשודים הרגילים. אין בעיה. עם זאת, מתוך שפע של זהירות, ג'יימס כיבה את השרת, החליף את כרטיס הרשת והחזיר את המערכת לאחור. היא מיד התחילה לעבוד במלואה. הצוות החל למכור כרטיסים שוב.

ג'יימס התקשר למארק והודיע ​​לו על המצב. לא קשה לדמיין שג'יימס אולי ירצה להישאר בסביבה ולראות אם משהו בלתי צפוי קורה. הוא ירד במדרגות והחל לשאול את העובדים מה קרה. ברור שהמערכת הפסיקה לעבוד. הם כיבו והדליקו, הכל עבד. אבל אחרי 10 דקות המערכת נפלה.

בדיוק ברגע זה קרה משהו דומה. לפתע, מערכת הכרטוס החלה לזרוק שגיאות. הצוות נאנח ותפס את כרטיסי הנייר, וג'יימס מיהר לחדר השרתים. הכל נראה טוב עם השרת.

ואז נכנס אחד העובדים.

- המערכת שוב עובדת.

ג'יימס היה תמה כי הוא לא עשה כלום. ליתר דיוק, שום דבר שיגרום למערכת לעבוד. הוא התנתק, הרים את הטלפון שלו והתקשר לקו התמיכה של החברה שלו. תוך זמן קצר אותו עובד נכנס לחדר השרתים.

- המערכת מושבתת.

ג'יימס הציץ בשרת. דוגמה מעניינת ומוכרת של צורות ססגוניות רקדה על המסך - צינורות מתפתלים ומשתלבים זה בזה. כולנו ראינו את שומר המסך הזה בשלב מסוים. זה היה מעובד יפה ומהפנט ממש.

ג'יימס לחץ על כפתור והדוגמה נעלמה. הוא מיהר למשרד הכרטיסים ובדרך פגש בעובד שחזר אליו.

- המערכת שוב עובדת.

אם אתה יכול לעשות טיפול נפשי, זה בדיוק מה שג'יימס עשה. שומר מסך. הוא משתמש ב-OpenGL. ולכן, במהלך הפעולה, הוא צורך את כל המשאבים של מעבד השרת. כתוצאה מכך, כל קריאה לשרת מסתיימת עם פסק זמן.

ג'יימס חזר לחדר השרתים, נכנס והחליף את שומר המסך בצינורות היפים במסך ריק. כלומר, במקום שומר מסך שצורך 100% ממשאבי המעבד, התקנתי עוד אחד שלא צורך משאבים. אחר כך חיכיתי 10 דקות כדי לבדוק את הניחוש שלי.

כשג'יימס הגיע לבית הקולנוע הבא, הוא תהה איך להסביר למנהל שלו שהוא זה עתה טס 800 ק"מ כדי לכבות את שומר המסך.

התרסקות במהלך שלב מסוים של הירח

סיפור אמיתי. יום אחד התעורר באג תוכנה שהיה תלוי בשלב הירח. הייתה שגרה קטנה שהייתה בשימוש נפוץ בתוכניות MIT שונות כדי לחשב את הקירוב לשלב האמיתי של הירח. GLS בנתה את השגרה הזו לתוך תוכנית LISP שכאשר כתיבת קובץ, תוציא שורה עם חותמת זמן של כמעט 80 תווים. זה היה נדיר מאוד שהשורה הראשונה בהודעה תהיה בסופו של דבר ארוכה מדי ותוביל לשורה הבאה. וכשהתוכנה קראה מאוחר יותר את הקובץ הזה, היא קיללה. אורך השורה הראשונה היה תלוי בתאריך ובשעה המדויקים, כמו גם באורך מפרט הפאזה בזמן הדפסת חותמת הזמן. כלומר, הבאג היה ממש תלוי בשלב הירח!

מהדורת נייר ראשונה קובץ ז'רגון (Steele-1983) הכילה דוגמה לשורה כזו שהובילה לבאג המתואר, אך הקופסא "תיקנה" אותה. זה תואר מאז כ"באג בשלב הירח".

עם זאת, היזהר בהנחות. לפני מספר שנים, מהנדסים מ-CERN (המרכז האירופי למחקר גרעיני) נתקלו בשגיאות בניסויים שבוצעו במתאיץ האלקטרון-פוזיטרון הגדול. מכיוון שמחשבים מעבדים באופן פעיל את כמות הנתונים העצומה שנוצרת על ידי המכשיר הזה לפני שהציגו את התוצאה למדענים, רבים שיערו שהתוכנה רגישה איכשהו לשלב הירח. כמה מהנדסים נואשים הגיעו לעומק האמת. השגיאה נוצרה עקב שינוי קל בגיאומטריה של הטבעת באורך 27 ק"מ עקב עיוות כדור הארץ במהלך מעבר הירח! הסיפור הזה נכנס לפולקלור הפיזיקלי כ"נקמתו של ניוטון בפיזיקה של החלקיקים" ודוגמה לקשר בין חוקי הפיזיקה הפשוטים והעתיקים ביותר לבין המושגים המדעיים המתקדמים ביותר.

שטיפת האסלה עוצרת את הרכבת

באג החומרה הטוב ביותר ששמעתי עליו היה ברכבת מהירה בצרפת. הבאג הוביל לבלימת חירום של הרכבת, אך רק אם היו נוסעים על הסיפון. בכל מקרה כזה הרכבת הוצאה משירות, נבדקה, אך לא נמצא דבר. אחר כך הוא נשלח בחזרה לקו, והוא מיד התרסק לעצירה.

באחת הבדיקות הלך מהנדס שנסע ברכבת לשירותים. הוא נשטף במהרה, בום! עצירת חירום.

המהנדס פנה לנהג ושאל:

- מה עשית רגע לפני בלימה?

ובכן, האטתי בירידה...

זה היה מוזר, כי בזמן פעילות רגילה הרכבת מאטה בירידות עשרות פעמים. הרכבת המשיכה הלאה, ובירידה הבאה הנהג הזהיר:

- אני הולך להאט.

שום דבר לא קרה.

- מה עשית במהלך הבלימה האחרונה? – שאל הנהג.

- טוב... הייתי בשירותים...

- נו, אז לך לשירותים ותעשה מה שעשית כשנרד שוב!

המהנדס הלך לשירותים, וכשהנהג הזהיר: "אני מאט", הוא שטף את המים. כמובן שהרכבת עצרה מיד.

כעת הם יכלו לשחזר את הבעיה והיו צריכים למצוא את הסיבה.

לאחר שתי דקות הבחינו שכבל שלט של בלם המנוע (לרכבת היה מנוע אחד בכל קצה) מנותק מקיר ארון החשמל ושוכב על הממסר ששלט על סולנואיד תקע האסלה... כאשר הממסר הופעל, הוא יצר הפרעות בכבל הבלמים, והגנת המערכת מפני תקלות פשוט כללה בלימת חירום.

השער ששנא את FORTRAN

לפני כמה חודשים שמנו לב שחיבורי הרשת ביבשת [זה היה בהוואי] נעשו מאוד מאוד איטיים. זה יכול להימשך 10-15 דקות ואז פתאום להתרחש שוב. לאחר זמן מה, עמית שלי התלונן בפניי כי חיבורי הרשת ביבשת באופן כללי לא עובד. היה לו קוד FORTRAN שהיה צריך להעתיק למכונה ביבשת, אבל זה לא היה יכול כי "הרשת לא החזיקה מספיק זמן כדי שהעלאת ה-FTP תסתיים".

כן, התברר שתקלות רשת התרחשו כאשר עמית ניסה להעביר קובץ עם קוד מקור ב- FORTRAN ל-FTP למכונה ביבשת. ניסינו לאחסן את הקובץ: לאחר מכן הוא הועתק בצורה חלקה (אבל למכונת היעד לא היה מפרק, כך שהבעיה לא נפתרה). לבסוף "פיצלנו" את קוד FORTRAN לחתיכות קטנות מאוד ושלחנו אותן אחת אחת. רוב השברים הועתקו ללא בעיות, אך חלקים בודדים לא עברו, או עברו לאחר מכן רב ניסיונות.

כשבדקנו את הקטעים הבעייתיים, גילינו שיש להם משהו משותף: כולם הכילו בלוקים של הערות שמתחילים ונגמרים בשורות המורכבות מ-C גדול (כפי שעמית העדיף להגיב ב- FORTRAN). שלחנו אימייל למומחי רשת ביבשת וביקשנו עזרה. כמובן שהם רצו לראות דוגמאות של הקבצים שלנו שלא ניתן היה להעביר דרך FTP... אבל המכתבים שלנו לא הגיעו אליהם. לבסוף מצאנו דבר פשוט לתאראיך נראים קבצים שאינם ניתנים להעברה. זה עבד :) [העז לי להוסיף דוגמה לאחת מהתגובות הבעייתיות של FORTRAN כאן? כנראה לא שווה את זה!]

בסוף הצלחנו להבין את זה. שער חדש הותקן לאחרונה בין החלק שלנו בקמפוס לרשת היבשת. היה לו קושי עצום בהעברת מנות שהכילו סיביות חוזרות ונשנות של אותיות גדולות C! רק כמה מהמנות הללו יכולות לתפוס את כל משאבי השער ולמנוע מרוב החבילות האחרות לעבור. התלוננו ליצרן השער... והם ענו: "אה, כן, אתה מתמודד עם באג של C חוזר! אנחנו כבר יודעים עליו". בסופו של דבר פתרנו את הבעיה על ידי רכישת שער חדש מיצרן אחר (להגנתו של הראשון, חוסר היכולת להעביר תוכניות FORTRAN עשוי להיות יתרון עבור חלקם!).

זמנים קשים

לפני כמה שנים, בזמן שעבדתי על יצירת מערכת ETL בפרל כדי להפחית את העלויות של ניסויים קליניים שלב 40, הייתי צריך לעבד כ-000 תאריכים. שניים מהם לא עברו את המבחן. זה לא הפריע לי יותר מדי כי התאריכים האלה נלקחו מנתונים שסופקו על ידי הלקוח, שלעתים קרובות, נגיד, מפתיעים. אבל כשבדקתי את הנתונים המקוריים, התברר שהתאריכים האלה הם 1 בינואר 2011 ו-1 בינואר 2007. חשבתי שהבאג כלול בתוכנית שכתבתי זה עתה, אבל התברר שזה כבר 30 שנה ישן. זה עשוי להישמע מסתורי למי שלא מכיר את המערכת האקולוגית של התוכנה. בגלל ההחלטה ארוכת השנים של חברה אחרת להרוויח כסף, הלקוח שלי שילם לי כדי לתקן באג שחברה אחת הציגה בטעות והשנייה בכוונה. כדי שתבינו על מה אני מדבר, אני צריך לדבר על החברה שהוסיפה את הפיצ'ר שבסופו של דבר הפך לבאג, כמו גם עוד כמה אירועים מעניינים שתרמו לבאג המסתורי שתיקנתי.

בימים הטובים, מחשבי אפל היו מאפסים באופן ספונטני את התאריך שלהם ל-1 בינואר 1904. הסיבה הייתה פשוטה: הוא השתמש ב"שעון מערכת" המופעל על ידי סוללה כדי לעקוב אחר התאריך והשעה. מה קרה כשהסוללה מתה? מחשבים החלו לעקוב אחר התאריך לפי מספר השניות מאז תחילתה של תקופה. בעידן התכוונו לתאריך המקורי של ההתייחסות, ועבור מקינטוש זה היה 1 בינואר 1904. ואחרי שהסוללה מתה, התאריך הנוכחי אופס לתאריך שצוין. אבל למה זה קרה?

בעבר, אפל השתמשה ב-32 סיביות כדי לאחסן את מספר השניות מאז התאריך המקורי. ביט אחד יכול לאחסן אחד משני ערכים - 1 או 0. שני ביטים יכולים לאחסן אחד מארבעה ערכים: 00, 01, 10, 11. שלושה ביטים - ערך אחד מתוך שמונה: 000, 001, 010, 011, 100 , 101, 110, 111 וכו'. ו-32 יכול לאחסן אחד מ-232 ערכים, כלומר 4 שניות. עבור תאריכים של אפל, זה היה שווה בערך ל-294 שנים, כך שמחשבי Mac ישנים יותר לא יכולים להתמודד עם תאריכים אחרי 967. ואם סוללת המערכת מתה, התאריך מתאפס ל-296 שניות מתחילת העידן, ויש להגדיר ידנית את התאריך בכל פעם שמפעילים את המחשב (או עד שקונים סוללה חדשה).

עם זאת, ההחלטה של ​​אפל לאחסן תאריכים כשניות מאז העידן גרמה לכך שלא יכולנו להתמודד עם תאריכים לפני העידן, שהיו לה השלכות מרחיקות לכת, כפי שנראה. אפל הציגה תכונה, לא באג. בין היתר, זה גרם לכך שמערכת ההפעלה מקינטוש הייתה חסינה מפני "באג המילניום" (שלא ניתן היה לומר על אפליקציות מק רבות שהיו להן מערכות תאריך משלהן כדי לעקוף הגבלות).

לך על זה. השתמשנו ב-Lotus 1-2-3, "יישום הרוצח" של יבמ שעזר להשיק את מהפכת ה-PC, למרות שבמחשבי אפל היה VisiCalc, שהפך את המחשב האישי להצלחה. למען ההגינות, אם 1-2-3 לא היה מופיע, המחשבים האישיים בקושי היו ממריאים, וההיסטוריה של המחשבים האישיים הייתה יכולה להתפתח אחרת לגמרי. לוטוס 1-2-3 התייחס באופן שגוי לשנת 1900 כשנה מעוברת. כשמיקרוסופט פרסמה את הגיליון האלקטרוני הראשון שלה, Multiplan, היא תפסה נתח קטן מהשוק. וכשהשיקו את פרויקט האקסל, הם החליטו לא רק להעתיק את ערכת שמות השורות והעמודות מ-Lotus 1-2-3, אלא גם להבטיח תאימות באגים על ידי התייחסות מכוונת לשנת 1900 כשנה מעוברת. הבעיה הזו קיימת עד היום. כלומר, ב-1-2-3 זה היה באג, אבל באקסל זו הייתה החלטה מודעת שהבטיחה שכל 1-2-3 המשתמשים יוכלו לייבא את הטבלאות שלהם לאקסל מבלי לשנות את הנתונים, גם אם הם לא נכונים.

אבל הייתה בעיה אחרת. ראשית, מיקרוסופט הוציאה את אקסל עבור המקינטוש, שלא זיהה תאריכים לפני 1 בינואר 1904. ובאקסל, 1 בינואר 1900 נחשב לתחילת העידן. לכן, המפתחים ביצעו שינוי כך שהתוכנה שלהם זיהתה את סוג העידן ואחסנה נתונים בתוך עצמה בהתאם לעידן הרצוי. מיקרוסופט אפילו כתבה על כך מאמר הסבר. וההחלטה הזו הובילה לבאג שלי.

מערכת ה-ETL שלי קיבלה גיליונות אלקטרוניים של Excel מלקוחות שנוצרו ב-Windows, אך ניתן היה ליצור אותם גם ב-Mac. לכן, תחילת העידן בטבלה יכולה להיות 1 בינואר 1900 או 1 בינואר 1904. איך לברר? פורמט קובץ האקסל מציג את המידע הדרוש, אבל המנתח שהשתמשתי בו לא הראה אותו (עכשיו הוא כן), והנחה שאתה מכיר את העידן של טבלה ספציפית. כנראה שיכולתי להשקיע יותר זמן בהבנת הפורמט הבינארי של Excel ושליחת תיקון למחבר המנתח, אבל היה לי עוד הרבה מה לעשות עבור הלקוח, אז כתבתי במהירות יוריסטיקה כדי לקבוע את העידן. היא הייתה פשוטה.

באקסל, התאריך 5 ביולי 1998 יכול להיות מיוצג בפורמט "07-05-98" (מערכת אמריקאית חסרת תועלת), "5 ביולי 98", "5 ביולי 1998", "5-יולי-98" או פורמט אחר. פורמט חסר תועלת אחר (למרבה האירוניה, אחד הפורמטים שגרסת האקסל שלי לא הציעה היה ISO 8601). עם זאת, בתוך הטבלה, התאריך הלא מעוצב נשמר כ-"35981" עבור עידן-1900 או "34519" עבור עידן-1904 (המספרים מייצגים את מספר הימים מאז התקופה). פשוט השתמשתי במנתח פשוט כדי לחלץ את השנה מהתאריך המעוצב, ולאחר מכן השתמשתי במנתח של Excel כדי לחלץ את השנה מהתאריך הלא מעוצב. אם שני הערכים היו שונים ב-4 שנים, אז ידעתי שאני משתמש במערכת עם epoch-1904.

למה לא השתמשתי בתאריכים מעוצבים? מכיוון שניתן לעצב את ה-5 ביולי 1998 כ-"יולי, 98" כשהיום בחודש אבוד. קיבלנו טבלאות מכל כך הרבה חברות שיצרו אותן בכל כך הרבה דרכים שונות שהייתה תלויה בנו (במקרה הזה, אני) להבין את התאריכים. חוץ מזה, אם אקסל מבין את זה נכון, אז גם אנחנו צריכים!

במקביל נתקלתי ב-39082. הרשו לי להזכיר לכם שלוטוס 1-2-3 ראה ב-1900 שנה מעוברת, וזה חזר על עצמו נאמנה באקסל. ומכיוון שזה הוסיף יום אחד לשנת 1900, פונקציות רבות של חישוב תאריכים עלולות להיות שגויות באותו היום. כלומר, 39082 יכול היה להיות 1 בינואר 2011 (ב-Mac) או 31 בדצמבר 2006 (ב-Windows). אם "מנתח השנה" שלי חילץ את שנת 2011 מהערך המעוצב, אז הכל בסדר. אבל מכיוון שמנתח ה-Excel אינו יודע באיזה תקופה נעשה שימוש, הוא כברירת מחדל ל-epoch-1900, וחוזר לשנת 2006. האפליקציה שלי ראתה שההפרש הוא 5 שנים, ראתה את זה כשגיאה, רשמה אותו והחזירה ערך לא מעוצב.

כדי לעקוף את זה, כתבתי את זה (פסאודוקוד):

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

ואז כל 40 התאריכים נותחו בצורה נכונה.

באמצע עבודות הדפסה גדולות

בתחילת שנות ה-1980, אבי עבד בחברת Storage Technology, חטיבה שהושבתה כעת, שיצרה כונני טייפ ומערכות פניאומטיות להזנת סרטים במהירות גבוהה.

הם עיצבו מחדש את הכוננים כך שיהיה להם כונן "A" מרכזי אחד מחובר לשבעה כונני "B", ומערכת ההפעלה הקטנה ב-RAM ששלטה בכונן "A" יכולה להאציל פעולות קריאה וכתיבה לכל כונני "B".

בכל פעם שהכונן "A" הופעל, היה צורך להכניס תקליטון לכונן ההיקפי המחובר ל-"A" על מנת לטעון את מערכת ההפעלה לזיכרון שלה. זה היה פרימיטיבי ביותר: כוח המחשוב סופק על ידי מיקרו-בקר של 8 סיביות.

קהל היעד של ציוד כזה היה חברות עם מחסני נתונים גדולים מאוד - בנקים, רשתות קמעונאיות וכו' - שהיו צריכים להדפיס הרבה תוויות כתובות או דפי בנק.

ללקוח אחד הייתה בעיה. באמצע עבודת הדפסה, כונן אחד מסוים "A" עלול להפסיק לעבוד, ולגרום לכל העבודה להיתקע. כדי לשחזר את פעולת הכונן, הצוות היה צריך לאתחל הכל. ואם זה קרה באמצע משימה של שש שעות, אז כמות עצומה של זמן מחשב יקר אבד ולוח הזמנים של כל המבצע השתבש.

טכנאים נשלחו מ- Storage Technologies. אבל למרות מאמציהם, הם לא הצליחו לשחזר את הבאג בתנאי בדיקה: נראה היה שהוא התרחש באמצע עבודות הדפסה גדולות. הבעיה לא הייתה החומרה, הם החליפו כל מה שיכלו: זיכרון RAM, מיקרו-בקר, כונן תקליטונים, כל חלק שאפשר להעלות על הדעת בכונן הטייפ - הבעיה נמשכה.

אחר כך התקשרו הטכנאים למפקדה והתקשרו למומחה.

המומחה תפס כיסא וכוס קפה, ישב בחדר המחשבים - באותם ימים היו חדרים ייעודיים למחשבים - וצפה איך הצוות עומד בתור לעבודת הדפסה גדולה. המומחה חיכה שיתרחש כישלון - וזה קרה. כולם הסתכלו על המומחה, אבל לא היה לו מושג למה זה קרה. אז הוא הורה להעמיד שוב את העבודה בתור, וכל הצוות והטכנאים חזרו לעבודה.

המומחה שוב התיישב על הכיסא והחל לחכות לכשל. חלפו כשש שעות והכשל התרחש. למומחה שוב לא היו רעיונות, אלא שהכל קרה בחדר מלא באנשים. הוא הורה להתחיל מחדש את המשימה, התיישב בחזרה והמתין.

עד לכישלון השלישי, המומחה הבחין במשהו. הכשל התרחש כאשר הצוות החליף קלטות בכונן זר. יתרה מכך, הכשל אירע ברגע שאחד העובדים עבר דרך אריח מסוים על הרצפה.

הרצפה המוגבהת הייתה עשויה מאריחי אלומיניום שהונחו בגובה של 6 עד 8 אינץ'. חוטים רבים ממחשבים עברו מתחת לרצפה המוגבהת כדי למנוע מאף אחד לדרוך בטעות על כבל חשוב. האריחים הונחו בצורה הדוקה מאוד כדי למנוע מפסולת להיכנס מתחת לרצפה המוגבהת.

המומחה הבין שאחד האריחים מעוות. כאשר עובד עלה על פינתה, שולי האריח התחככו באריחים הסמוכים. גם חלקי הפלסטיק שחיברו את האריחים התחככו איתם, מה שגרם לפריקות מיקרו סטטיות שיצרו הפרעות בתדרי רדיו.

כיום, זיכרון RAM מוגן הרבה יותר מהפרעות בתדר רדיו. אבל באותן שנים זה לא היה המצב. המומחה הבין שההפרעה הזו משבשת את הזיכרון, ואיתה את פעולת מערכת ההפעלה. הוא התקשר לשירות התמיכה, הזמין אריחים חדשים, התקין אותם בעצמו והבעיה נעלמה.

זה גאות!

הסיפור התרחש בחדר שרתים, בקומה הרביעית או החמישית של משרד בפורטסמות' (אני חושב), באזור הרציפים.

יום אחד קרס שרת יוניקס עם מסד הנתונים הראשי. הם הפעילו אותו מחדש, אבל הוא המשיך בשמחה ליפול שוב ושוב. החלטנו להתקשר למישהו משירות התמיכה.

איש התמיכה... אני חושב ששמו היה מארק, אבל זה לא משנה... אני לא חושב שאני מכיר אותו. זה לא משנה, באמת. בוא נישאר עם מארק, בסדר? גדול.

אז, כמה שעות לאחר מכן מארק הגיע (זה לא דרך ארוכה מלידס לפורטסמות', אתם יודעים), הדליק את השרת והכל עבד בלי בעיות. תמיכה ארורה אופיינית, הלקוח מתעצבן מאוד מזה. מארק מסתכל בקבצי היומן ולא מוצא שום דבר לא ראוי. אז מארק חוזר לרכבת (או בכל אמצעי תחבורה שהוא הגיע בו, זו הייתה יכולה להיות פרה צולעת לכל מה שאני יודע... בכל מקרה, זה לא משנה, בסדר?) וחוזר ללידס, לאחר שבזבזתי היום.

באותו ערב השרת קורס שוב. הסיפור זהה... השרת לא עולה. מארק מנסה לעזור מרחוק, אך הלקוח לא יכול להפעיל את השרת.

עוד רכבת, אוטובוס, מרנג לימון או איזה שטות אחרת, ומארק חזר לפורטסמות'. תראה, השרת מאתחל ללא בעיות! נֵס. מארק מבלה מספר שעות בבדיקה שהכל תקין עם מערכת ההפעלה או התוכנה ויוצא לדרך לידס.

בסביבות אמצע היום השרת קורס (קח את זה בקלות!). הפעם נראה הגיוני להביא את אנשי תמיכת החומרה שיחליפו את השרת. אבל לא, אחרי בערך 10 שעות זה גם נופל.

המצב חזר על עצמו במשך מספר ימים. השרת עובד, קורס לאחר כ-10 שעות ולא מופעל במשך השעתיים הבאות. הם בדקו קירור, דליפות זיכרון, בדקו הכל, אבל לא מצאו כלום. ואז נעצרו ההתרסקויות.

השבוע עבר ללא דאגות... כולם היו מרוצים. שמח עד שהכל יתחיל מחדש. התמונה זהה. 10 שעות עבודה, 2-3 שעות השבתה...

ואז מישהו (אני חושב שהם אמרו לי שלאדם הזה אין שום קשר ל-IT) אמר:

"זה הגאות!"

הקריאה נענתה במבטים ריקים, וידו של מישהו כנראה היססה בלחצן שיחת האבטחה.

"זה מפסיק לעבוד עם הגאות".

נראה שזה רעיון זר לחלוטין לעובדי תמיכת IT, שספק אם יקראו את ספר השנתון של גאות בזמן שהם יושבים לקפה. הם הסבירו שזה לא יכול להיות קשור לגאות בשום צורה, כי השרת עבד שבוע ללא תקלות.

"בשבוע שעבר הגאות הייתה נמוכה, אבל השבוע הוא גבוה".

מינוח קטן למי שאין לו רישיון יאכטה. הגאות והשפל תלויים במחזור הירח. וכאשר כדור הארץ מסתובב, כל 12,5 שעות כוח הכבידה של השמש והירח יוצר גל גאות. בתחילת המחזור של 12,5 שעות יש גאות, באמצע המחזור יש גאות ובסיומו שוב גאות. אבל ככל שמסלול הירח משתנה, כך גם ההבדל בין שפל לגאות משתנה. כאשר הירח נמצא בין השמש לכדור הארץ או בצד הנגדי של כדור הארץ (ירח מלא או ללא ירח), אנו מקבלים גאות ושפל Syzygyn - הגאות הגבוהה ביותר והשפל הנמוך ביותר. בחצי ירח אנו מקבלים גאות נצב - הגאות הנמוכה ביותר. ההבדל בין שני הקצוות יורד מאוד. מחזור הירח נמשך 28 ימים: syzygian - quadrature - syzygian - quadrature.

כשהוסבר לטכנאים מהות כוחות הגאות, חשבו מיד שעליהם להזעיק משטרה. ודי הגיוני. אבל מסתבר שהבחור צדק. שבועיים קודם לכן עגנה משחתת לא הרחק מהמשרד. בכל פעם שהגאות העלתה אותו לגובה מסוים, עמדת הרדאר של הספינה הגיעה לגובה רצפת חדר השרתים. והרדאר (או ציוד לוחמה אלקטרוני, או צעצוע צבאי אחר) יצר כאוס במחשבים.

משימת טיסה לרקטה

הוטל עליי להעביר מערכת בקרת וניטור שיגור רקטות גדולה (כ-400 אלף קווים) לגרסאות חדשות של מערכת ההפעלה, המהדר והשפה. ליתר דיוק, מ-Solaris 2.5.1 ל-Solaris 7, וממערכת הפיתוח של Verdix Ada (VADS), שנכתבה ב-Ada 83, למערכת Rational Apex Ada, שנכתבה ב-Ada 95. VADS נרכשה על ידי Rational, והמוצר שלה היה מיושן, למרות ש-Rational ניסתה ליישם גרסאות תואמות של חבילות ספציפיות ל-VADS כדי להקל על המעבר למהדר Apex.

שלושה אנשים עזרו לי פשוט להרכיב את הקוד בצורה נקייה. זה לקח שבועיים. ואז עבדתי לבד כדי לגרום למערכת לעבוד. בקיצור, זו הייתה הארכיטקטורה והיישום הגרועים ביותר של מערכת תוכנה שנתקלתי בה, אז לקח עוד חודשיים להשלים את הפורט. לאחר מכן הוגשה המערכת לבדיקה, שנמשכה מספר חודשים נוספים. תיקנתי מיד את הבאגים שנמצאו במהלך הבדיקה, אך מספרם ירד במהירות (קוד המקור היה מערכת ייצור, כך שהפונקציונליות שלו עבדה בצורה אמינה למדי, רק הייתי צריך להסיר את הבאגים שעלו במהלך ההתאמה לקומפיילר החדש). בסופו של דבר, כשהכל עבד כמו שצריך, הועברתי לפרויקט אחר.

וביום שישי לפני חג ההודיה, הטלפון צלצל.

שיגור הרקטה היה אמור להיבדק בעוד כשלושה שבועות, ובמהלך בדיקות מעבדה של הספירה לאחור נחסם רצף הפקודות. בחיים האמיתיים הדבר יבטל את הבדיקה, ואם החסימה תתרחש תוך שניות ספורות מרגע התנעת המנוע, יתרחשו במערכות העזר כמה פעולות בלתי הפיכות, שידרשו מוכנות ארוכה - ויקרה - של הרקטה. זה לא היה מתחיל, אבל הרבה אנשים היו כועסים מאוד על אובדן הזמן והרבה הרבה כסף. אל תתנו לאף אחד להגיד לכם שמשרד הביטחון מוציא כסף בפזיזות - מעולם לא פגשתי מנהל קבלנות שלא שם את התקציב במקום הראשון או השני, ואחריו לוח זמנים.

בחודשים קודמים, אתגר הספירה לאחור הזה הופעל מאות פעמים בווריאציות רבות, עם כמה שיהוקים קלים בלבד. אז הסבירות שזה יקרה הייתה מאוד נמוכה, אבל ההשלכות שלו היו מאוד משמעותיות. תכפילו את שני הגורמים הללו, ותבינו שהחדשות ניבאו לי ולעשרות מהנדסים ומנהלים שבוע חג הרוס.

ותשומת הלב הוקדשה אלי כמי שהעביר את המערכת.

כמו ברוב המערכות הקריטיות לאבטחה, הרבה פרמטרים נרשמו, כך שהיה די קל לזהות את מעט שורות הקוד שהופעלו לפני שהמערכת קרסה. וכמובן, לא היה בהם שום דבר יוצא דופן; ​​אותם ביטויים בוצעו בהצלחה ממש אלפי פעמים במהלך אותה ריצה.

קראנו לאנשי Apex ל-Rational כי הם אלה שפיתחו את המהדר וחלק מהרוטינות שהם פיתחו נקראו בקוד החשוד. הם (וכל השאר) התרשמו שיש צורך לרדת לשורשה של בעיה בעלת חשיבות לאומית תרתי משמע.

מכיוון שלא היה שום דבר מעניין בכתבי העת, החלטנו לנסות לשחזר את הבעיה במעבדה מקומית. זו לא הייתה משימה קלה מכיוון שהאירוע התרחש בערך פעם אחת לכל 1000 ריצות. סיבה חשודה אחת הייתה שקריאה לפונקציית mutex שפותחה על ידי הספק (חלק מחבילת ההגירה של VADS) Unlock לא הוביל לפתיחה. חוט העיבוד שקרא לפונקציה עיבד הודעות פעימות לב, שהגיעו באופן נומינלי כל שנייה. העלינו את התדר ל-10 הרץ, כלומר 10 פעמים בשנייה, והתחלנו לרוץ. כשעה לאחר מכן המערכת נעלה את עצמה. ביומן ראינו שרצף ההודעות המוקלטות זהה לזה של המבחן שנכשל. עשינו עוד מספר ריצות, המערכת נחסמה באופן עקבי 45-90 דקות לאחר ההתחלה, ובכל פעם היומן הכיל את אותו מסלול. למרות שהרצנו טכנית קוד שונה - תדירות ההודעות הייתה שונה - התנהגות המערכת הייתה זהה, כך שהיינו בטוחים שתרחיש העומס הזה גורם לאותה בעיה.

כעת היינו צריכים להבין היכן בדיוק התרחשה החסימה ברצף הביטויים.

יישום זה של המערכת השתמש במערכת המשימות Ada והשתמש בה בצורה גרועה להפליא. משימות הן מבנה הניתן להפעלה בו-זמנית ברמה גבוהה ב-Ada, משהו כמו פתילים של ביצוע, המובנים רק בשפה עצמה. כאשר שתי משימות צריכות לתקשר, הם "קובעים פגישה", מחליפים את הנתונים הדרושים, ואז מפסיקים את המפגש וחוזרים לביצוע עצמאי שלהם. עם זאת, המערכת יושמה אחרת. לאחר שמשימת מטרה הייתה מפגש, משימת היעד התכנסה למשימה אחרת, ולאחר מכן התכנסה עם משימה שלישית, וכן הלאה עד להשלמת עיבוד מסוים. לאחר מכן, הושלמו כל המפגשים הללו וכל משימה הייתה צריכה לחזור לביצועה. כלומר, עסקינן במערכת קריאת הפונקציות היקרה ביותר בעולם, שעצרה את כל תהליך ה"ריבוי משימות" בזמן שהיא מעבדת חלק מנתוני הקלט. ולפני זה לא הוביל לבעיות רק בגלל שהתפוקה הייתה נמוכה מאוד.

תיארתי את מנגנון המשימה הזה מכיוון שכאשר התבקשה מפגש או צפוי להסתיים, יכול להתרחש "החלפת משימה". כלומר, המעבד יכול להתחיל לעבד משימה אחרת שמוכנה לביצוע. מסתבר שכאשר משימה אחת מוכנה למפגש עם משימה אחרת, משימה אחרת לגמרי יכולה להתחיל בביצוע, ובסופו של דבר השליטה חוזרת למפגש הראשון. וייתכנו אירועים אחרים שגורמים למשימה לעבור; אירוע אחד כזה הוא קריאה לפונקציית מערכת, כגון הדפסה או ביצוע mutex.

כדי להבין איזו שורת קוד גורמת לבעיה, הייתי צריך למצוא דרך לתעד התקדמות דרך רצף של הצהרות מבלי להפעיל מתג משימה, שימנע את התרחשות התרסקות. אז לא יכולתי לנצל Put_Line()כדי להימנע מביצוע פעולות קלט/פלט. אני יכול להגדיר משתנה מונה או משהו דומה, אבל איך אני יכול לראות את הערך שלו אם אני לא יכול להציג אותו על המסך?

כמו כן, בבחינת היומן התברר שלמרות הקפאת עיבוד הודעות פעימות הלב, שחסמה את כל פעולות ה-I/O של התהליך ומנעה ביצוע עיבודים אחרים, המשיכו לבצע משימות עצמאיות אחרות. כלומר, העבודה לא נחסמה לחלוטין, אלא רק שרשרת (קריטית) של משימות.

זה היה הרמז הדרוש כדי להעריך את הביטוי החוסם.

הכנתי חבילת Ada שהכילה משימה, סוג מסופר ומשתנה גלובלי מהסוג הזה. מילוליות רבות היו קשורות לביטויים ספציפיים של הרצף הבעייתי (למשל. Incrementing_Buffer_Index, Locking_Mutex, Mutex_Unlocked), ולאחר מכן הכניס לתוכו ביטויי הקצאה שהקצו את הספירה המתאימה למשתנה גלובלי. מכיוון שקוד האובייקט של כל זה פשוט אחסן קבוע בזיכרון, החלפת משימות כתוצאה מביצועו הייתה מאוד לא סבירה. חשדנו בעיקר בביטויים שיכולים להחליף את המשימה, מכיוון שהחסימה התרחשה בביצוע ולא בהחזרה בעת החלפת המשימה לאחור (מכמה סיבות).

משימת המעקב פשוט רצה בלולאה ובודקה מעת לעת אם הערך של המשתנה הגלובלי השתנה. עם כל שינוי, הערך נשמר בקובץ. ואז המתנה קצרה וצ'ק חדש. כתבתי את המשתנה לקובץ כי המשימה בוצעה רק כאשר המערכת בחרה אותו לביצוע בעת החלפת המשימה באזור הבעיה. כל מה שקרה במשימה הזו לא ישפיע על משימות חסומות אחרות, שאינן קשורות.

היה צפוי שכאשר המערכת תגיע לנקודת ביצוע הקוד הבעייתי, המשתנה הגלובלי יאופס בעת מעבר לכל ביטוי הבא. אז יקרה משהו שיגרום למשימה לעבור, ומכיוון שתדירות הביצוע שלה (10 הרץ) נמוכה מזו של משימת הניטור, המוניטור יוכל ללכוד את הערך של המשתנה הגלובלי ולכתוב אותו. במצב רגיל, יכולתי לקבל רצף חוזר של תת-קבוצה של ספירות: הערכים האחרונים של המשתנה בזמן החלפת המשימה. בעת התליה, המשתנה הגלובלי כבר לא אמור להשתנות, והערך האחרון שנכתב יציין איזה ביטוי לא הושלם.

הרצתי את הקוד עם מעקב. הוא קפא. והניטור עבד כמו שעון.

היומן הכיל את הרצף הצפוי, שנקטע על ידי ערך המציין שנקרא mutex Unlock, והמשימה לא הושלמה - כפי שקורה באלפי שיחות קודמות.

מהנדסי Apex ניתחו בקדחתנות את הקוד שלהם בשלב זה ומצאו מקום ב-mutex שבו, תיאורטית, יכולה להתרחש נעילה. אבל ההסתברות שלו הייתה נמוכה מאוד, שכן רק רצף מסוים של אירועים המתרחש בזמן מסוים יכול להוביל לחסימה. חוק מרפי, חבר'ה, זה חוק מרפי.

כדי להגן על פיסת הקוד שהייתי צריך, החלפתי את קריאות הפונקציות mutex (שבנויות על גבי פונקציונליות ה-mutex של מערכת ההפעלה) בחבילה קטנה של Ada mutex כדי לשלוט בגישה של mutex לקטע הזה.

הכנסתי אותו לקוד והרצתי את הבדיקה. שבע שעות לאחר מכן הקוד עדיין פעל.

הקוד שלי הוגש ל-Rational ושם הרכיבו אותו, פירקו אותו ובדקו שהוא לא משתמש באותה גישה שהייתה בשימוש בפונקציות ה-mutex הבעייתיות.

זו הייתה סקירת הקוד הצפופה ביותר בקריירה שלי 🙂 היו איתי כעשרה מהנדסים ומנהלים בחדר, עוד עשרה אנשים היו בשיחת ועידה - וכולם בחנו כ-20 שורות קוד.

הקוד נבדק, קובצי הפעלה חדשים הורכבו והוגשו לבדיקת רגרסיה רשמית. כעבור שבועיים, ניסוי הספירה לאחור הצליח והטיל המריאה.

אוקיי, הכל טוב ויפה, אבל מה הטעם בסיפור?

זו הייתה בעיה מגעילה לחלוטין. מאות אלפי שורות קוד, ביצוע מקביל, למעלה מתריסר תהליכי אינטראקציה, ארכיטקטורה לקויה והטמעה לקויה, ממשקים למערכות משובצות והוצאת מיליוני דולרים. בלי לחץ, נכון.

לא הייתי היחיד שעבד על הבעיה הזו, למרות שהייתי באור הזרקורים בזמן שעשיתי את ההעברה. אבל למרות שעשיתי את זה, זה לא אומר שהבנתי את כל מאות אלפי שורות הקוד, או אפילו רפרפתי אותן. הקוד והלוגים נותחו על ידי מהנדסים בכל הארץ, אבל כשסיפרו לי את ההשערות שלהם לגבי הגורמים לכשל, לקח לי רק חצי דקה להפריך אותם. וכשהתבקשתי לנתח תיאוריות, הייתי מעביר את זה למישהו אחר, כי היה לי ברור שהמהנדסים האלה הולכים בדרך הלא נכונה. נשמע יומרני? כן, זה נכון, אבל דחיתי את ההשערות והבקשות מסיבה אחרת.

הבנתי את מהות הבעיה. לא ידעתי בדיוק איפה זה קורה או למה, אבל ידעתי מה קורה.

במהלך השנים צברתי ידע וניסיון רב. הייתי מחלוצי השימוש בעדה והבנתי את היתרונות והחסרונות שלה. אני יודע איך ספריות זמן הריצה של Ada מטפלות במשימות ומתמודדות עם ביצוע מקביל. ואני מבין בתכנות ברמה נמוכה ברמת הזיכרון, הרגיסטרים והאסמבלר. במילים אחרות, יש לי ידע מעמיק בתחום שלי. והשתמשתי בהם כדי למצוא את הסיבה לבעיה. לא רק עקפתי את הבאג, הבנתי איך למצוא אותו בסביבת זמן ריצה מאוד רגישה.

סיפורים כאלה של מאבק בקוד אינם מעניינים במיוחד עבור מי שלא מכיר את התכונות והתנאים של מאבק כזה. אבל הסיפורים האלה עוזרים לנו להבין מה נדרש כדי לפתור בעיות קשות באמת.

כדי לפתור בעיות קשות באמת, אתה צריך להיות יותר מסתם מתכנת. אתה צריך להבין את "גורלו" של הקוד, כיצד הוא מקיים אינטראקציה עם הסביבה שלו, וכיצד הסביבה עצמה פועלת.

ואז יהיה לך שבוע חג הרוס משלך.

המשך.

מקור: www.habr.com