هايزنبج

في مصطلحات برمجة الحاسوب ، يُعرف خطأ هايزنبرغ بأنه خلل برمجي يختفي أو يتغير سلوكه عند محاولة دراسته. ^{[ 1 ]} ويُشتق المصطلح من اسم فيرنر هايزنبرغ ، الفيزيائي الذي وضع مبدأ عدم اليقين ، وهو إشارة إلى تأثير المراقب ، الذي ينص على أن مراقبة النظام تُغير حالته حتمًا. في الإلكترونيات، يُستخدم مصطلح " تأثير المسبار" لوصف هذا الخطأ ، حيث يؤدي توصيل مسبار اختبار بجهاز ما إلى تغيير سلوكه. وقد وُجهت انتقادات لهذا المصطلح لأنه يخلط بين مبدأ عدم اليقين لهايزنبرغ (الذي استمد منه اسمه) وتأثير المراقب في ميكانيكا الكم ، وهما مفهومان مختلفان. ^{[ 2 ]}

وقد تم اقتراح مصطلحات مشابهة، مثل "bohrbug" و"mandelbug" ^{[ 3 ] [ 4 ] [ 5 ]} و"hindenbug" و"schrödinbug" ^{[ 6 ] [ 7 ]} (انظر قسم المصطلحات ذات الصلة )، من حين لآخر لوصف أنواع أخرى من أخطاء البرمجيات غير المألوفة، وأحيانًا على سبيل المزاح. ^{[ 8 ] [ 9 ]}

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

من الأمثلة الشائعة على أخطاء هايزن، الخطأ الذي يظهر عند تجميع البرنامج باستخدام مُجمِّع مُحسِّن ، ولكنه لا يظهر عند تجميع البرنامج نفسه بدون تحسين (كما هو شائع عند فحصه باستخدام مُصحِّح الأخطاء). أثناء تصحيح الأخطاء، غالبًا ما تُنقل القيم التي يحتفظ بها البرنامج المُحسَّن عادةً في السجلات إلى الذاكرة الرئيسية. قد يؤثر هذا، على سبيل المثال، على نتيجة مقارنات الأعداد العشرية ، لأن القيمة الموجودة في الذاكرة قد يكون نطاقها ودقتها أقل من القيمة الموجودة في السجل . وبالمثل، قد تنشأ أخطاء هايزن بسبب آثار جانبية في تعابير الاختبار المستخدمة في تأكيدات وقت التشغيل في لغات مثل C و C++ ، حيث لا يتم تقييم تعبير الاختبار عند تعطيل التأكيدات في كود الإنتاج باستخدام الماكرو.NDEBUG

من الأسباب الشائعة الأخرى لأخطاء هايزن: استخدام قيمة متغير غير مُهيأ (والذي قد يُغير عنوانه أو قيمته الأولية أثناء التصحيح)، أو تتبع مؤشر غير صالح (والذي قد يُشير إلى مكان مختلف أثناء التصحيح). كما تسمح أدوات التصحيح عادةً باستخدام نقاط التوقف أو توفر واجهات مستخدم أخرى تُؤدي إلى تنفيذ شفرة مصدرية إضافية (مثل دوال الوصول إلى الخصائص) خلسةً، مما قد يُغير حالة البرنامج. ^{[ 10 ]}

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

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

يمكن اعتبار أخطاء هايزنبج أمثلة على تأثير المراقب في تكنولوجيا المعلومات . قد يلقي المبرمجون المحبطون باللوم على طور القمر في حدوث خطأ هايزنبج ، ^{[ 11 ]} أو (إذا حدث مرة واحدة فقط) قد يفسرونه على أنه خطأ عابر ناتج عن جسيمات ألفا أو الأشعة الكونية التي تؤثر على الأجهزة، وهي ظاهرة موثقة جيدًا تُعرف باسم تأثيرات الحدث الفردي .

على النقيض من ذلك، فإنّ " حشرة بور " هي "حشرة جيدة وصلبة". ومثل نموذج ذرة بور الحتمي ، فإنها لا تُغيّر سلوكها ويمكن اكتشافها بسهولة نسبية. ^{[ 12 ] [ 13 ]}

خطأ ماندل (نسبةً إلى شكل بينوا ماندلبروت الكسوري ) هو خطأ برمجي تكون أسبابه معقدة للغاية لدرجة أنها تتحدى الإصلاح، أو تجعل سلوكه يبدو فوضويًا أو حتى غير حتمي . ^{[ 3 ]} يشير المصطلح أيضًا إلى خطأ برمجي يُظهر سلوكًا كسريًا (أي التشابه الذاتي ) من خلال الكشف عن المزيد من الأخطاء (كلما تعمق المطور في الكود لإصلاحه، كلما وجد المزيد من الأخطاء).

خطأ شرودنغر ( نسبةً إلى إرفين شرودنغر وتجربته الفكرية ) هو خطأ يظهر في البرامج قيد التشغيل بعد أن يلاحظ المبرمج أن الكود لم يكن من المفترض أن يعمل في المقام الأول . ^{[ 6 ]}

إن خلل هيندنبورغ ^{[ 14 ]} (سمي على اسم كارثة هيندنبورغ ) هو خلل ذو سلوك كارثي.

خطأ هيغز -بوغسون ^{[ 15 ] [ 16 ]} (نسبةً إلى جسيم هيغز بوزون ) هو خطأ يُتوقع وجوده بناءً على ظروف مُلاحظة أخرى (غالبًا ما تكون سجلات ذات صلة غامضة وتقارير مستخدمين غير موثقة)، ولكنه يصعب، إن لم يستحيل، إعادة إنتاجه بشكل مصطنع في بيئة تطوير أو اختبار. قد يُشير المصطلح أيضًا إلى خطأ واضح في الكود (مُثبت رياضيًا)، ولكنه غير مرئي أثناء التنفيذ (ومع ذلك يصعب أو يستحيل العثور عليه فعليًا).

أقدم ظهور معروف يعود إلى عام 1983، في منشور تابع لجمعية آلات الحوسبة (ACM) . ^{[ 17 ]}

استُخدم هذا المصطلح لأول مرة عام 1985 من قِبل جيم غراي ، في ورقة بحثية حول أعطال البرمجيات، ^{[ 18 ]} ويُنسب إليه خطأً في بعض الأحيان بسبب هذا المنشور. كما استُخدم عام 1986 من قِبل جوناثان كلارك وزهاي ستيوارت في القائمة البريدية (التي أصبحت لاحقًا مجموعة أخبار يوزنت ) comp.risks . ^{[ 19 ]}

أكد بروس ليندسي، الباحث في شركة IBM ، في مقابلة مع ACM Queue عام 2004 أنه كان حاضرًا عندما تم تعريف Heisenbug في الأصل، ^{[ 20 ]} لكنه لم يذكر متى حدث ذلك.

يصعب تحديد أخطاء هايزن وإصلاحها؛ وغالبًا ما تؤدي محاولة حلها إلى سلوكيات غير متوقعة أخرى. ولأن المشكلة تظهر نتيجة خطأ أساسي منفصل، يصعب التنبؤ بالسلوك وتحليله أثناء عملية تصحيح الأخطاء. عمومًا، من المفترض أن يقل عدد أخطاء هايزن المكتشفة مع تطور البرنامج. ^{[ 21 ]}

• برمجة عبادة الشحن
• مصحح أخطاء Jinx — أداة تستكشف تلقائيًا عمليات التنفيذ التي من المحتمل أن تكشف عن أخطاء Heisenbugs
• مصحح أخطاء الذاكرة

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