در این مقاله، نگاهی می‌اندازیم به 4 نوع از باگ‌ها که نام خود را از دانشمندان معروف گرفته‌اند؛ دسته‌بندی این باگ‌ها مورد جالبی است و در ادامه خواهیم دید که باگ‌های ایجاد شده در فرایند کدنویسی تا چه اندازه می‌توانند عجیب باشند!

در مقاله‌ای معروف، آقای Jim Gray، باگ‌ها را به 2 دستهٔ Bohrbugs و Heisenbugs، براساس نام 2 دانشمند معروف تقسیم‌بندی کرده است اما امروزه، ما انواع باگ‌های بیشتری را می‌شناسیم و با آن‌ها سروکار داریم؛ بنابراین به 2 دستهٔ دیگر هم نگاهی خواهیم داشت و هر 4 مورد را با ذکر مثال بررسی خواهیم کرد.

انوع باگ‌ها:

Bohrbug

بیشتر باگ‌هایی که با آن‌ها برخورد داریم، مجدداً قابل‌تولید هستند و با عنوان Bohrbugs شناخته می‌شوند؛ این باگ‌ها نام خود را از دانشمندی به نام Niels Bohr گرفته‌اند که در سال 1913 یک مدل اتمی ساده و قابل‌درک ارائه داد. در مدل آقای Bohr، چیزهایی مثل مسیر حرکت و مقدار انرژی یک الکترون در یک اتم، قابل پیش‌بینی هستند.

به‌طور مشابه، Bohrbugها هم قابل پیش‌بینی هستند؛ به‌عبارت دیگر، اگر تحت همان شرایط قبلی نرم‌افزار را اجرا کنید، دوباره ایجاد می‌شوند. برای مثال، وقتی به‌خاطر این‌که از یک موجودیت null استفاده می‌کنید و بالتبع برنامهٔ شما کرش می‌کند، قطعاً بار دیگر برنامه برای یک ورودی دیگر با مقدار null در همین قسمت کرش خواهد کرد؛ پس مشخص است که این باگ به‌راحتی قابل تولید مجدد و بالتبع قابل دیباگ کردن است.

Heisenbug

همهٔ دولوپرهای حرفه‌ای با این موضوع مواجه شده‌اند زمانی‌که برنامه را دوباره اجرا می‌کنند، باگی که باعث شده بود برنامه کرش کند، ناپدید شده است! صرف‌نظر از این‌که چقدر تلاش می‌کنید و زمان خود را صرف پیدا کردن دوبارهٔ همان باگ می‌کنید، ولی باگ از دست شما فرار می‌کند و دوباره خود را نشان نمی‌دهد.

این نوع از باگ‌ها اسم خود را از دانشمند معروف آقای Werner Heisenberg گرفته‌اند که به‌خاطر «اصل عدم قطعیت» یا اصطلاحاً‌ Uncertainty Principle شناخته شده است؛ براساس این اصل، در یک زمان مشخص، امکان اندازه‌گیری مکان و سرعت یک الکترون درون یک اتم، به‌صورت دقیق و یا تقریبی وجود ندارد.

وقتی شما می‌خواهید عملیات دیباگینگ، ایزوله‌سازی و یا بررسی دقیق برای پیدا کردن مشکل را انجام دهید و باگ‌ها رفتار متفاوتی از خود نشان می‌دهند، به این نام شناخته می‌شوند؛ برای مثال، اگر متغیرهایتان را مقداردهی اولیه نکنید، ممکن این اتفاق رخ دهد. وقتی برنامه اجرا می‌شود، به متغیرهایی که مقداردهی اولیه نشده‌اند دسترسی خواهد داشت و این باعث ایجاد باگ می‌شود اما این درحالی است که وقتی می‌خواهید برنامه را دیباگ کنید، برنامه احتمالاً درست کار خواهد کرد چراکه بسیاری از دیباگرها، متغیرهایی که مقداردهی اولیه نشده‌اند را با ۰ مقداردهی می‌کنند و همین باعث می‌شود که شما با باگ موردنظر برخورد نکنید.

Mandelbugs

وقتی علت ایجاد باگ بسیار پیچیده و غیرقابل فهم باشد و باگ رفتاری غیرطبیعی از خود نشان می‌دهد، آن‌را Mandelbugs می‌نامند. این باگ‌ها نام خود را از روی نام آقای Benoît Mandelbrot گرفته‌اند که به‌عنوان پدر علم هندسه فراکتال شناخته می‌شود (فراکتال‌ها، ساختارهای پیچیده و شبیه به خود هستند). یک باگ در سیستم‌عامل که به زمان‌بندی وابسته است، مثالی از این نوع باگ‌ها است.

Schroedinbug

گاهی‌اوقات به سورس‌کد نگاه می‌اندازید و متوجه می‌شوید که باگ یا مشکلی وجود دارد که در مرحلهٔ اول اصلاً نباید اجازهٔ اجرا شدن برنامه را بدهد؛ وقتی می‌خواهید همین کد را اجرا کنید، باگ موردنظر بی‌درنگ ظاهر می‌شود و نرم‌افزار متوقف می‌شود. هرچند این مورد کمی غیرمعمول به‌نظر می‌رسد، اما چنین باگ‌هایی گاهی‌اوقات رخ می‌دهند و با نام Schroedinbug شناخته می‌شوند (معمولاً این نوع باگ‌ها از مراحل اولیهٔ تست‌های کیفیت نرم‌افزار رد می‌شوند و خود را نشان نمی‌دهند).

باگ‌های نوع Schroedinbug، نام خود را از دانشمند معروف آقای Erwin Schrödinger گرفته‌اند که ایدهٔ «آزمایش تئوری گربه» را ارائه کرد؛ در فیزیک کوانتوم، ذره‌های کوانتوم مانند اتم‌ها، می‌توانند در ۲ حالت یا بیشتر وجود داشته باشند ولی شرودینگر پیشنهاد کرد که در اشیاء کلاسیکتری مانند گربه که از اتم‌های بسیاری تشکیل شده، وجود داشتن در ۲ حالت، غیرممکن است. وی یک سناریو را پیشنهاد می‌کند که در آن یک گربه در داخل جعبه‌ای در بسته، همراه با شیشه‌ای با محتوای سم (که به یک اتم رادیواکتیو متصل است) قرار دارد.

اگر نیمه‌عمر اتم تمام شود، شیشه شکسته می‌شود و سم به بیرون نشت می‌کند و باعث مرگ گربه می‌شود؛ ولی درِ جعبه بسته است و بنابراین نمی‌توان گفت گربه زنده است یا مرده. از این‌رو، تا زمانی‌که درِ جعبه باز شود، گربه می‌تواند در ۲ حالت قرار داشته باشد: زنده یا مرده. در فیزیک کوانتوم، به این مورد اصطلاحاً Superposition State می‌گویند، به شکلی که گربه هم زنده است و هم مرده!

برگردیم به بحث باگ‌ها؛ صرفاً با مشاهدهٔ مشکل در کد، شما دست به ایجاد یکسری تغییرات می‌زنید که در این صورت یا نرم‌افزار اجرا می‌شود و یا کار نمی‌کند. بنابراین این نوع از باگ‌ها با عنوان Schroedinbug شناخته می‌شوند.

انواع باگ‌های دیگری هم وجود دارند که در قالب این ۴ دسته قرار نمی‌گیرند که از آن جمله می‌توان به باگ‌های به‌اصطلاح Aging-Related اشاره کرد که فقط زمانی رخ می‌دهند که نرم‌افزار برای مدت طولانی کار کند!

 

Joy of Programming: Types of Bugs

Types of bugsIn this column, we’ll look at four types of bugs, named after popular scientists. The classification is interesting — we’ll understand how strange bugs can be!

Jim Gray, in his popular paper (see References) originally proposed the classification of bugs as Bohrbugs and Heisenbugs, named after well-known scientists. Today, there are more bug types known to us, so we’ll also look at two other categories of them.

Bohrbugs: Most of the bugs that we come across are reproducible, and are known as Bohrbugs. These are named after Niels Bohr, who proposed a simple and easy-to-understand atomic model in 1913. In Bohr’s model, things like the path and momentum of an electron in an atom are predictable. Similarly, Bohrbugs are predictable — you can reproduce them if you run the software with similar conditions. For example, when the program crashes with a null-pointer access, it always crashes there for a given input; so you can easily reproduce it.

Heisenbugs: All experienced programmers have faced situations where the bug that crashed the software just disappears when the software is restarted. No matter how much time and effort is spent trying to reproduce the problem, the bug eludes us. Such bugs were named Heisenbugs, after Werner Heisenberg, who is known for his “uncertainty principle”. According to his theory, it is not possible to accurately or certainly determine the position and velocity of an electron in an atom at a particular moment. When bugs change their behaviour when you try to debug, probe or isolate, they are called Heisenbugs. It can happen, for example, when you use uninitialised variables. When the program is run, it will access variables that are uninitialised, and hence result in a bug. However, when you try to debug the program, the program might work just fine, because many debuggers initialise uninitialised variables to zeros, and so you might not hit the problem!

Mandelbugs: When the cause of the bug is too complex to understand, and the resulting bug appears chaotic, it is called a Mandelbug. These are named after Benoît Mandelbrot, who is considered the father of fractal geometry (fractals are complex, self-similar structures). A bug in an operating system that depends on scheduling is an example of a Mandelbug.

Schroedinbug: Sometimes, you look into the code, and find that it has a bug or a problem that should never have allowed it to work in the first place. When you try out the code, the bug promptly shows up, and the software fails! Though it sounds very uncommon, such bugs do occur and are known as Schroedinbugs. They are named after the scientist Erwin Schrödinger, who proposed a theoretical “cat experiment”. In quantum physics, quantum particles like atoms could exist in two or more quantum states, but Schrödinger suggested that in more classical objects like a cat which is made up of many atoms, existing in two states was impossible. He theorised about a scenario in which a cat is kept in a sealed chamber, with a vial of poison (attached to a radioactive atom). If the atom decayed, the vial would be smashed and the poison would leak, killing the cat. But with the chamber sealed, there would be no way to know whether the cat was dead or alive. So till the chamber is opened, theoretically, the cat could be in either of two states — dead or alive. In quantum physics, this is called a “superposition state”, where the cat is both alive and dead!

Coming back to bugs, by merely observing the problem in the code, you change the outcome — either the software works or breaks. So these kinds of bugs are known as Schroedinbugs.

There are other types of bugs that don’t come under these categories. For instance, “aging-related bugs” occur only after the software runs for a long time.

References

Jim Gray, “Why do computers stop and what can be done about it?”, Symposium on Reliability in Distributed Software and Database Systems, 1986.