|
There aren't any unsolvable bugs . You just need to keep debugging until you find it. Bugs occur when there is code. If there is code then the bug can be fixed.
Microsoft ... the only place where VARIANT_TRUE != true
|
|
|
|
|
True, I know there arent any unsolveable bugs.
I want to know if you came across any unsolveable bugs to you.
Ones that you were unable to fix or maybe someone didnt give you time for it.
|
|
|
|
|
No, i haven't find a bug that i cannot solve  If you debug hard enough and if you find something that you cannot understand after you ask in the right place (for example here) you can fix everything
Microsoft ... the only place where VARIANT_TRUE != true
|
|
|
|
|
No.
Bugs are errors: sometimes in the code, or the design, or the specification, or the way the user is working - though the last reflects more on the spec than anything else.
And errors are fixable. If necessary, write them up in the manual, and then they are features, not bugs at all! 
The only instant messaging I do involves my middle finger.
|
|
|
|
|
OriginalGriff wrote: then they are features, not bugs at all
That's the MS way of coding...
The signature is in building process.. Please wait...
|
|
|
|
|
MS write documentation?  Why did nobody tell me?
The only instant messaging I do involves my middle finger.
|
|
|
|
|
Yes. It was in RSA-signature-protected firmware. I would have had to crack the key in order to fix it.
|
|
|
|
|
Sounds heavy.
Was it your code to begin with?
|
|
|
|
|
No, was it supposed to be a question about my own code only?
|
|
|
|
|
Not really, was just asking how it was in your case.
|
|
|
|
|
Ok.
There have been bugs in my own code that I didn't fix, but as far as I can remember, never because I was unable to. They were just too unimportant to spend time on. There have been bugs that were particularly hard to diagnose, such as a very sneaky non-admissible heuristic that was only incorrect about once in a million times and lead to a detectable error even more rarely, and various obscure race conditions.
|
|
|
|
|
One so far. Solved it by sweeping it under the rug (customer request). 5 months of work. 2 people tried their hand at it. Still as much of a mystery. I would have still wanted to figure it out but lack of source code for the entire app (only ran at somebody else site) and the fact that it was tested on weekends only and it didn't show up every weekend of tests made it pretty rough.
Worst that I've solved was about 2-3 months of work, and it was a stupidly simple root cause from the customer's side.
|
|
|
|
|
Sounds abit like the one I´m wrestling with now.
I´ve made a communications application which runs on 3 different computers where it mess up on only one computer every monday, sometimes every 2 mondays.(Bytes are being swapped and the numbers are wrong, tcp/ip).
Cleaning buffers and restarting the socket solves it, until next monday or the monday after.
I ran it on my own computer hooked to the system on the computer that mess up and it works.
So its only on one PC that mess up, same config as the rest.
|
|
|
|
|
If there is no solution, there probably is a workaround.
|
|
|
|
|
you beat me to it 
"Rock journalism is people who can't write interviewing people who can't talk for people who can't read." Frank Zappa 1980
|
|
|
|
|
Unsolvable bug, no.
Extremely difficult to solve and very time consuming, yes.
I don't believe there is such a thing as unsolvable bugs, just bugs that can't be properly solved due to time and resource constraints.
|
|
|
|
|
1. Just wrap entire code with try-catch. Make sure you have a empty catch block. You can also write some code in catch block that actually does nothing.
2. Do not tell anyone about this in office.
3. Find credentials of your arch enemy in the team and check in with his credentials.
4. Tell this awesome story to others while enjoying a beer.
"Bastards encourage idiots to use Oracle Forms, Web Forms, Access and a number of other dinky web publishing tolls.", Mycroft Holmes[ ^]
|
|
|
|
|
I first read that subject line as "bug solving pill". Pass the Valium please.
|
|
|
|
|
I had a bug once that took over a year to find and correct. I never gave up on the problem, but I would leave it and come back to it, sometimes weeks later. This is the only time I was desperate enough to use a link map to figure out in release-compiled code where a crash was taking place (this was a native app).
There's always a critical piece of information to understanding the problem that you don't find out until the end. Once you find that bit, the problem's straightforward to fix.
In my case, my app would randomly crash at a couple customers' locations, approximately once a week. We make commercial ink-jet printing systems, and my app is the user interface for the machine. It turns out these customers were shutting down their press hardware, but leaving the controller computer powered up, with the UI sitting on a particular screen. Overnight this was okay, but over a weekend the crash seemed to happen more often. The critical piece of information was that the customers were leaving the app sitting at that screen for long periods. I could simulate this at my desk. Eventually, running the simulation speed very fast, I could cause the crash in a few minutes.
As it turns out, the app was leaking a GDI handle during a polling operation, and when the app finally reached the limit, it would crash.
Software Zen: delete this;
|
|
|
|
|
Interesting.
I hate when it feels like its right in front of me but I fail to see it.
I´m currently looking for that little piece of information.
|
|
|
|
|
It´s easy to get that piece of information if you can reproduce or simulate the bug you are after.
Which is the normal way to go, for me at least.
|
|
|
|
|
In my case, I didn't know how to reproduce the bug without the little piece of information. Without reproducing the bug, I could only walk the code, hoping to find the problem. In this circumstance, the actual bug was in a controls library being used by the piece of UI in question, so it wasn't even in a piece of code I was reviewing.
Software Zen: delete this;
|
|
|
|
|
The closest I've come is when programming embedded stuff and there is actually an issue on the die of a microcontroller that prevents a subsystem (like a UART) from working correctly. There usually is a work-around, but not always, something which I painfully found out not too long ago, a UART that would work intermittently at a certain baud rate. But generally speaking I agree with the other posters, that there are no unsolvable issues. Sometimes the issues are not with your code, but perhaps in a library or such that you're linking to. Is it possible to make a smaller project that exhibits the problem?
|
|
|
|
|
Söderlund wrote: Have you guys ever found a bug or misbehaviour that you were unable to correct?
Yes - when it was an architectural problem which was at the center of the product design. A list of actions took place when triggered by an HI event. The actions could be processed in any order.
The proper way to fix this one was to rearchitect and rewrite the app - all 3 million lines of it.
Oh yeah it used the old SEH "__try" "__except" style of exception handling. It needed to be rewritten. Doing so would have required changing over 1000 lines of code in one whack.
Windows 8 is the resurrected version of Microsoft Bob. The only thing missing is the Fisher-Price logo.
- Harvey
|
|
|
|
|
I don't think there are unsolvable bugs, but I have had a few that caused me much grief. In each case, the bug was not in our application, but rather in an outside component such as a printer driver or third-party library. These can be difficult to track down, and even though the 'fault' is not in your code, the customer doesn't care. Happy hunting!
"Go forth into the source" - Neal Morse
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
