স্ক্র্যাডিনবাগ কী?

Question

এই উইকি পৃষ্ঠাটি বলে:

একটি স্ক্র্যাডিনবগ একটি বাগ যা কেবলমাত্র উত্স কোড পড়ার পরে বা প্রোগ্রামটি একটি অস্বাভাবিক উপায়ে ব্যবহার করার পরে প্রকাশ পায় যা লক্ষ করা যায় যে এটি কখনই প্রথম স্থানে কাজ করা উচিত নয়, এই পর্যায়ে প্রোগ্রামটি অবিলম্বে স্থির হওয়া পর্যন্ত প্রত্যেকের জন্য কাজ করা বন্ধ করে দেয়। জারগন ফাইল যোগ করেছে: "যদিও ... এটি অসম্ভব বলে মনে হচ্ছে, এটি ঘটে; কিছু প্রোগ্রাম বহু বছর ধরে সুপ্ত স্ক্র্যাডিনব্যাগগুলিকে আশ্রয় দিয়েছিল।"

যা নিয়ে কথা হচ্ছে তা অত্যন্ত অস্পষ্ট ..

কেউ কীভাবে স্ক্র্যাডিনবাগের মতো (যেমন একটি কাল্পনিক / বাস্তব জীবনের পরিস্থিতি সহকারে) উদাহরণ দিতে পারেন?

Comments

উল্লেখ্য যে উদ্ধৃতিটি রসিকভাবে বলা হয়েছে।

: আমার মনে হয় আপনি ভাল shrodinbug বুঝতে চান তাহলে আপনি Shrodinger বিড়াল সম্পর্কে জানত en.wikipedia.org/wiki/Shrodingers_cat

— Eimantas

@ আইমান্তাস আমি আসলে এখন আরও বিভ্রান্ত কিন্তু এটি একটি আকর্ষণীয় নিবন্ধ :)

Answer 1

আমার অভিজ্ঞতার নিদর্শনটি হ'ল:

• সিস্টেম প্রায়শ বছর ধরে কাজ করে
• একটি ত্রুটি রিপোর্ট করা হয়
• বিকাশকারী ত্রুটিটি তদন্ত করে এবং কিছুটা কোড সন্ধান করে যা পুরোপুরি ত্রুটিযুক্ত বলে মনে হয় এবং ঘোষণা করে যে এটি "কখনই কাজ করতে পারে না"
• ত্রুটিটি ঠিক হয়ে যায় এবং কোডটির কিংবদন্তিটি কখনও কাজ করতে পারে না (তবে বছরের পর বছর ধরে কাজ করে)

আসুন এখানে যৌক্তিক হতে হবে। কোড যা কখনও কাজ করতে পারে না ... কখনও কাজ করতে পারে না । যদি করেনি কাজ তারপর বিবৃতি মিথ্যা।

সুতরাং আমি বলতে যাচ্ছি যে ঠিক যেমন বর্ণিত একটি বাগ (ত্রুটিযুক্ত কোডটি পর্যবেক্ষণ করে এটি কাজ করা বন্ধ করে দেয়) তা স্পষ্টতই বাজে কথা।

বাস্তবে যা ঘটেছে তা হ'ল দুটি জিনিসের একটি:

1) বিকাশকারী কোডটি পুরোপুরি বুঝতে পারেন নি । এই ক্ষেত্রে কোডটি সাধারণত গণ্ডগোল হয়ে থাকে এবং এর কোথাও কোথাও কোনও বাহ্যিক অবস্থার প্রতি প্রধান তবে অ-স্পষ্ট সংবেদনশীলতা রয়েছে (একটি নির্দিষ্ট ওএস সংস্করণ বা কনফিগারেশন বলুন যা কিছু ফাংশন কিছু ছোট কিন্তু তাত্পর্যপূর্ণভাবে কীভাবে কাজ করে তা পরিচালনা করে)। এই বাহ্যিক অবস্থার পরিবর্তন করা হয়েছে (কোনও সার্ভার আপগ্রেড বা পরিবর্তনের মাধ্যমে বলুন যা বিশ্বাসহীন বলে মনে করা হয়) এবং এর ফলে কোডটি ভেঙে যায়।

এর পরে বিকাশকারী কোডটি দেখেন এবং theতিহাসিক প্রেক্ষাপটটি বুঝতে না পেরে বা প্রতিটি সম্ভাব্য নির্ভরতা এবং দৃশ্যের মধ্য দিয়ে খুঁজে পাওয়ার সময় না জানিয়ে ঘোষণা দিয়েছিলেন যে এটি কখনই কাজ করতে পারে না এবং পুনরায় লিখতে পারে না।

এই পরিস্থিতিতে এখানে বোঝার বিষয়টি হ'ল "এটি কখনই কাজ করতে পারে না" এমন ধারণাটি মিথ্যা (কারণ এটি ঘটেছে) is

এটি পুনর্লিখন করা একটি খারাপ জিনিস বলে বলা যায় না - এটি প্রায়শই নয়, যদিও ঠিক কী ভুল ছিল তা জানতে বেশিরভাগ সময় সময়সাপেক্ষ এবং কোডের বিভাগটি পুনরায় লেখার কাজটি দ্রুততর হয় এবং আপনি নিশ্চিত হন যে আপনি জিনিসগুলি স্থির করেছেন।

2) আসলে এটি কখনও কাজ করে নি, কেবল কারও নজরে নেই । এটি আশ্চর্যজনকরূপে সাধারণ, বিশেষত বৃহত সিস্টেমে। এই উদাহরণে কেউ নতুন শুরু করে এবং জিনিসগুলি এমনভাবে দেখা শুরু করে যে আগে কেউ করেনি, বা কোনও ব্যবসায়িক প্রক্রিয়া পরিবর্তিত হয় কিছু পূর্বের ছোট ছোট প্রান্তকে মূল প্রক্রিয়াতে নিয়ে আসে এবং এমন কিছু যা সত্যই কখনও কাজ করে না (বা কিছু কাজ করেছে তবে সব কিছুই নয়) সময়) পাওয়া যায় এবং রিপোর্ট করা হয়।

বিকাশকারী এটি দেখে এবং ঘোষণা করে যে "এটি কখনই কাজ করতে পারে না" তবে ব্যবহারকারীরা বলে "বোকা, আমরা এটি বছরের পর বছর ধরে ব্যবহার করে আসছি" এবং তারা সঠিকভাবে সাজছে তবে এমন কিছু যা তারা অপ্রাসঙ্গিক বলে মনে করে (এবং সাধারণত এটি উল্লেখ না করা পর্যন্ত ডেভেলপার সঠিক অবস্থায় সময়ে তারা যেতে "ওহ হ্যাঁ, আমরা করব খুঁজে বের করে যে এখন এবং আগের" পরিবর্তিত হয়েছে)।

এখানে বিকাশকারী সঠিক - এটি কখনও কাজ করতে পারে না এবং কখনও কাজ করে না।

তবে উভয় ক্ষেত্রেই দুটি বিষয়ে একটি সত্য:

• "এটি কখনও কাজ করতে পারে না" দাবিটি সত্য এবং এটি কখনও কাজ করেনি - লোকেরা কেবল এটি ভেবেছিল
• এটি কাজ করেছে এবং "এটি কখনই কাজ করতে পারে না" বিবৃতিটি মিথ্যা এবং নীচে কোডের এবং এর নির্ভরতাগুলির (সাধারণত যুক্তিসঙ্গত) বোঝার অভাবের পক্ষে হয়

Comments

তাই প্রায়ই আমার হবে

— জনন

এই পরিস্থিতিতে বাস্তবতা সম্পর্কে দুর্দান্ত অন্তর্দৃষ্টি

— স্টুপারউজার

আমি অনুমান করব এটি সাধারণত "ডাব্লুটিএফ" মুহুর্তের ফলাফল। আমি একবার ছিল। আমি লিখেছি এমন কিছু কোড আমি আবারও পড়েছি এবং বুঝতে পেরেছি যে সম্প্রতি যে বাগটি লক্ষ্য করা গেছে তার সম্পূর্ণ অ্যাপ্লিকেশনটি ভেঙে ফেলা উচিত ছিল। প্রকৃতপক্ষে, আরও তদন্তের পরে, আমি লিখেছি এমন আরও একটি উপাদান এটির ত্রুটিগুলি পূরণ করেছিল।

— থাদদী টাইল

@ থাডি - আমি এটি আগেও দেখেছি কিন্তু কোড মডিউলগুলিতে দুটি বাগও দেখেছি যা একে অপরকে একে অপরকে বাতিল করার আহ্বান জানিয়েছিল যাতে এটি আসলে কাজ করে। একজনের দিকে তাকান এবং সেগুলি ভেঙে পড়েছিল তবে তারা একসাথে ভাল ছিল।

— জন হপকিন্স

@ জোন হপকিন্স: আমি দুটি বাগ একে অপরকে বাতিল করার একটি ঘটনা পেয়েছি এবং এটি সত্যিই অবাক করার মতো। আমি একটি বাগ খুঁজে পেয়েছি, "এটি কখনই কাজ করতে পারত না" বলে কুখ্যাত বিবৃতিটি নীরব করেছিলাম, কেন এটি যেভাবেই কাজ করে তা অনুসন্ধান করার জন্য আরও গভীরভাবে তাকাল এবং আরও একটি ক্ষেত্রে কমপক্ষে বেশিরভাগ ক্ষেত্রেই প্রথমটি সংশোধনকারী কোন বাগ খুঁজে পেয়েছি। আমি আবিষ্কারটি দেখে সত্যিই হতবাক হয়ে গিয়েছিলাম এবং এই বাগের মধ্যে কেবল একটির সাথেই পরিণতিটি বিপর্যয়কর হত!

— অ্যালেক্সিস ডুফরনয়

Answer 2

যেহেতু প্রত্যেকে কোডের উল্লেখ করেছে যা কখনই কাজ করা উচিত ছিল না, আমি 8 বছর আগে একটি ডাইনিং ভিবি 3 প্রকল্পে যা নেট থেকে রূপান্তরিত হচ্ছিলাম তার একটি উদাহরণ আমি আপনাকে দিয়েছি। দুর্ভাগ্যক্রমে। নেট সংস্করণটি সম্পূর্ণ না হওয়া পর্যন্ত এই প্রকল্পটি আপ টু ডেট রাখতে হয়েছিল - এবং আমি সেখানে একাই ছিলাম যারা এমনকি দূরবর্তী অবস্থান থেকে ভিবি 3 বুঝতে পেরেছিলেন।

একটি খুব গুরুত্বপূর্ণ ফাংশন ছিল যা প্রতিটি গণনার জন্য কয়েকবার বলা হত - এটি দীর্ঘমেয়াদী পেনশন পরিকল্পনার জন্য মাসিক সুদের গণনা করে। আমি আকর্ষণীয় অংশ পুনরুত্পাদন করব।

Function CalculateMonthlyInterest([...], IsYearlyInterestMode As Boolean, [...]) As Double
    [about 30 lines of code]
    If IsYearlyInterestMode Then
        [about 30 lines of code]
        If Not IsYearlyInterestMode Then
            [about 30 lines of code (*)]
        End If
    End If
End Function

তারার সাথে চিহ্নিত অংশটির সর্বাধিক গুরুত্বপূর্ণ কোড ছিল; এটিই ছিল একমাত্র অংশ যা আসল গণনা করেছিল। স্পষ্টত এই কাজ করা উচিত ছিল না, তাই না?

এটা তোলে ডিবাগ অনেকটা গ্রহণ, কিন্তু আমি অবশেষে কারণ পাওয়া যায়নি: IsYearlyInterestModeছিল True, এবং Not IsYearlyInterestModeসত্য ছিল। এটি কারণ যে কোথাও লাইন বরাবর কেউ এটি একটি পূর্ণসংখ্যার জন্য ফেলেছে, তারপরে এমন কোনও ফাংশনে যা এটিটিকে সত্যিকারের বর্ধিত হিসাবে সেট করার কথা রয়েছে (যদি এটি 0 হয় তবে এটি False1 তে সেট করা হবে যা ভিবি True, তাই আমি যুক্তিটি দেখতে পাচ্ছি) সেখানে), তারপরে এটি একটি বুলিয়ানকে ফেলে দিন। এবং আমি এমন একটি শর্ত রেখেছিলাম যা কখনই ঘটতে পারে না এবং এখনও সর্বদা ঘটে।

Comments

Epilogue: আমি কখনই সেই ফাংশন স্থির করি নি; আমি কেবল ব্যর্থ কল সাইটকে অন্যান্য সকলের মতো 2 টি প্রেরণ করতে পেরেছি।

— Configurator

সুতরাং আপনি বোঝাতে চাইছেন যে কোডগুলি ভুল ব্যাখ্যা করার সময় এটি ব্যবহার করা হয়?

— পেসারিয়ার

@ পেসারিয়র: প্রায়শই যখন কোডটি এমন গোলযোগ হয় যে এটি কেবল দুর্ঘটনার দ্বারা সঠিকভাবে কাজ করে। আমার উদাহরণে, কোনও বিকাশকারী IsYearlyInterestModeসত্য এবং সত্য নয় উভয় হিসাবে মূল্যায়ন করার জন্য বোঝায় ; মূল ডেভেলপার করে একটি কয়েক লাইন (এক সহ যোগ ifগুলি আসলে বুঝতে পারে না কিভাবে এটি কাজ করে - এটা ঠিক তাই এটা যথেষ্ট ভাল ছিল কাজ করতে ঘটেছে।

— Configurator

Answer 3

বাস্তব-জগতের উদাহরণটি জানেন না, তবে উদাহরণের পরিস্থিতি দিয়ে এটিকে সরল করতে:

• কোনও ত্রুটি একটি সময়ের জন্য লক্ষ্য করা যায় না, কারণ অ্যাপ্লিকেশনটি কোডটিটি এমন পরিস্থিতিতে চালিত করে না যে কারণে এটি ব্যর্থ হয়।
• কেউ সাধারণ ব্যবহারের বাইরে (বা উত্সটি পরীক্ষা করে) কিছু করে এটি লক্ষ্য করে।
• এখন বাগটি লক্ষ্য করা গেছে, বাগটি ঠিক না করা অবধি অ্যাপ্লিকেশনটি স্বাভাবিক অবস্থার আগে পর্যন্ত ব্যর্থ হয়।

এটি ঘটতে পারে কারণ বাগটি অ্যাপ্লিকেশনটির কিছু স্থিতিকে দূষিত করবে যা পূর্ববর্তী সাধারণ পরিস্থিতিতে ব্যর্থতা সৃষ্টি করে।

Comments

একটি ব্যাখ্যা হ'ল সফ্টওয়্যারটিতে এলোমেলো ব্যর্থতা ছিল যে, কেউ মানসিকভাবে একসাথে লিঙ্ক করতে সক্ষম হয় নি। সুতরাং, এই ত্রুটিগুলি প্রাকৃতিক কারণ হিসাবে বিবেচিত হয়েছিল (যেমন এলোমেলো হার্ডওয়্যার ব্যর্থতা)। উত্স কোডটি একবার পড়ার পরে, লোকেরা এখন এই প্রথম কারণে সমস্ত পূর্ববর্তী র্যান্ডম ত্রুটিগুলি সম্পর্কিত করতে সক্ষম হবে এবং বুঝতে পারবে যে এটি কখনই প্রথম স্থানে কাজ করা উচিত হয়নি।

— rwong

দ্বিতীয় ব্যাখ্যাটি হ'ল সফ্টওয়্যারটির একটি অংশ রয়েছে যা একটি চেইন অফ দায়িত্বশীলতার ধরণ দিয়ে প্রয়োগ করা হয়। প্রতিটি হ্যান্ডলার একটি শক্তিশালী উপায়ে লেখা হয়, তবুও একজন হ্যান্ডলারের একটি জটিল ত্রুটি রয়েছে। এখন, প্রথম হ্যান্ডলার সর্বদা ব্যর্থ হবে, তবে দ্বিতীয় হ্যান্ডলারের (যা দায়ভারে ওভারল্যাপ করেছে) একই কাজটি সম্পাদন করার চেষ্টা করার কারণে সামগ্রিক ক্রিয়াকলাপটি সফল হয়েছে বলে মনে হয়। যদি দ্বিতীয় মডিউলে কোনও পরিবর্তন হয় যেমন দায়িত্বের ক্ষেত্রের পরিবর্তন, এটি সামগ্রিক ব্যর্থতার কারণ হতে পারে, যদিও আসল বাগটি অন্য কোনও স্থানে থাকে।

— rwong

Answer 4

একটি বাস্তব জীবনের উদাহরণ। আমি কোডটি প্রদর্শন করতে পারি না, তবে বেশিরভাগ লোক এটির সাথে সম্পর্কিত হবে।

আমাদের যেখানে ইউটিলিটি ফাংশন রয়েছে তার একটি বড় অভ্যন্তরীণ গ্রন্থাগার রয়েছে। একদিন আমি একটি নির্দিষ্ট কাজ করার জন্য একটি ফাংশন সন্ধান করছি এবং আমি এটি Frobnicate()ব্যবহার করার চেষ্টা করেছি। আহ-ওহ: দেখা যাচ্ছে যে Frobnicate()সর্বদা একটি ত্রুটি কোড দেয়।

বাস্তবায়নের জন্য খনন করে, আমি কিছু বুনিয়াদি যুক্তি ত্রুটিগুলি পাই Frobnicate()যা এটি সর্বদা ব্যর্থ হয়। উত্স নিয়ন্ত্রণে আমি দেখতে পাচ্ছি যে ফাংশনটি লিখিত হওয়ার পর থেকে এটি সংশোধন করা হয়নি, অর্থাত্ ফাংশনটি কখনই উদ্দেশ্য হিসাবে কাজ করে নি । কেন কেউ তা খেয়াল করেনি? আমি উত্স তালিকাভুক্তির বাকী অংশে অনুসন্ধান করে দেখতে পেলাম যে বিদ্যমান কলাররা Frobnicate()সবাই রিটার্নের মানটিকে উপেক্ষা করছে (এবং সেইজন্য তাদের নিজস্ব সূক্ষ্ম বাগ রয়েছে)। আমি যদি ফাংশনগুলি পরিবর্তন করে তাদের রিটার্নের মানটি যাচাই করতে পারি, তবে সেগুলিও ব্যর্থ হয়।

এটি জেন ​​হপকিন্স তার উত্তরে উল্লিখিত # 2 শর্তের একটি সাধারণ ঘটনা এবং বড় অভ্যন্তরীণ লাইব্রেরিতে এটি হতাশাজনকভাবে সাধারণ।

Comments

... যা কোনও বাহ্যিক ব্যবহারের যোগ্য যেখানেই অভ্যন্তরীণ লাইব্রেরি লেখা এড়াতে একটি ভাল কারণ তৈরি করে। এটি আরও পরীক্ষিত হবে এবং এই জাতীয় দুর্লভ বিস্ময়ের চেয়ে কম সংখ্যক হবে (ওপেন-সোর্স লাইব্রেরিগুলি পছন্দনীয়, কারণ তারা যদি যাইহোক করেন তবে আপনি সেগুলি ঠিক করতে পারেন)।

— জানু হুডেক

হ্যাঁ, তবে প্রোগ্রামাররা যদি রিটার্ন কোডগুলিকে অগ্রাহ্য করে তবে এটি গ্রন্থাগারের ত্রুটি নয়। (যাইহোক, আপনি কখন শেষবারের কোডটি চেক করেছিলেন printf()?)

— জেনসজি

ঠিক এই কারণেই চেক করা ব্যতিক্রমগুলি আবিষ্কার করা হয়েছিল।

— কেভিন ক্রামউইদে

Answer 5

এখানে কিছু সিস্টেম কোড আমি দেখেছি একটি সত্যিকারের শ্রাদিনবাগ। একটি রুট ডিমন কার্নেল মডিউলটির সাথে যোগাযোগ করতে হবে। সুতরাং কার্নেল কোডটি কিছু ফাইল বর্ণনাকারী তৈরি করে:

int pipeFDs[1];

তারপরে একটি পাইপের উপর যোগাযোগ স্থাপন করে যা নামযুক্ত পাইপের সাথে সংযুক্ত থাকবে:

int pipeResult = pipe(pipeFDs);

এটি কাজ করা উচিত নয় । pipe()অ্যারেতে দুটি ফাইল বর্ণনাকারী লেখেন, তবে একটির জন্য কেবল স্থান রয়েছে। কিন্তু প্রায় সাত বছর জন্য এটি করেনি কাজ; অ্যারে ঘটেছে মেমরির কিছু অব্যবহৃত জায়গার আগে যা ফাইল বিবরণকারী হিসাবে পরিণত হয়েছিল।

তারপরে, একদিন আমাকে কোডটি একটি নতুন আর্কিটেকচারে পোর্ট করতে হয়েছিল। এটি কাজ করা বন্ধ করে দিয়েছিল এবং যে বাগটি কখনও কাজ করা উচিত হয়নি তা আবিষ্কার হয়েছিল।

Answer 6

Schrödinbug একটি সম্পুরক হয় Heisenbug যা একটি বাগ disappears (অথবা মাঝে মাঝে দেখা যায়) যখন তদন্ত এবং / অথবা এটা ঠিক করার চেষ্টা বর্ণনা -।

হাইজেনব্যাগগুলি হলেন পৌরাণিক চৌকস ছোট্ট ব্লাইটার যা কোনও ডিবাগার লোড হয়ে গেলে দৌড়ায় এবং লুকিয়ে রাখে, তবে আপনি দেখা বন্ধ করার পরে কাঠের কাজ থেকে বেরিয়ে আসুন।

বাস্তবে, এগুলি সাধারণত নিম্নলিখিত বা অন্য কোনও কারণে ঘটে বলে মনে হয়:

• প্রভাব যে অপ্টিমাইজেশান, যেখানে কোড সংকলিত -DDEBUGরিলিজ বিল্ড থেকে আলাদা স্তরে অনুকূলিত হয় optim
• বাস্তব-বিশ্ব যোগাযোগের বাসগুলি বা বিঘ্নগুলির কারণে সূক্ষ্ম সময় পার্থক্যগুলি সিমুলেটেড "পারফেক্ট" ডামি লোডের থেকে সম্পূর্ণ আলাদা

উভয়ই রিলিজ সরঞ্জামগুলিতে পরীক্ষার রিলিজ কোডের গুরুত্বের পাশাপাশি ইউনিট / মডিউল / সিস্টেম পরীক্ষার সাহায্যে ইমুলেটর ব্যবহার করে highlight

Comments

আমি পোস্ট করার আগে কেন আমি এস.লোটের উত্তর এবং ডেলাননের মন্তব্য লক্ষ্য করিনি?

— অ্যান্ড্রু

আমি সামান্য অভিজ্ঞতা আছে কিন্তু এর একটি দম্পতি পেয়েছি। আমি একটি অ্যান্ড্রয়েড এনডিকে পরিবেশে কাজ করছিলাম। যখন ডিবাগারটি একটি ব্রেকপয়েন্ট পেল তখন এটি জাভা থ্রেডগুলিকে কেবল সি ++ থামিয়ে দিয়েছিল, কিছু কল করা সম্ভব করেছিল কারণ উপাদানগুলি সি ++ এ আরম্ভ করা হয়েছিল। যদি ডিবাগার ছাড়াই ছেড়ে যায় তবে জাভা কোডটি সি ++ এর চেয়ে দ্রুত চলে যায় এবং যে মানগুলি এখনও আরম্ভ করা হয়নি সেগুলি ব্যবহার করার চেষ্টা করে।

— এমএলপ্রোগ্রামার-সিআইএম

আমি কয়েক মাস আগে আমাদের ব্যবহারে জ্যাঙ্গো ডাটাবেস এপিআইয়ের একটি হাইজেনব্যাগ আবিষ্কার করেছি : কখন DEBUG = True, "পরামিতিগুলি" এর নামটি কাঁচা এসকিউএল কোয়েরি পরিবর্তিত হয়। আমরা ক্যোয়ারির দৈর্ঘ্যের কারণে স্পষ্টতার জন্য কীওয়ার্ড আর্গ হিসাবে এটি ব্যবহার করছিলাম, যা বিটা সাইটের দিকে ধাক্কা দেওয়ার সময় যখন পুরোপুরি ভেঙে গেল, যেখানেDEBUG = False

— ইজকাটা

Answer 7

আমি কয়েকটি শোডিনবাগ দেখেছি এবং সর্বদা একই কারণে:

কোম্পানির নীতিতে প্রত্যেকেরই একটি প্রোগ্রাম ব্যবহার করার কথা ছিল required
সত্যই কেউ এটি ব্যবহার করেনি (বেশিরভাগ কারণেই এটির জন্য কোনও প্রশিক্ষণ ছিল না))
তবে তারা এটি ম্যানেজমেন্টকে বলতে পারেনি। সুতরাং প্রত্যেককেই বলতে হয়েছিল "আমি এই প্রোগ্রামটি 2 বছর ধরে ব্যবহার করে আসছি এবং আজ অবধি এই বাগের মুখোমুখি হয়নি।"
সংখ্যালঘু ব্যবহারকারীর ব্যতীত (প্রোগ্রামটি লিখেছেন এমন বিকাশকারীগণ সহ) প্রোগ্রামটি সত্যই কার্যকর হয়নি

একটি ক্ষেত্রে, প্রোগ্রামটি প্রচুর পরীক্ষার বিষয় ছিল, তবে আসল ডাটাবেসে নয় (এটি অত্যন্ত সংবেদনশীল বলে মনে করা হয়েছিল, সুতরাং একটি জাল সংস্করণ ব্যবহৃত হয়েছিল))

Answer 8

আমার নিজের ইতিহাস থেকে একটি উদাহরণ রয়েছে, এটি প্রায় 25 বছর আগে ছিল। আমি বাচ্চা ছিলাম টার্বো পাস্কেলে প্রাথমিক গ্রাফিক্স প্রোগ্রামিং করছি। টিপির বিজিআই নামে একটি লাইব্রেরি ছিল যা এতে কিছু ফাংশন অন্তর্ভুক্ত যা আপনাকে পর্দার একটি অঞ্চলকে পয়েন্টার ভিত্তিক মেমরি-ব্লকে অনুলিপি করতে দেয় এবং তারপরে এটিকে অন্য কোথাও ব্লিট করে দেয়। কালো-সাদা-স্ক্রিনে জোর-ব্লিটিংয়ের সাথে মিলিত এটি সাধারণ অ্যানিমেশন করতে ব্যবহৃত হতে পারে।

আমি এটিকে আরও একধাপ এগিয়ে নিয়ে স্প্রিট করতে চেয়েছিলাম। আমি একটি প্রোগ্রাম লিখেছিলাম যা এটিগুলিতে রঙিন করার জন্য বড় ব্লকগুলি এবং নিয়ন্ত্রণগুলিকে আকর্ষণ করেছিল, যেমন আপনি এটি করেছেন পিক্সেল হিসাবে এটি পুনরুত্পাদন করে স্প্রাইট তৈরির জন্য একটি সাধারণ অঙ্কন প্রোগ্রাম তৈরি করে, যা এটি তখন স্মৃতিতে অনুলিপি করতে পারে। কেবল একটি সমস্যা ছিল, এই blitted sprites ব্যবহার করতে, তাদের একটি ফাইলে সংরক্ষণ করতে হবে যাতে অন্যান্য প্রোগ্রামগুলি সেগুলি পড়তে পারে। কিন্তু টিপির কাছে পয়েন্টার-ভিত্তিক মেমরি বরাদ্দকে সিরিয়াল দেওয়ার কোনও উপায় ছিল না। ম্যানুয়ালগুলি ফ্ল্যাট আউট করে জানিয়েছে যে তাদের ফাইল করা যায় না।

আমি একটি কোডের টুকরো নিয়ে এসেছি যা সফলভাবে ফাইলটিতে লিখতে পেরেছিল। এবং একটি পরীক্ষা প্রোগ্রাম লিখতে শুরু করেছিল যা আমার অঙ্কন প্রোগ্রাম থেকে একটি প্লেগ্রাউন্ডে একটি স্প্রিটকে blitted - একটি গেম তৈরি করার পথে। এবং এটি সুন্দরভাবে কাজ করেছে। পরের দিন, এটি কাজ বন্ধ। এটি একটি গার্ল্ড গন্ডগোল ছাড়া কিছুই দেখায় নি। এটি আর কখনও কাজ করেনি। আমি একটি নতুন স্প্রাইট তৈরি করেছি এবং এটি পুরোপুরি কার্যকর হয়েছিল - যতক্ষণ না এটি ঘটেছিল এবং এটি আবার গর্জে ওঠে।

এটি একটি দীর্ঘ সময় নিয়েছে কিন্তু অবশেষে আমি বুঝতে পারছিলাম কি হচ্ছে। অঙ্কন প্রোগ্রামটি ছিল না, যেমনটি আমি ভেবেছিলাম, অনুলিপি করা পিক্সেল ডেটা ফাইলে সংরক্ষণ করা - এটি পয়েন্টারটি নিজেই সংরক্ষণ করছিল। যখন পরের প্রোগ্রামটি ফাইলটি পড়বে তখন এটি একই মেমরির ব্লকের পয়েন্টার দিয়ে শেষ হয়েছিল - এতে এখনও শেষ প্রোগ্রামটি যা লিখেছিল তা অন্তর্ভুক্ত ছিল (এটি এমএস-ডস-এ ছিল, মেমরি পরিচালনাটি অস্তিত্বহীন ছিল)। তবে এটি কার্যকর ছিল ... যতক্ষণ না আপনি রিবুট করেছেন, না এমন কিছু চালিয়েছেন যা মেমরির সেই একই ক্ষেত্রটি পুনরায় ব্যবহার করেছে এবং তারপরে আপনি একটি গণ্ডগোল পেলেন কারণ আপনি ভিডিও-মেমরি ব্লকটিতে পুরোপুরি সম্পর্কিত নয় এমন ডেটা গুঁড়িয়ে দিচ্ছেন।

এটি কখনও কাজ করা উচিত ছিল না, এটি কখনও কাজ করার জন্য হাজির হওয়া উচিত ছিল না (এবং কোনও সত্যিকারের ওএসে এটি নাও হত) তবে এটি এখনও করেছে, এবং একবার এটি ভেঙে গেছে - এটি ভাঙ্গা থেকে যায়।

Answer 9

লোকেরা যখন ডিবাগার ব্যবহার করে তখন সমস্ত সময় এটি ঘটে।

ডিবাগিং পরিবেশ প্রকৃত থেকে আলাদা - কোনও ডিবাগার নয় - উত্পাদন পরিবেশ।

একটি ডিবাগার দিয়ে চালানো স্ট্যাক ওভারফ্লোসের মতো জিনিসগুলি মাস্ক করতে পারে কারণ ডিবাগারের স্ট্যাক ফ্রেমগুলি বাগটি মাস্ক করে।

Comments

আমি মনে করি না এটি কোনও ডিবাগারে কোড চালানো এবং সংকলিত হওয়ার মধ্যে পার্থক্যের কথা উল্লেখ করছে।

— জন হপকিন্স

এটি স্ক্রাইডিনবাগ নয়, এটি হিজেনব্যাগ ।

@ ডেলান: এটি প্রান্তে, আইএমও। আমি এটাকে একটি অনির্দিষ্ট বিষয় বলে মনে করি কারণ অজান্তে স্বাধীনতার ডিগ্রি রয়েছে। আমি কিছু যেখানে এক জিনিস পরিমাপের জন্য heisenbug রিজার্ভ করতে চাই আসলে অন্য (অর্থাত, জাতি শর্ত, অপটিমাইজার সেটিংস, নেটওয়ার্ক ব্যান্ডউইদ সীমাবদ্ধতা, ইত্যাদি) বিরক্ত

— S.Lott

@ এস.লোট: আপনি যে পরিস্থিতি বর্ণনা করেছেন তাতে স্ট্যাক ফ্রেমগুলি বা এর মতো জগাখিচুড়ি করে পর্যবেক্ষণ পরিবর্তনকারী জিনিসগুলিকে অন্তর্ভুক্ত করা হয়। (এর মধ্যে সবচেয়ে খারাপ উদাহরণ আমি দেখেছি হ'ল ডিবাগারটি শান্তিপূর্ণভাবে এবং একক-পদক্ষেপ মোডে অবৈধ বিভাগের রেজিস্টার মানগুলির লোডগুলি "সঠিকভাবে" চালিত করবে The । যেহেতু এটি কেবল অনুলিপি করা হচ্ছিল এবং এটি

— যথাযথ

Answer 10

আমি কখনই সত্যিকারের স্ক্রোডিনব্যাগটি দেখিনি এবং আমি মনে করি না যে তাদের উপস্থিতি থাকতে পারে - এটি সন্ধান করার ফলে জিনিস ভাঙ্গবে না।

বরং, এমন কিছু পরিবর্তন হয়েছে যা যুগ যুগ ধরে লুকিয়ে থাকা একটি বাগটি উন্মোচিত করেছিল। যা কিছু পরিবর্তিত হয়েছে তা এখনও পরিবর্তিত হয়েছে এবং একই সাথে কেউ বাগটি খুঁজে পাওয়ার সময় বাগটি প্রদর্শন করে চলেছে।