#140537 - Lazy1 - Mon Sep 17, 2007 8:43 am
You know the ones...
They take forever to track down and when you do find them you curse yourself for making the dumb mistake in the first place.
My latest one was how my music extractor for wolfenstein would run perfectly on linux but fail when compiled under cygwin/win32.
I spent a long time trying to find out why the audio offsets were all zero until I spotted the error.
I forgot to open the file in binary mode...
Oops.
What are some of your annoying bugs?
#140549 - melw - Mon Sep 17, 2007 10:44 am
Wondering why something doesn't work no matter how much you update it... until you notice you've compiled the wrong source code all the time.
#140557 - Cearn - Mon Sep 17, 2007 2:23 pm
I can't remember exactly what it was, but long ago in usenti I had something like this
| Code: |
Many lines of code
if(special condition);
do something special (probably memory allocation related)
More code
...
More code, elsewhere
*bewm*
|
At the site of the crash (hurray for debuggers) there was nothing really odd (except of course the crash). I think it took me four effin hours to to find that extra semi-colon in a completely different part of the code that was the cause of it all.
Also fun: using unsigned integers for rotation/scale in fixed point math. I think that's how I realized just why there are two different right-shift instructions.
Can't remember where I got it from, but it seems relevant here:
| Quote: |
| You can't make a program without breaking some egos |
#140842 - sgeos - Thu Sep 20, 2007 4:33 am
This comes to mind:
| Code: |
for (i = 0; i < MAX; i++)
do_something(EXPRESSION / i); |
-Brendan
#140867 - keldon - Thu Sep 20, 2007 10:26 am
Now here's an interesting one, it's easy to spot but if you're coding something simple that doesn't really beg scrutiny you can miss the shift key.
| Code: |
| for ( int y = 0; y , 192; ++y ) |
In isolation it's pretty easy to spot, but look how easy I can make it a little harder to spot.
| Code: |
// ... 10 lines of code ...
for ( int y = 0; (EXPR_DUBDUB1 + EXPR_DUBDUB2) , (CONST_DUBDUB1 + function_dubdub1(DUB1,DUB2)); ++y )
// ... 10 lines of code ... |
In fact there was a book centred around programming errors and how easy they can arise. So they gave an example of how a typo in a switch statement could allow you to write defualt instead of default; but in their code example they wrote default instead of defualt - which was really funny!
#140907 - Vich - Thu Sep 20, 2007 3:46 pm
Spending weeks or even months to fix a bug to then realize that it is not your code, but the library or compiler that is causing the error.
I had this happening with GCC once(a few weeks of work, can't recall what it was though, I probably intentionally forgot that :P) and recently with the Nintendo DS: I spent months to find why sorting of vertices in glOrtho mode didn't work, while it was a libnds error.
_________________
[project website] [personal website]
#140911 - simonjhall - Thu Sep 20, 2007 4:51 pm
My favourite one - trashing the stack...somehow. You know it's not behaving right, and its behaviour defies logic!
Or actually, even more favourite is the old "it doesn't break when I put printfs in" one!
And one I'm getting at work is a thing where if you write off the end of memory it'll not only trash your stack, but it'll wrap round to corrupt the data at the bottom of memory (ie your program). By the time the debugger steps in you can't figure out what's going wrong since you're executing data :-D
_________________
Big thanks to everyone who donated for Quake2
#140912 - kusma - Thu Sep 20, 2007 5:09 pm
| simonjhall wrote: |
My favourite one - trashing the stack...somehow. You know it's not behaving right, and its behaviour defies logic!
Or actually, even more favourite is the old "it doesn't break when I put printfs in" one!
|
Which is usually the same! Stack-corruption is often magically cleaned up by varargs-functions for some reason.
#140913 - kusma - Thu Sep 20, 2007 5:13 pm
By the way: my biggest hate-object is heap-corruption. When you write over the your memory allocator's internal structures, you're really fucked when it comes to debugging. Add some threads, race-conditions and inconsistent ref-counts, and you're living in my world! Oh, and yeah, custom (buggy) hardware that sometimes likes to write randomly around in memory.
#140920 - simonjhall - Thu Sep 20, 2007 6:40 pm
About a year ago it looked like I was working with some obscure hardware for the long haul and decided to write myself a full-blown emulator for the thing - the tool proved so useful for debugging that I rarely run it on the real kit as I can't be bothered to power it on! The only reason I'd run it on the kit is to get the speed boost.
Many of 'those' bugs can be *easily* solved by a system which supports "backwards debugging" and so I recently added it into the emulator. I tell ya, once you've tried backwards debugging you'll NEVER want to go back! It's like having a PVR that allows you to pause or rewind live TV - once you've used it a few times you'll wonder how you lived without it!
The thing is few debuggers (command line or IDE-based) provide the hooks to have a "step backwards" button, so a custom solution has to be rigged in, which can be a pain in the arse.
There are just SO many cool features you can add to an emulator to make development easier I could go on for ages! Shame I can't give details though :-(
_________________
Big thanks to everyone who donated for Quake2
#140930 - Lazy1 - Thu Sep 20, 2007 8:20 pm
| simonjhall wrote: |
Or actually, even more favourite is the old "it doesn't break when I put printfs in" one!
|
Yeah, what the hell is with that anyway?
#140931 - kusma - Thu Sep 20, 2007 8:25 pm
| Lazy1 wrote: |
Yeah, what the hell is with that anyway? |
I believe it has to do with varargs-functions aligning the stack-pointer.
#140940 - tepples - Thu Sep 20, 2007 8:53 pm
| simonjhall wrote: |
| About a year ago it looked like I was working with some obscure hardware for the long haul and decided to write myself a full-blown emulator for the thing - the tool proved so useful for debugging that I rarely run it on the real kit as I can't be bothered to power it on! The only reason I'd run it on the kit is to get the speed boost. |
Or possibly because of latent differences between the kit and the emulator. If you were on Nintendo Entertainment System homebrew forums before Nintendulator became as accurate as it is today, you'd have met up with Michel Iwaniec (aka "Bananmos") who decried the tendency at the time for self-styled "NES homebrew developers" to test their programs exclusively on emulators. A lot of releases from this era (2000 to 2005) do not even boot when run on an NES with a hand-soldered flash card because their developers unwittingly relied on defects in the emulators from the era.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#140947 - DiscoStew - Thu Sep 20, 2007 9:35 pm
Not an annoying bug, but something that you'd give yourself a quick slap on the forehead for.
When working on a project of mine, I came up with an idea to improve processing, so I backed up the project, then loaded it up, began doing the code, compiled, then tested it on the emulator. Everything worked fine, but I got no performance increase from it. I checked a few other things. Same result. I then commented out a line, just to see what would happen. No change. Commented out some more. No change. Finally, I was getting fed up that I stopped for a few hours to think of why the method wasn't changing. Tired of the whole ordeal, I decide to run a different project I had worked on earlier. Navigating through the folders, it hit me.........
I had been editing the project from the "back up" folder the entire time! No wonder the test rom never changed. The emulator was still loading from the original folder.
_________________
DS - It's all about DiscoStew
#140950 - simonjhall - Thu Sep 20, 2007 9:53 pm
@tepples, yeah, that's very true. It does bug me a bit when we get messages on here when people are doing obscure stuff in an emulator (eg dmaing command lists to the gfx fifo) and never actually tested it on the hardware until they want to share it with the world! You'd think on a machine where it's not properly understood people would favour developing on the real thing versus under emulation.
But yeah that is one reason why I do sometimes try it on the real machine, simply because of the hundred plus instructions in the ISA I can't believe I coded them all 100% correctly! Some of them must fail in 'extreme' cases...
_________________
Big thanks to everyone who donated for Quake2
#140955 - kusma - Thu Sep 20, 2007 10:26 pm
DiscoStew: I had a similar issue when working on a demo 5-6 years ago. I was tweaking some variables to get "just the right look", and I spent a couple of hours without ever getting things as I wanted it. Then after a while, I found out that I was editing the back-up, so in anger I gave up and went outside to booze. The demo was never released, and looking back, I think that's a good thing. It was very yellow ;)
#141645 - HyperHacker - Thu Sep 27, 2007 11:31 pm
I get this one every now and then. The program crashes with evidence of memory corruption. I add some debug output to track it down. Eventually, it just starts working again. I remove the output and restore the code to exactly how it was before, and it works. Then a few hours later, it starts crashing again!
_________________
I'm a PSP hacker now, but I still <3 DS.
#142964 - keldon - Mon Oct 15, 2007 6:02 pm
I just got the best "stupid" bug ever. The plan was to quickly make a little tool to boost production to output particular files. At first I had problems with the phoney Java specification for outputting bytes; I can't say I've ever used Java for outputting binary files in my life so after finding the appropriate method for outputting bytes I faced the horror of getting the same output.
For hours I was puzzled about it, until I realized that somewhere along the lines I managed to miss out the code that outputted the file; so a file dialog will appear and look like it's saving. Patching was the culprit as I was taking code that worked for one method and tried to blend it together, since the method was the same and all that got messed up was the fact that you write to the file after writing to your buffer - which I did not do because I previously wrote directly to the file stream. Also note that I was reading the exact same file for about an hour or two in a HEX editor!!!
... Another fun one was wondering why my colours were looking odd; I thought I was missing bits somehow ... nope, just a bad colour profile on the different screens ^_^ The problem I had there was that there was no metric other than the human eye - and the mind's [mis]interpretation of it!!!!
What a waste of a bunch of hours >_>