⛹🏽 🧑🏾‍🤝‍🧑🏻 😢 فولكلور المبرمجين والمهندسين (الجزء الثاني) 😳 👋🏽 🐣

استمرار جمع القصص من الإنترنت حول كيف يكون للبق أحيانًا مظاهر لا تصدق تمامًا. الجزء الأول هنا .

OpenOffice لا يطبع أيام الثلاثاء

صادفت اليوم على المدونة إشارة إلى خطأ مثير للاهتمام. واجه بعض الأشخاص مشكلة في طباعة المستندات. لاحقًا لاحظ أحدهم أن زوجته اشتكت من عدم قدرتها على الطباعة أيام الثلاثاء!

في تقارير الأخطاء ، اشتكى البعض في البداية من أنه يجب أن يكون خطأ OpenOffice ، لأنه من جميع التطبيقات الأخرى قام بطباعته دون مشاكل. لاحظ آخرون أن المشكلة تأتي وتذهب. وجد أحد المستخدمين حلاً: قم بإلغاء تثبيت OpenOffice ومسح النظام ، ثم أعد التثبيت (أي مهمة بسيطة على Ubuntu). أبلغ المستخدم يوم الثلاثاء أن مشكلة الطباعة الخاصة به قد تم حلها.

بعد أسبوعين ، كتب (يوم الثلاثاء) أن حله ما زال غير مجد. بعد حوالي أربعة أشهر ، اشتكت زوجة مخترق Ubuntu من أن OpenOffice لم يطبع أيام الثلاثاء. تخيل هذا الموقف:

الزوجة: ستيف ، الطابعة مغلقة أيام الثلاثاء.

ستيف: إنه يوم عطلة في الطابعة ، بالطبع لا تطبع أيام الثلاثاء.

الزوجة: أنا جاد! لا يمكنني الطباعة من OpenOffice أيام الثلاثاء.

ستيف: (مشكوك فيه) حسنًا ، أرني.

الزوجة: لا أستطيع أن أريك.

ستيف: (يلف عينيه) لماذا؟

الزوجة: اليوم الأربعاء!

ستيف: (إيماءة ، يتكلم ببطء) حسنًا.

تم إرجاع المشكلة إلى برنامج يسمى file. تستخدم الأداة المساعدة NIX هذه قوالب لتحديد أنواع الملفات. على سبيل المثال ، إذا كان الملف يبدأ بـ%!ثم يذهب PS-Adobe-، ثم هو PostScript. يبدو أن OpenOffice يقوم بكتابة البيانات إلى مثل هذا الملف. يوم الثلاثاء أخذ زيه الرسمي %%CreationDate: (Tue MMM D hh:mm:...). حدث خطأ في نموذج ملفات Erlang JAM يعني أنه Tueتم التعرف على ملف PostScript كملف Erlang JAM ، وبالتالي ، من المفترض أنه لم يتم إرساله للطباعة.

يبدو نموذج ملف Erlang JAM كالتالي:

4 string Tue Jan 22 14:32:44 MET 1991 Erlang JAM file - version 4.2

ويجب أن تبدو هكذا:

4 string Tue\ Jan\ 22\ 14:32:44\ MET\ 1991 Erlang JAM file - version 4.2

بالنظر إلى العديد من أنواع الملفات التي يحاول هذا البرنامج التعرف عليها (أكثر من 1600) ، فإن أخطاء القوالب ليست مفاجئة. لكن ترتيب المقارنة يؤدي أيضًا إلى إيجابيات خاطئة متكررة. في هذه الحالة ، تم تعيين نوع Erlang JAM إلى نوع PostScript.

حزم الموت

بدأت في الاتصال بهم لأنهم كانوا بالضبط حزم الموت.

دخلت Star2Star في شراكة مع إحدى الشركات المصنعة للأجهزة التي أنشأت الإصدارين الأخيرين من نظام العميل المحلي لدينا.

منذ حوالي عام أصدرنا تحديثًا لهذا الجهاز. بدأ كل شيء بسيطًا جدًا ، وفقًا لقانون مور المعتاد. أكبر وأفضل وأسرع وأرخص. كان الجهاز الجديد 64 بت ، ويحتوي على ذاكرة أكبر 8 مرات ، ويحتوي على عدد أكبر من محركات الأقراص ، ويحتوي على أربعة منافذ Intel Gigabit Ethernet (الشركة المصنعة المفضلة لوحدات تحكم Ethernet). كان لدينا (ولا يزال لدينا) العديد من الأفكار حول كيفية استخدام هذه المنافذ. بشكل عام ، كانت قطعة الحديد مذهلة.

ظهرت الجدة من خلال اختبارات الأداء والوظائف. كل من السرعة عالية والموثوقية. من الناحية المثالية. ثم نشرنا المعدات ببطء في عدة مواقع اختبار. بالطبع ، بدأت المشاكل في الظهور.

يشير بحث Google السريع إلى أن وحدة التحكم Intel 82574L Ethernet بها بعض المشكلات على الأقل. على وجه الخصوص ، مشاكل EEPROM ، الأخطاء في ASPM ، الحيل مع MSI-X ، إلخ. لقد تم حل كل منهم لعدة أشهر. واعتقدنا أننا انتهينا.

لكن لا. لقد ازداد الأمر سوءًا.

اعتقدت أنني صممت ونشرت صورة البرنامج المثالية (و BIOS). ومع ذلك ، كان الواقع مختلفًا. استمرت الوحدات في الفشل. في بعض الأحيان تعافوا بعد إعادة التشغيل ، وأحيانًا لم يفعلوا ذلك. ومع ذلك ، بعد استعادة الوحدة ، يجب اختبارها.

نجاح باهر. كان الوضع غريبًا.

استمرت الشذوذ ، وفي النهاية قررت أن أشمر عن ساعدي. كنت محظوظًا بالعثور على بائع تجزئة صبور ومتعاون للغاية ظل معي على هاتفي لمدة ثلاث ساعات أثناء جمع البيانات. عند نقطة العميل هذه ، لسبب ما ، يمكن أن تسقط وحدة التحكم في Ethernet أثناء نقل حركة الصوت عبر الشبكة.

سوف أتناول هذا بمزيد من التفصيل. عندما أقول أن وحدة التحكم في Ethernet "يمكن أن تكون قد تعطلت" ، فهذا يعني أنها قد تسقط. يبدو النظام وواجهة Ethernet على ما يرام ، وبعد إرسال مقدار عشوائي من حركة المرور ، يمكن للواجهة الإبلاغ عن خطأ في الجهاز (فقدان الاتصال مع PHY) وفقدان الاتصال. خرجت المصابيح الموجودة على المفتاح والواجهة حرفيًا. كان جهاز التحكم ميتًا.

كان من الممكن إعادته إلى الحياة فقط عن طريق إيقاف تشغيل الطاقة وتشغيلها. أدت محاولة إعادة تشغيل وحدة kernel أو الجهاز إلى حدوث خطأ في فحص PCI. ظلت الواجهة معطلة حتى تم فصل الجهاز فعليًا وتوصيله مرة أخرى. في معظم الحالات ، كان هذا يعني بالنسبة لعملائنا إزالة المعدات.

أثناء تصحيح الأخطاء مع بائع التجزئة الصبور هذا ، بدأت في التوقف عن تلقي الحزم عندما تعطلت الواجهة. في النهاية ، حددت نمطًا: الحزمة الأخيرة من الواجهة كانت دائمًا 100 Trying provisional response، وكان لها طول معين دائمًا. هذا ليس كل شيء ، لقد تتبعت هذه الاستجابة (من النجمة) رجوعًا إلى طلب INVITE الأصلي الخاص بأحد هواتف الشركات المصنعة.

اتصلت بالموزع ، وجمعت الناس وأظهرت الدليل. على الرغم من أنه كان مساء الجمعة ، فقد شارك الجميع في العمل وقاموا بتجميع منصة اختبار من أجهزتنا الجديدة والهواتف من هذا المصنع.

جلسنا في غرفة الاجتماعات وبدأنا في الاتصال بأسرع ما يمكن لأصابعنا. اتضح أنه يمكننا إعادة إنتاج المشكلة! ليس في كل مكالمة وليس على كل جهاز ، ولكن من وقت لآخر تمكنا من تشغيل وحدة تحكم Ethernet ، ومن وقت لآخر لم نفعل ذلك. بعد أن أسقطنا السلطة حاولنا مرة أخرى ونجحنا. على أي حال ، كما يعلم أي شخص حاول تشخيص المشكلات الفنية ، فإن الخطوة الأولى هي إعادة إظهار المشكلة. لقد نجحنا في النهاية.

صدقني ، لقد استغرق الأمر وقتًا طويلاً. أعرف كيف يعمل مكدس OSI. أعرف كيف يتم تجزئة البرنامج. أعلم أن محتويات حزم SIP يجب ألا تؤثر على محول Ethernet. كل هذا هراء.

أخيرًا ، تمكنا من عزل مشكلة الحزم في الفترة الفاصلة بين وصولها إلى أجهزتنا وعلى منفذ النسخ المتطابق في المحول. اتضح أن المشكلة تتعلق بالطلب INVITEوليس الاستجابة 100 Trying. لا 100 Tryingتوجد استجابة في البيانات التي تم التقاطها على المنفذ المتطابق .

كان من الضروري التعامل مع هذا INVITE. هل كانت المشكلة متعلقة بالتعامل مع هذه الحزمة بواسطة عفريت مساحة المستخدمين؟ ربما كان الإرسال هو المشكلة 100 Trying؟ اقترح أحد الزملاء إغلاق تطبيق SIP ومعرفة ما إذا كانت المشكلة قائمة. بدون هذا التطبيق ، الحزم100 Tryingلم تنتقل.

كان من الضروري تحسين إرسال حزم المشكلة بطريقة ما. عزلنا الحزمة المرسلة من الهاتف وقمنا بتشغيلها INVITEباستخدام tcpreplay. انها عملت. لأول مرة منذ شهور ، تمكنا من إسقاط المنافذ عند الأمر باستخدام حزمة واحدة. كان هذا تقدمًا كبيرًا ، وقد حان الوقت للعودة إلى المنزل ، أي لتكرار مقعد الاختبار في المختبر المنزلي!

قبل أن أكمل قصتي ، أود أن أخبركم عن تطبيق رائع مفتوح المصدر وجدته. يحولك أوستيناتو إلى خبير حزم. احتمالاته لا حصر لها حرفيا. بدون هذا التطبيق ، لم أكن لأتمكن من التقدم أكثر.

مسلحًا بهذه الأداة متعددة الاستخدامات ، بدأت في التجريب. لقد اندهشت مما وجدته.

بدأ كل شيء مع غريب SIP / SDP. ألق نظرة على SDP هذا:

v=0
o=- 20047 20047 IN IP4 10.41.22.248
s=SDP data
c=IN IP4 10.41.22.248
t=0 0
m=audio 11786 RTP/AVP 18 0 18 9 9 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:9 G722/8000
a=rtpmap:9 G722/8000
a=fmtp:101 0-15
a=rtpmap:101 telephone-event/8000
a=ptime:20
a=sendrecv

نعم هذا صحيح. تم تكرار اقتراح نقل الصوت. هذه مشكلة ، لكن مرة أخرى ، ما علاقة وحدة تحكم Ethernet بهذا ؟! حسنًا ، بصرف النظر عن حقيقة أن لا شيء آخر يزيد من حجم إطار Ethernet ... لكن انتظر ، كان هناك الكثير من إطارات Ethernet الناجحة في الحزم التي يتم إرسالها. كان بعضها أصغر ، وبعضها كان أكثر. لم تكن هناك مشاكل معهم. كان علي أن أحفر أكثر. بعد بضع حيل للكونغ فو مع Ostinato ومجموعة من عمليات إعادة التوصيل الكهربائية ، تمكنت من تحديد العلاقة الإشكالية (مع إطار المشكلة). ملاحظة: سننظر في القيم السداسية العشرية.

بدأ تعطل الواجهة بواسطة قيمة بايت محددة عند إزاحة معينة. في حالتنا ، كانت القيمة السداسية العشرية 32c 0x47f. في ASCII ، 32يكون النظام الست عشري هو2... خمن من أين أتت 2.

a=ptime:20

كانت جميع نقاط تقديم الخدمة متطابقة (بما في ذلك ptime). كانت جميع عناوين URL المصدر والوجهة متطابقة. كانت الاختلافات الوحيدة هي رقم المتصل وعلاماته ومعرفات الجلسة الفريدة. تحتوي حزم المشكلات على مزيج من معرفات المكالمات والعلامات والفروع ، مما ptimeأدى إلى قيمة 2مع إزاحة 0x47f.

فقاعة! باستخدام المعرفات والعلامات والفروع الصحيحة (أو أي بريد عشوائي عشوائي) ، يمكن أن تتحول "الحزمة الجيدة" إلى حزمة "قاتلة" بمجرد ptimeانتهاء السطر عند عنوان معين. كان غريبا جدا.

عند إنشاء الحزم ، جربت قيمًا سداسية عشرية مختلفة. تبين أن الوضع أكثر تعقيدًا. اتضح أن سلوك وحدة التحكم يعتمد كليًا على هذه القيمة المحددة الموجودة في العنوان المحدد في الحزمة الأولى المستلمة. كانت الصورة مثل هذا:

 0x47f = 31 HEX (1 ASCII) -  
 0x47f = 32 HEX (2 ASCII) -  
 0x47f = 33 HEX (3 ASCII) -  
 0x47f = 34 HEX (4 ASCII) -  (inoculation)

عندما قلت "لا تؤثر" ، قصدت ليس فقط لا تقتل الواجهة ، ولكن أيضًا لا تلقيح (أكثر أو أقل). وعندما أقول أن "الواجهة تتعطل" ، حسنًا ، أتذكر وصفي؟ الواجهة تحتضر. تماما.

بعد اختبارات جديدة ، وجدت أن المشكلة لا تزال قائمة مع كل إصدار من Linux يمكنني العثور عليه ، مع FreeBSD ، وحتى تشغيل الجهاز بدون وسائط قابلة للتمهيد! كان الأمر يتعلق بالأجهزة وليس بنظام التشغيل. نجاح باهر.

علاوة على ذلك ، بمساعدة Ostinato ، تمكنت من إنشاء إصدارات مختلفة من الحزمة القاتلة: HTTP POST ، طلب ارتداد ICMP ، وغيرها. تقريبا كل ما أردته. باستخدام خادم HTTP معدل الذي أنشأ البيانات في قيم البايت (استنادًا إلى العناوين والمضيف وما إلى ذلك) ، كان من السهل إنشاء طلب HTTP رقم 200 لاحتواء حزمة الموت وقتل أجهزة العميل خلف جدار الحماية!

لقد شرحت بالفعل مدى غرابة الوضع برمته. لكن أغرب شيء كان اللقاح. اتضح أنه إذا كانت الحزمة الأولى المستلمة تحتوي على أي قيمة (من اختبارها) ، باستثناء 1، 2أو 3، إذا أصبحت الواجهة غير معرضة لموت أي حزم (تحتوي على القيمة 2أو 3). علاوة على ذلك ، كانت الرموز والسمات ptimeمن مضاعفات 10: 10، 20، 30، 40. اعتمادًا على مجموعة معرف المكالمة ، والعلامة ، والفرع ، و IP ، و URI ، والمزيد (مع SDP عربات التي تجرها الدواب) ، ptimeتصطف هذه السمات الصالحة في تسلسل مثالي. لا يصدق!

أصبح من الواضح فجأة سبب حدوث المشكلة بشكل متقطع. إنه لأمر مدهش أنني تمكنت من اكتشاف ذلك. أنا أعمل مع الشبكات منذ 15 عامًا ولم أر شيئًا من هذا القبيل. وأشك في أن أراك مرة أخرى. نأمل ...

لقد اتصلت باثنين من المهندسين في Intel وأرسلت إليهم عرضًا توضيحيًا حتى يتمكنوا من إعادة إنتاج المشكلة. بعد إجراء التجارب لمدة أسبوعين ، اكتشفوا أن المشكلة كانت مع EEPROM في وحدات التحكم 82574L. أرسلوا لي EEPROM جديد وأداة كتابة. لسوء الحظ ، لم نتمكن من توزيعها ، وإلى جانب ذلك ، كان من الضروري تفريغ وإعادة تحميل وحدة النواة e1000e ، لذلك لم تكن الأداة مناسبة لبيئتنا. لحسن الحظ (بقليل من المعرفة بتخطيط EEPROM) تمكنت من كتابة نص باش ثم بطريقة سحريةethtoolحفظ القيم "الثابتة" وتسجيلها في الأنظمة التي يظهر فيها الخطأ نفسه. الآن يمكننا تحديد الأجهزة التي بها مشكلة. لقد اتصلنا ببائعنا لتطبيق التصحيح على جميع الأجهزة قبل شحنه إلينا. من غير المعروف عدد وحدات تحكم Intel Ethernet التي تم بيعها بالفعل.

منصة نقالة أخرى

في عام 2005 ، واجهت مشكلة غير مبررة في العمل. بعد يوم من الإغلاق غير المخطط له (بسبب الإعصار) ، بدأت في تلقي مكالمات من المستخدمين الذين كانوا يشكون من المهلات عند الاتصال بقاعدة البيانات. نظرًا لأن لدينا شبكة بسيطة جدًا لـ 32 عقدة وبنطاق ترددي غير مستخدم عمليًا ، فقد شعرت بالانزعاج من أن الخادم الذي يحتوي على قاعدة البيانات يتم اختباره بشكل طبيعي لمدة 15-20 دقيقة ، ثم جاءت ردود "طلب المهلة المحددة" في غضون دقيقتين تقريبًا. كان هذا الخادم يقوم بتشغيل أدوات مراقبة الأداء والأدوات الأخرى وأعمال ping من مواقع مختلفة. باستثناء الخادم ، يمكن لبقية الأجهزة التواصل مع أعضاء الشبكة الآخرين طوال الوقت. لقد بحثت عن مفتاح أو اتصال فاشل لكن لم أجد تفسيرًا للفشل العشوائي والمتقطع.

طلبت من أحد الزملاء مشاهدة المصابيح الموجودة على المفتاح في المستودع بينما كنت أتتبع الأجهزة المختلفة وأعيد توصيلها. قال لي أحد الزملاء عبر الراديو "لقد توقف هذا ، هذا الشخص استيقظ" استغرق 45-50 دقيقة. سألته إذا كان قد لاحظ أي نمط.

- نعم لاحظت. لكنك ستعتقد أنني مجنون. في كل مرة تقوم فيها الرافعة الشوكية بإخراج منصة نقالة من قاعة الشحن ، تحدث المهلة بعد ثانيتين على الخادم.

- ماذا؟؟؟

- بلى. ويتم استعادة الخادم عندما يبدأ المُحمل في شحن طلب جديد.

ركضت لإلقاء نظرة على الرافعة الشوكية وكنت على يقين من أنه كان يشير إلى إكمال الطلب بنجاح من خلال تشغيل بعض المغنطرون العملاق. مما لا شك فيه أن الموجات الكهرومغناطيسية الصادرة عن المكثف تؤدي إلى انقطاع في استمرارية الزمكان وتقطع مؤقتًا تشغيل بطاقة شبكة الخادم الموجودة في غرفة أخرى على بعد 50 مترًا. لا. تقوم الرافعة الشوكية ببساطة بتكديس الصناديق الكبيرة على المنصة النقالة ، مع وجود صناديق أصغر في الأعلى ، أثناء مسح كل صندوق باستخدام ماسح ضوئي للرمز الشريطي لاسلكي. آها! من المحتمل أن يكون الماسح الضوئي هو الذي يصل إلى خادم قاعدة البيانات ، مما يتسبب في فشل الاستعلامات الأخرى. لا. راجعت ووجدت أن الماسح الضوئي لا علاقة له به. تم تكوين الموجه اللاسلكي ومزود الطاقة غير المنقطعة (UPS) الخاص به في قاعة الشحن بشكل صحيح ويعملان بشكل طبيعي. كان السبب شيئًا آخر ، لأنه قبل الإغلاق بسبب الإعصار ، كان كل شيء يعمل بشكل جيد.

بمجرد أن بدأت المهلة التالية ، ركضت إلى صالة الشحن وشاهدت اللودر يملأ البليت التالي. بمجرد أن وضع أربعة صناديق كبيرة من الشامبو على صينية فارغة ، توقف الخادم مرة أخرى! لم أكن أؤمن بعبثية ما كان يحدث ، ولمدة خمس دقائق أخرى أزلت ووضعت علب الشامبو بنفس النتيجة. كنت على وشك السقوط على ركبتيّ وأدعو الله أن يرحمني الإنترانت عندما لاحظت أن الموجه في صالة الشحن كان معلقًا بحوالي 30 سم تحت مستوى الصناديق على البليت. هناك دليل!

عندما تم وضع الصناديق الكبيرة على منصة نقالة ، فقد جهاز التوجيه اللاسلكي خط الرؤية إلى المستودع الخارجي. بعد عشر دقائق ، قمت بحل المشكلة. إليكم ما حدث. أثناء الإعصار ، كان هناك انقطاع في التيار الكهربائي أدى إلى سقوط الجهاز الوحيد غير المتصل بـ UPS - جهاز توجيه لاسلكي تجريبي في مكتبي. حولته الإعدادات الافتراضية بطريقة ما إلى مكرر لجهاز التوجيه اللاسلكي الوحيد المعلق في قاعة الشحن. لا يمكن للجهازين التواصل مع بعضهما البعض إلا في حالة عدم وجود منصة نقالة بينهما ، ولكن حتى ذلك الحين لم تكن الإشارة قوية جدًا. عندما تحدثت أجهزة التوجيه ، قاموا بإنشاء حلقة في شبكتي الصغيرة ، ثم فقدت جميع الحزم الأخرى إلى خادم قاعدة البيانات. كان للخادم مفتاح تبديل خاص به من جهاز التوجيه الرئيسي ، وبالتالي ، باعتباره عقدة شبكة ، كان بعيدًا جدًا.كانت معظم أجهزة الكمبيوتر الأخرى على نفس المحول ذي 16 منفذًا ، لذا يمكنني إجراء اختبار الاتصال بينها دون أي مشاكل.

في ثانية واحدة ، قمت بحل مشكلة كنت أعذبها لمدة أربع ساعات: قمت بإيقاف تشغيل الطاقة عن جهاز التوجيه التجريبي. لم يكن هناك المزيد من المهلات على الخادم.

مثل فيلم Tron ، فقط على كمبيوتر Apple IIgs

كان ترون أحد أفلامي المفضلة عندما كنت طفلاً ، وتم تصويره في أوائل الثمانينيات. تحدثت عن مبرمج تم "رقمنته" وتم استيعابه في عالم الكمبيوتر الذي تسكنه برامج مخصصة. انضم بطل الرواية إلى مجموعة مقاومة في محاولة للإطاحة ببرنامج التحكم الرئيسي للاضطهاد (MCP) ، وهو برنامج متمرد تطور ، واكتسب رغبة في السلطة وحاول الاستيلاء على نظام الكمبيوتر في البنتاغون.

في واحدة من أكثر المشاهد إثارة للإعجاب في البرامج ، تتسابق الشخصيات على دراجات خفيفة - سيارات ذات عجلتين تشبه الدراجات النارية التي تترك الجدران خلفها. أجبر أحد الأبطال مقاتلي العدو على الاصطدام بالحائط في الحلبة ، مما أحدث ثقبًا. تعامل الأبطال مع خصومهم وفروا عبر الفتحة إلى الحرية - وهي الخطوة الأولى نحو الإطاحة بحزب MCP.

عندما شاهدت الفيلم ، لم يكن لدي أي فكرة أنه بعد سنوات سأعيد عن غير قصد إنشاء عالم Tron والبرامج المتمردة وكل شيء آخر على كمبيوتر Apple IIgs.

و هكذا حدثت الحكاية. عندما بدأت تعلم البرمجة ، قررت إنشاء لعبة دورة خفيفة من Tron. قمت مع صديقي ماركو بكتابة برنامج عن Apple IIgs في ORCA / Pascal و 65816 المجمع ، أثناء اللعبة ، تم طلاء الشاشة باللون الأسود بإطار أبيض. يمثل كل سطر أحد اللاعبين. عرضنا نتائج المباريات على التوالي في أسفل الشاشة. من الناحية الرسومية ، لم يكن البرنامج الأكثر تقدمًا ، لكنه كان بسيطًا وممتعًا. بدت هكذا:

دعمت اللعبة ما يصل إلى أربعة لاعبين إذا جلسوا أمام لوحة مفاتيح واحدة. كان غير مريح ، لكنه نجح. نادرًا ما كنا قادرين على الحصول على عدد كافٍ من الأشخاص لاستخدام جميع دورات الضوء الأربع ، لذلك أضاف ماركو لاعبين يتحكم فيهم الكمبيوتر ويمكنهم المنافسة بشكل معقول.

سباق التسلح

كانت اللعبة بالفعل مضحكة للغاية ، لكننا أردنا التجربة. لقد أضفنا صواريخ لمنح اللاعبين فرصة للهروب من حادث وشيك. كما وصف ماركو لاحقًا:

يمتلك كل من البشر والذكاء الاصطناعي ثلاثة صواريخ يمكن استخدامها أثناء اللعبة. عندما اصطدم الصاروخ بالجدار ، حدث "انفجار" طليت خلفيته باللون الأسود ، وبذلك أزال أجزاء من المسار الذي خلفته دورات الضوء السابقة.

وسرعان ما يمكن للاعبين وأجهزة الكمبيوتر أن يشقوا طريقهم للخروج من المواقف الصعبة بالصواريخ. على الرغم من أن أنصار ترون سوف يسخرون من هذا ، إلا أن البرامج في الفيلم لم تكن تتمتع برفاهية الصواريخ.

الهروب

كما هو الحال مع جميع الأحداث غير العادية والغريبة ، كان الأمر غير متوقع أيضًا.

ذات مرة ، عندما كنت أنا وماركو نلعب ضد اثنين من لاعبي الكمبيوتر ، حاصرنا إحدى حلقات الذكاء الاصطناعي بين جدارها والحافة السفلية للشاشة. توقع وقوع حادث وشيك ، أطلق صاروخًا ، كما كان يفعل دائمًا من قبل. لكن هذه المرة ، بدلًا من الحائط ، أطلق النار على حافة الشاشة ، التي بدت وكأنها أثر لإحدى دورات الضوء. أصاب الصاروخ الحدود ، وترك فجوة بحجم دورة الضوء ، وخرج الكمبيوتر على الفور من الملعب من خلاله. لقد حدقنا في ارتباك في دورة الضوء أثناء مرورها عبر خط النتيجة. لقد تجنب بسهولة الاصطدام بالرموز ثم غادر الشاشة تمامًا.

وبعد ذلك مباشرة ، انهار النظام.

تمايلت عقولنا ونحن نحاول فهم ما حدث. وجد الكمبيوتر طريقة للخروج من اللعبة. عندما غادرت دورة الضوء الشاشة ، تسربت إلى ذاكرة الكمبيوتر ، تمامًا كما في الفيلم. سقط فكينا عندما أدركنا ما حدث.

ماذا فعلنا عندما اكتشفنا وجود خلل في برنامجنا يمكن أن يؤدي إلى تعطل النظام بأكمله بشكل منتظم؟ لقد فعلناها من جديد حاولنا أولاً الخروج من الحدود بأنفسنا. ثم أجبروا الكمبيوتر على الهرب مرة أخرى. في كل مرة تم تكريمنا بتعطل نظام ساحر. في بعض الأحيان كان ضوء محرك الأقراص يومض بينما كان محرك الأقراص يتذمر بلا نهاية. في أحيان أخرى ، تمتلئ الشاشة بأحرف لا معنى لها ، أو يصدر المتحدث صريرًا أو همهمة منخفضة. وأحيانًا حدث كل هذا مرة واحدة ، وكان الكمبيوتر في حالة من الفوضى الكاملة.

لماذا حدث هذا؟ لفهم هذا ، دعنا نلقي نظرة على بنية كمبيوتر Apple IIgs.

(Un) ذاكرة محمية

لا يحتوي نظام التشغيل Apple IIgs على ذاكرة محمية ، والتي ظهرت في أنظمة التشغيل اللاحقة عندما تم تخصيص مناطق من الذاكرة لبرنامج ما وحمايتها من الوصول الخارجي. لذلك ، يمكن لبرنامج تحت Apple IIgs قراءة وكتابة أي شيء (باستثناء ROM). استخدمت IIgs الإدخال / الإخراج المرتبط بالذاكرة للوصول إلى أجهزة مثل محرك الأقراص المرنة ، لذلك كان من الممكن تنشيط محرك الأقراص المرنة من خلال القراءة من منطقة معينة من الذاكرة. سمحت هذه البنية للبرامج الرسومية بالقراءة والكتابة مباشرة على ذاكرة الشاشة.

استخدمت اللعبة أحد أوضاع رسومات Apple IIgs - Super Hi-Res: دقة مذهلة تبلغ 320 × 200 بكسل مع لوحة من 16 لونًا. لتحديد لوحة ، حدد المبرمج 16 إدخالًا (مرقمة من 0 إلى 15 أو من $ 0 إلى F بتنسيق سداسي عشري) لقيم ألوان 12 بت. للرسم على الشاشة ، يمكنك قراءة الألوان وكتابتها مباشرة في ذاكرة الفيديو.

خوارزمية كشف الاصطدام

لقد استفدنا من هذه الميزة وقمنا بتنفيذ كاشف الأعطال عن طريق القراءة مباشرة من ذاكرة الفيديو. تحسب اللعبة لكل دورة ضوئية موقعها التالي بناءً على الاتجاه الحالي ، وقراءة هذا البكسل من ذاكرة الفيديو. إذا كان الموضع فارغًا ، أي يمثله بكسل أسود (إدخال في لوحة 0 دولار) ، فستستمر اللعبة. ولكن إذا تم اتخاذ الموقف ، فإن اللاعب قد اصطدم بدورة الضوء أو الإطار الأبيض للشاشة (الإدخال في اللوحة 15 أو $ F). مثال:

تظهر الزاوية العلوية اليسرى من الشاشة هنا. يشير اللون $ F إلى حد أبيض ، واللون $ 1 يشير إلى دورة الضوء الأخضر للاعب. يتحرك إلى اليسار كما هو موضح بالسهم ، أي البكسل التالي فارغ ، ولونه 0 دولار. إذا استمر اللاعب في التحرك في هذا الاتجاه لأكثر من دورة ، فسوف يصطدم بجدار (اللون $ F) وينكسر.

تجاوز

قامت خوارزمية تحديد البكسل التالي باستخدام الرياضيات المجمعة بحساب عنوان الذاكرة بسرعة بكسل واحد أعلى أو أسفل أو يسار أو يمين البكسل الحالي. نظرًا لأن أي بكسل على الشاشة كان عنوانًا في الذاكرة ، فقد حسبت الخوارزمية ببساطة عنوانًا جديدًا لقراءته. وعندما غادرت دورة الضوء الشاشة ، حددت الخوارزمية مكانًا في ذاكرة النظام للتحقق من وجود تصادم بجدار. وهذا يعني أن دورة الضوء كانت تعبر الآن ذاكرة النظام ، وتعمل بلا فائدة على البتات و "تحطم" في الذاكرة.

الكتابة في مواقع عشوائية في ذاكرة النظام ليست قرارًا معماريًا حكيمًا. مما لا يثير الدهشة أن اللعبة تعطلت بسبب هذا. لن يركب اللاعب البشري بشكل أعمى وعادة ما يصطدم على الفور ، مما يحد من نطاق مشاكل النظام. والذكاء الاصطناعي ليس لديه مثل هذا الضعف. يقوم الكمبيوتر على الفور بمسح المواضع حوله لتحديد ما إذا كان يصطدم بجدار ويغير اتجاهه. وهذا يعني ، من وجهة نظر الكمبيوتر ، أن ذاكرة النظام لا تختلف عن ذاكرة الشاشة. كما وصف ماركو:

, , . , , 0. «» , . «», - - , , — . , - , .

نتيجة لذلك ، لم نقم فقط بإعادة إنشاء سباق دورة الضوء من الفيلم ، ولكن أيضًا الهروب نفسه. كما في الفيلم ، كان للهروب عواقب وخيمة.

يصعب تكرار هذا اليوم ، لأن أنظمة التشغيل قد اكتسبت ذاكرة محمية. لكن ما زلت أتساءل عما إذا كانت هناك برامج مثل ترون تحاول الهروب من "المساحات المحمية" في محاولة لمنع كود الذكاء الاصطناعي المتمرد من الاستيلاء على البنتاغون.

أعتقد أنه لمعرفة ذلك ، نحن بحاجة إلى انتظار اختراع رقمنة الوعي.

اجلس لتسجيل الدخول

يعرف كل مبرمج أن التصحيح صعب. على الرغم من أن الوظيفة تبدو بسيطة بشكل مخادع بالنسبة لمصححات الأخطاء الممتازة. يصف المبرمجون المذهولون الخطأ الذي يقضون ساعات في اكتشافه ، ويطرح المعلم بعض الأسئلة ، وبعد بضع دقائق يرى المبرمجون الشفرة الخاطئة أمامهم. لا ينسى خبير التصحيح أن هناك دائمًا تفسيرًا منطقيًا ، بغض النظر عن مدى غموض النظام للوهلة الأولى.

يتضح هذا الموقف من خلال قصة حدثت في مركز أبحاث IBM Yorktown Heights. قام المبرمج مؤخرًا بتركيب محطة عمل جديدة. كان كل شيء على ما يرام عندما كان جالسًا أمام الكمبيوتر ، لكنه لم يتمكن من تسجيل الدخول أثناء وقوفه. تم تكرار هذا السلوك دائمًا: كان المبرمج يسجل الدخول دائمًا أثناء الجلوس ، أثناء الوقوف - لم يستطع حتى مرة واحدة.

كثير منا جلس هناك وتساءل. كيف يمكن للكمبيوتر معرفة ما إذا كانوا يقفون أمامه أم جالسين؟ ومع ذلك ، يعرف المصححون الجيدون أنه يجب أن يكون هناك سبب. أول ما يتبادر إلى الذهن هو الكهرباء. سلك مكسور تحت السجاد أم كهرباء ساكنة؟ ولكن نادرًا ما تتكرر المشكلات الكهربائية بنسبة 100٪ من الوقت. أخيرًا طرح أحد الزملاء السؤال الصحيح: كيف قام المبرمج بتسجيل الدخول أثناء الجلوس والوقوف؟ جربها بنفسك.

كان السبب هو لوحة المفاتيح: تم عكس الزرين. عندما كان المبرمج جالسًا ، كان يكتب بشكل أعمى ، وتذهب المشكلة دون أن يلاحظها أحد. وعندما وقف ، أربكه ، بحث عن أزرار وضغط عليها. مسلحًا بهذا التلميح ومفك البراغي ، قام خبير تصحيح الأخطاء بتبديل الأزرار وعمل كل شيء.

عمل النظام المصرفي المعمول به في شيكاغو بشكل جيد لعدة أشهر. لكنها توقفت بشكل غير متوقع عندما تم استخدامها لأول مرة لمعالجة البيانات الدولية. ظل المبرمجون يدورون حول الشفرة لعدة أيام ، لكنهم لم يتمكنوا من العثور على أمر واحد أدى إلى إنهاء البرنامج. عندما ألقوا نظرة فاحصة على سلوكها ، وجدوا أن البرنامج سينتهي عند إدخال بيانات الإكوادور. أظهر التحليل أنه عندما يكتب المستخدم اسم العاصمة (كيتو) ، فسره البرنامج على أنه أمر خروج!

في أحد الأيام ، صادف بوب مارتن نظامًا "يعمل مرة واحدة مرتين". لقد عالجت المعاملة الأولى بشكل صحيح ، وكانت هناك مشاكل صغيرة في جميع المعاملات اللاحقة. عندما أعيد تشغيل النظام ، قام مرة أخرى بمعالجة المعاملة الأولى بشكل صحيح وفشل في جميع المعاملات اللاحقة. عندما وصف بوب هذا السلوك بأنه "يعمل مرة واحدة مرتين" ، أدرك المطورون على الفور أنهم بحاجة إلى البحث عن متغير تمت تهيئته بشكل صحيح عند تحميل البرنامج ، ولكن لم تتم إعادة تعيينه بعد المعاملة الأولى. في جميع الحالات ، سمحت الأسئلة الصحيحة للمبرمجين الحكماء بالتعرف بسرعة على الأخطاء غير السارة: "ماذا فعلت بشكل مختلف عندما كنت واقفًا جالسًا؟ أرني كيف تقوم بتسجيل الدخول في كلتا الحالتين "،" ما الذي أدخلته بالضبط قبل نهاية البرنامج؟ " "هل عمل البرنامج بشكل صحيح قبل بدء الأعطال؟ كم مرة؟ "

قال ريك ليمونز إن أفضل درس تعلمه عن تصحيح الأخطاء كان عندما شاهد أداء الساحر. لقد قام بالعشرات من الحيل المستحيلة ، وشعر ليمون أنه يؤمن بها. ثم ذكّر نفسه بأن المستحيل غير ممكن ، واختبر كل حيلة لإثبات هذا التناقض الواضح. بدأ ليمون بما كان حقيقة لا تتزعزع - قوانين الفيزياء ، ومنها بدأ في البحث عن تفسيرات بسيطة لكل خدعة. هذا الموقف يجعل Lemons أحد أفضل مصححي الأخطاء الذين قابلتهم.

أفضل كتاب تصحيح أخطاء في رأيي هو The Medical Detectives، كتبه بيرتون رويشي ونشره بينجوين عام 1991. أبطال الكتاب يصححون أخطاء الأنظمة المعقدة ، من شخص مريض إلى مدن مريضة للغاية. يمكن استخدام طرق حل المشكلات المستخدمة بشكل مباشر في تصحيح أخطاء أنظمة الكمبيوتر. هذه القصص الحقيقية رائعة مثل أي قصة خيالية.

500 ميل البريد الإلكتروني القضية

هنا موقف بدا غير معقول ... كدت أرفض الحديث عنه لأنه دراجة رائعة للمؤتمرات. لقد قمت بتعديل القصة قليلاً لحماية الجاني ، ولتجاهل التفاصيل غير الملائمة والمملة ، وبشكل عام لجعل القصة أكثر جاذبية.

منذ عدة سنوات ، كنت أخدم نظام بريد إلكتروني في الحرم الجامعي. اتصل بي رئيس دائرة الإحصاء.

- لدينا مشكلة في إرسال الرسائل.

- ما هي المشكلة؟

"لا يمكننا إرسال رسائل أبعد من 500 ميل.

لقد اختنقت على قهوتي.

- غير مفهوم.

"لا يمكننا إرسال رسائل من القسم لأكثر من 500 ميل. في الواقع ، أبعد قليلاً. ما يقرب من 520 ميلا. لكن هذا هو الحد.

أجبته "حسنًا ... في الواقع ، البريد الإلكتروني لا يعمل بهذه الطريقة" ، محاولًا السيطرة على الذعر في صوتي. لا يمكنك إظهار الذعر في محادثة مع رئيس قسم ، حتى مع رئيس قسم مثل قسم الإحصاء. - لماذا قررت أنه لا يمكنك إرسال رسائل أبعد من 500 ميل؟ أجاب بثقل: "

لم أقرر ". - كما ترى ، عندما لاحظنا ما كان يحدث قبل أيام قليلة ...

- هل انتظرت بضعة أيام؟ قطعته بصوت يرتجف. - وأنت لا تستطيع إرسال الرسائل كل هذا الوقت؟

- يمكننا أن نرسل. فقط لا مزيد ...

"" خمسمائة ميل ، نعم ، "انتهيت من أجله. - واضح. لكن لماذا لم تتصل في وقت سابق؟

"حسنًا ، حتى هذه اللحظة لم يكن لدينا بيانات كافية للتأكد مما كان يحدث.

بالضبط ، هذا هو رئيس الإحصاء .

- على أي حال ، طلبت من أحد علماء الإحصاء العمل مع هذا ...

- الجيوستاتيون ...

- نعم ، وقد أعدت خريطة توضح نصف القطر الذي يمكننا من خلاله إرسال الرسائل ، ما يزيد قليلاً عن 500 ميل. هناك العديد من الأماكن في هذه المنطقة حيث لا تصل رسائلنا على الإطلاق أو بشكل دوري ، ولكن خارج النطاق الجغرافي لا يمكننا إرسال أي شيء على الإطلاق.

قلت: "أنا أرى" ، وأسقطت رأسي في يدي. - عندما بدأ؟ لقد قلت ذلك قبل أيام قليلة ، لكننا لم نغير أي شيء في أنظمتك.

- جاء استشاري ، وقام بتصحيح وإعادة تشغيل الخادم الخاص بنا. لكنني اتصلت به ، وقال إنه لم يمس نظام البريد.

أجبته ، "حسنًا ، دعني ألقي نظرة وأعاود الاتصال بك" ، وبالكاد أعتقد أنني كنت أشارك في مثل هذا الشيء. اليوم لم يكن الأول من أبريل. حاولت أن أتذكر ما إذا كان هناك من يدين لي بمزحة.

لقد قمت بتسجيل الدخول إلى خادم قسمهم وأرسلت بعض رسائل التحقق عبر البريد الإلكتروني. حدث هذا في مثلث أبحاث نورث كارولينا ، ووصلت الرسالة إلى صندوق بريدي دون أي مشاكل. وكذلك فعلت الرسائل المرسلة إلى ريتشموند وأتلانتا وواشنطن. كما تم إرسال رسالة إلى برينستون (400 ميل).

ولكن بعد ذلك أرسلت رسالة إلى ممفيس (600 ميل). لم يأت. في بوسطن ، لم يأتِ. في ديترويت ، لم يأتِ. أخرجت دفتر العناوين الخاص بي وبدأت في إرسال الرسائل من خلاله. وصلت إلى نيويورك (420 ميلاً) ، لكنها لم تأت إلى بروفيدنس (580 ميلاً).

بدأت أشك في سلامتي. كتبت إلى صديق في ولاية كارولينا الشمالية كان مقدم الخدمة في سياتل. لحسن الحظ ، لم تصل الرسالة. إذا كانت المشكلة تتعلق بموقع المستلمين ، وليس خوادم البريد الخاصة بهم ، فربما كنت قد انفجرت في البكاء.

بعد معرفة أن المشكلة موجودة (بشكل لا يصدق) وقابلة للتكرار ، بدأت في تحليل ملف sendmail.cf. بدا بخير. كل عادة. قارنته بـ sendmail.cf في دليلي الرئيسي. لم يكن هناك فرق - كان الملف الذي كتبته. وكنت متأكدًا تمامًا من أنني لم أقم بتضمين الخيار FAIL_MAIL_OVER_500_MILES. في حالة ارتباك ، قمت بإرسال منفذ SMTP عبر الهاتف. استجاب الخادم بسعادة مع لافتة Sendmail من SunOS.

انتظر ... لافتة Sendmail من SunOS؟ في ذلك الوقت ، كانت Sun لا تزال تشحن Sendmail 5 مع نظام التشغيل الخاص بها ، على الرغم من أن Sendmail 8 كان بالفعل مخدرًا بالكامل. منذ أن كنت مسؤول نظام جيد ، قدمت Sendmail 8 كمعيار. أيضًا ، منذ أن كنت مسؤول نظام جيد ، كتبت sendmail.cf ، والذي استخدم خيارات التوثيق الذاتي الطويلة الرائعة والأسماء المتغيرة المتوفرة في Sendmail 8 ، بدلاً من رموز الترقيم المشفرة المستخدمة في Sendmail 5.

وسقط كل شيء في مكانه. واختنقت من قهوتي المبردة بالفعل مرة أخرى. يبدو أنه عندما قام المستشار "بتصحيح الخادم" ، قام بترقية إصدار SunOS الذي طرح منه إصدارًا أقدم من Sendmail. لحسن الحظ ، نجا ملف sendmail.cf ، لكنه لم يتطابق الآن.

اتضح أن Sendmail 5 - على الأقل الإصدار المشحون من Sun مع عدد من التحسينات - يمكنه العمل مع sendmail.cf لـ Sendmail 8 ، لأن معظم القواعد هي نفسها. لكن خيارات التكوين الطويلة الجديدة لم يتم التعرف عليها الآن وإهمالها. ونظرًا لعدم وجود قيم افتراضية لمعظمها في ملف Sendmail الثنائي ، لم يجد البرنامج أي قيم مناسبة في sendmail.cf وأعاد تعيينها إلى الصفر.

كانت إحدى هذه القيم الصفرية هي مهلة الاتصال بخادم SMTP البعيد. بعد إجراء بعض التجارب ، اتضح أنه في هذا الجهاز المعين ، في ظل الحمل العادي ، تؤدي المهلة الصفرية إلى انقطاع الاتصال في أكثر من ثلاثة أجزاء من الألف من الثانية بقليل.

في ذلك الوقت ، كانت شبكة الحرم الجامعي عبارة عن مفاتيح تبديل كاملة. لم تتأخر الحزمة الصادرة حتى تصل إلى جهاز التوجيه على الجانب الآخر عبر بروتوكول POP. أي أن مدة الاتصال بمضيف بعيد محمّل بشكل ضعيف في شبكة مجاورة تعتمد إلى حد كبير على المسافة المقطوعة بسرعة الضوء ، وليس على التأخيرات العشوائية بواسطة أجهزة التوجيه.

شعرت بالدوار قليلا ، دخلت في سطر الأوامر:

$ units
1311 units, 63 prefixes

You have: 3 millilightseconds
You want: miles
        * 558.84719
        / 0.0017893979

"500 ميل أو أكثر".

يتبع.

فولكلور المبرمجين والمهندسين (الجزء الثاني)

المزيد من السحر