|
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
|
|
|
|
|
I was told many years ago when I first started working in the computer industry "Don't sweat it! It's just 1's and 0's, how hard can that be?" (mainframes, 1965).
I never let a stupid machine that only understands 1's and 0's get the better of me.
Dave.
|
|
|
|
|
Söderlund wrote: misbehaviour that you were unable to correct?
Yes, a WinForms app that would crash once in a while; probably due to a cross-thread problem, but I never took the time to figure it out; I just told the user to get back in and I'd try to track it down later. I never tracked it down; there were always more important things that I could accomplish.
There was also a memory leak in a C app that I didn't track down until a few years after I had left the job. So I made the fix in my copy, but couldn't get it to the client.
Söderlund wrote: unsolveable bugs out there
I can't prove that there aren't, therefore there must be.
I'd like to know more (unless it's in VB).
|
|
|
|
|
SFW[^]
MVVM # - I did it My Way
___________________________________________
Man, you're a god. - walterhevedeich 26/05/2011
.\\axxx
(That's an 'M')
|
|
|
|
|
...from MSDNAA for use as a build server.
Yes, I already have access to Win8.1 and Win Server 2012 R2. I have had access for about three weeks now.
And yes, these are the RTM versions.
Keep Clam And Proofread
--
√(-1) 23 ∑ π...
And it was delicious.
|
|
|
|
|
I really don't understand why you don't use twitter for this kind of Messages ...
|
|
|
|
|
Klaus-Werner Konrad wrote: I really don't understand why you don't use twitter for this kind of Messages .
because 140 doesn't download an R2
|
|
|
|
|
Twitter won't have them.
Peter Wasser
Art is making something out of nothing and selling it.
Frank Zappa
|
|
|
|
|
True.
He'd have to add "and eating a sandwich" to bring it up to twitter standards.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
I left my job a little over a year ago for several reasons. Now the company I went to work for closed down, and I returned to the original job.
Now I'm a lead developer! I brought book suggestions with me such as "Clean Code", "Code Complete" and "Head First Design Patterns". I'm introducing linq, entity framework, mvc, etc. Shoot, we even got these guys using version control, and I'm enforcing a code review process.
I think my extended leave was very fruitful 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
