This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

Fun with strange bugs!

Fun with strange bugs!
by on (#226810)
I don't know if I should have put that in general instead since I think I may not find an answer about it and it will become about everything and nothing but for now let's just start the thread here ;)

Have you ever had a bug where it doesn't seems to make much sense and the temporary solution shouldn't be working in the first place? I just got one of those today.

I was modifying a group of method that required an extra flag for some status. After finishing the task and starting to test it, I had a strange bug where something was going wrong that was not supposed to be affected by the current modification. Since it didn't work, I decided to roll back and to compare the new/old code. Nothing strange was added.

So I decided to remake it step by step, starting first with the simplest modification: increasing the size of a temp buffer by 1. To my surprise, just changing the size created the issue. Puzzled, I decide to create a new variable after the buffer. Same issue. Remove it and put buffer to original size: working. Then I had that strange idea of "let's put a new variable just after that group of zp" and... it's now working. Wth :lol:

I cannot be a page boundary bug since it's just a group of zp variables that if I look at the map file, are defined around A0~A9. It just doesn't make sense to just move it and it works.

It may be that I just found a bug where another function is actually using something in that group that it's not supposed or write to something it's not supposed either, maybe, it just that it may take time until I find the cause and was just weird and fun at the same time when I found the cause.

Even if I show how the variables are defined, I don't think there is anything wrong with it so I won't come back on the subject until I dig a little bit more in the code.

Have you ever had one of those strange bugs while writing nes code and the solution didn't make sense either?
Re: Fun with strange bugs!
by on (#226811)
Not on the NES, but code that's so broken it emphatically should not be working yet does so flawlessly is par for the course for me. :D

I've improved my coding style immensely in the last few months though. I really should stop using C, it lets me get away with so many dumb things...
Re: Fun with strange bugs!
by on (#226812)
A few days ago, I had a SNES bug like that. When I added the priority bit in a single nametable word, several other tiles on screen became corrupted. WTF, that function doesn't even touch those tiles.

Half an hour later: a couple functions later, one function running in a8i16 mode does a TAX without clearing high A.
Re: Fun with strange bugs!
by on (#226813)
I can tell you that I'm way too obsessed about coding mistakes to just roll back and carry on when something seemingly unrelated breaks! Whenever that happens to me, I spend as much time as it takes to figure out *exactly* what went wrong, otherwise something even more sinister may end up happening in the future...
Re: Fun with strange bugs!
by on (#226814)
tokumaru wrote:
I can tell you that I'm way too obsessed about coding mistakes to just roll back and carry on when something seemingly unrelated breaks! Whenever that happens to me, I spend as much time as it takes to figure out *exactly* what went wrong, otherwise something even more sinister may end up happening in the future...


I feel the same way, there is an odd sound glitch in my game that happens whenever an explosion sound effect (using software volumes) lines up with a noise percussion hit (which uses envelopes). I've been meaning to go back to it and since I never had the willpower to find where the issue is, I've been putting off working on the project for a while now... but I hope I'm right when I assume that it's as simple as me updating an APU register when I shouldn't.
Re: Fun with strange bugs!
by on (#226829)
@Rahsennor

Don't C and drive :P Jokes aside, C with pointers can cause all kind of interesting bug when you're not careful and don't know the platform. One example of this (not my code) is to assume that IIS 7+ server is like Apache 1.3 and there is only one instance per request so there is no issue having static content inside that module while processing the page!....

For people that don't know IIS, C/CPP native modules are run in a multi-threaded environment which means the same instance can be reused multiple time, which mean you CANNOT do like apache module and keep some static reference since you will end up with content from multiple request mixed up and security goes by the window... It was so much fun to fix... I think this is after that "incident" that I started coding for the nes since I needed a break ^^;;; So maybe it was a good thing after all :lol:

@calima

That little thing that you don't see after a while.. This was my case for the bug above. I couldn't let go and checked the possible code that could be the cause when I saw this:

Code:
     lda $0F        ; For now, the color for erasing the background is hardcoded


Then it became pretty obvious that I was not "sharp" enough when I wrote that line :lol: I love #... This little bug was there since a while and never ended up on it.

@tokumaru

Same thing here actually. I couldn't let go and reviewed some code that could be the cause and found it. What made me click is that fact that increasing the variable size/quantity caused the change which meant something was affected by the location. Once I saw the code above I realized right away the error.

@za909

I had tons of bugs in my collision code and other logic for ladder which impeded progress. So what I did is I took a break and worked on other part on my engine. That way, that reduced the tension about not being able to find a proper way to do it while still advancing the project, which is a win-win situation. Once I will get back on that code I may find the error more easily.
Re: Fun with strange bugs!
by on (#226871)
C is just a terrible language all around. It fails as a high-level language, because it's as error-prone and hard to read as assembler, and it fails as a low-level language, because at that point you're better off actually using assembler. It sort-of succeeds at being a 'portable' pseudo-assembler... but writing portable C is almost impossible!

For example, this code is not portable:

Code:
bool brute_force_test(void)
{
   for(int i = INT_MAX; i > INT_MIN; i--)
   {
      if(unit_test(i) == false)
      {
         return false;
      }
   }

   return true;
}

See if you can spot the bug.
Re: Fun with strange bugs!
by on (#226873)
It depends.

since I do not know what is unit_test function does and what ranges it can process it is hard to say the real issue. One thing for sure, since INT_MAX/INT_MIN can change size per platform, if unit_test access an array with that value it could go out of bound and fun ensue.

That would be the most concerning part of it. If there is something else, I didn't do C for ages (except now for the nes but that's not real C anyway :lol:) that I'm not seeing it.
Re: Fun with strange bugs!
by on (#226876)
Quote:
See if you can spot the bug.


C doesn't have bool types. "true" and "false" are meaningless until you define them.

Oh, wait...

"The C programming language, as of C99, supports Boolean arithmetic with the built-in type _Bool (see _Bool). When the header <stdbool.h> is included".

I guess my C programming book is old, since it was written in 1978.
Re: Fun with strange bugs!
by on (#226887)
I suppose I should have been more specific... assume unit_test() accepts every possible value of int without crashing, and that INT_MIN is excluded from the range intentionally. There is a bug in brute_force_test() itself, one that will result in it silently missing a unit test failure.

On the first iteration, i = INT_MAX. So we have:

Code:
INT_MAX > INT_MIN
= INT_MAX - INT_MIN > 0
= 0x7FFFFFFF - -0x80000000 > 0
= 0x7FFFFFFF + 0x80000000 > 0
= 0xFFFFFFFF > 0
= -1 > 0
= false

And so the loop never executes.

This is a perfectly standards-compliant optimization, performed by real compilers on commercially-deployed systems. Enjoy.
Re: Fun with strange bugs!
by on (#226894)
I see. That's an interesting case since the code intention is valid but because of the compiler behavior the result is not. I never uses INT_MAX/INT_MIN but manually writing the literal would have caused the same issue.

Since the bug is a sign based one, I assume the way to make it works is by changing int to an unsigned int so it would uses the proper range of MAX/MIN.

It was an interesting one for the fun and strange ones thread that leave you scratching you head until you realize it.

Thanks!
Re: Fun with strange bugs!
by on (#226899)
Banshaku wrote:
@calima

That little thing that you don't see after a while.. This was my case for the bug above. I couldn't let go and checked the possible code that could be the cause when I saw this:

Code:
     lda $0F        ; For now, the color for erasing the background is hardcoded


Then it became pretty obvious that I was not "sharp" enough when I wrote that line :lol: I love #... This little bug was there since a while and never ended up on it.


I've been stung by this soooo many times, I got the assembler dev to add a warning to the assembler for me. Never again!

Oh there have been a lot of fun bugs over the years... The it just so happens ones are always the best..

Like that one time some code that shipped in 3 games, suddenly blew up on the 4th.. it went something like this
Code:
{
  int SomeVar = something
  bunch of code here
}

int thing = SomeVar + otherThing.
to be clear the SomeVar outside of the scope is not declared anywhere else. So for 3 games it just so happened that the SomeVar's value didn't get trashed.. However on the 4th it did and went horribly wrong.. Many of us stared at the code and tried to work out how it compiled. Fixed and well a compiler programmer somewhere got a very angry email !

The PrintFBandit bugs are also common. You get a bug.. you add a printf to find it.. it goes away.. the bug only shows up when you are not trying to hunt it...
Re: Fun with strange bugs!
by on (#226901)
Rahsennor wrote:
C is just a terrible language all around. It fails as a high-level language, because it's as error-prone and hard to read as assembler, and it fails as a low-level language, because at that point you're better off actually using assembler. It sort-of succeeds at being a 'portable' pseudo-assembler... but writing portable C is almost impossible!

I'm glad someone finally agrees with me on this. C is great if you want to get something done quickly, it gets the job done and is a fine tool. However it is not by any means a great language or inherently superior to it's concurrents, as it seems to be assumed by most people. The only reason C is so popular is because of some kind of snowball effect.
Re: Fun with strange bugs!
by on (#226902)
what are you calling its concurrents? B? or Comal?
Re: Fun with strange bugs!
by on (#226910)
Yeah. I think missing #s is a very common mistake in 6502 assembly in general, and it's sometimes hard to spot, in which in some cases the stuff still work most of the time(such as what I once encountered in my short demo).

Depending on systems, forgetting to clear/initialise RAM beforehand can generate hard to detect bugs too as the stuff may only break "sometimes" (I think a number of official Famicom/NES games were even released without noticing this).
Re: Fun with strange bugs!
by on (#226913)
Oziphantom wrote:
I've been stung by this soooo many times, I got the assembler dev to add a warning to the assembler for me. Never again!

Gilbert wrote:
Yeah. I think missing #s is a very common mistake in 6502 assembly in general, and it's sometimes hard to spot, in which in some cases the stuff still work most of the time(such as what I once encountered in my short demo).

I've been thinking of writing my own assembler, since I can't seem to find one picky enough to stop me doing dumb stuff. Maybe I should start a thread for common bugs I should make it look out for?

Oziphantom wrote:
Code:
{
  int SomeVar = something
  bunch of code here
}

int thing = SomeVar + otherThing.

:shock:

How did that compile. Why did that compile. Who wrote that compiler!?

Bregalad wrote:
I'm glad someone finally agrees with me on this.

Me too! We should start a C-haters club.

I kid. Though in all seriousness, I think the reason it's so popular is that every major OS is written in it. Thus anyone wanting to write code for any popular platform has to deal with it at some level. And anyone who writes an OS in anything else is forced to provide compatibility or fade into obscurity.

I've looked at loads of other programming languages in search of an alternative, but they all have one thing in common: they're not freestanding. They've all got great big libraries full of exception handling, garbage collection and Shinki knows what else that they haul around everywhere. The only people who are interested in freestanding programming languages are the OS devs, and they're all using stuff like C, because everyone uses C for OS development. It's a vicious cycle.

I've been trying to break the cycle - for me at least - by coming up with a freestanding language that's safer/stricter than C, but I'm a self-taught high school dropout. What would I know.
Re: Fun with strange bugs!
by on (#226914)
Rahsennor wrote:
Oziphantom wrote:
I've been stung by this soooo many times, I got the assembler dev to add a warning to the assembler for me. Never again!

Gilbert wrote:
Yeah. I think missing #s is a very common mistake in 6502 assembly in general, and it's sometimes hard to spot, in which in some cases the stuff still work most of the time(such as what I once encountered in my short demo).

I've been thinking of writing my own assembler, since I can't seem to find one picky enough to stop me doing dumb stuff. Maybe I should start a thread for common bugs I should make it look out for?

http://tass64.sourceforge.net/ see the diagnostic and warning areas at the end
constant result, possibly changeable to 'lda'
could be shorter by using 'xxx' instead
could be simpler by using 'xxx' instead
immediate addressing mode suggested
independent result, possibly changeable to 'lda'
label defined instead of variable multiplication for compatibility
possible jmp ($xxff) bug
possibly redundant as ...
possibly redundant if last 'jsr' is changed to 'jmp'
possibly redundant indexing with a constant value
duplicate definition
shadow definition
symbol is defined in an upper scope as well and is used ambiguously


Rahsennor wrote:
Oziphantom wrote:
Code:
{
  int SomeVar = something
  bunch of code here
}

int thing = SomeVar + otherThing.

:shock:

How did that compile. Why did that compile. Who wrote that compiler!?

I don't know, or that either. NDAs forbid me from saying which compiler, and where we got it from, but lets just say for a very large and popular console.

Rahsennor wrote:
Bregalad wrote:
I'm glad someone finally agrees with me on this.

Me too! We should start a C-haters club.

I kid. Though in all seriousness, I think the reason it's so popular is that every major OS is written in it. Thus anyone wanting to write code for any popular platform has to deal with it at some level. And anyone who writes an OS in anything else is forced to provide compatibility or fade into obscurity.

I've looked at loads of other programming languages in search of an alternative, but they all have one thing in common: they're not freestanding. They've all got great big libraries full of exception handling, garbage collection and Shinki knows what else that they haul around everywhere. The only people who are interested in freestanding programming languages are the OS devs, and they're all using stuff like C, because everyone uses C for OS development. It's a vicious cycle.

I've been trying to break the cycle - for me at least - by coming up with a freestanding language that's safer/stricter than C, but I'm a self-taught high school dropout. What would I know.

Commodore once wrote an OS in BCPL this was not looked on favorably and the switch to ASM and C was a massive improvement loved by all. The thing is you need something like C so you can actually hit a memory location, the higher level languages are great but when you need to do INT 5 they are kind of lost at sea.
Re: Fun with strange bugs!
by on (#226917)
It just happens too often that you accidentally end up using zero page memory access instead of an immediate value. Had the 6502 assembly language been originally developed to require you to prefix both immedate values and memory accesses, this kind of mistake would slip through much less often.

Whenever I find an instance of this happening during my debugging process, I get the urge for an ultimate facepalm.
Re: Fun with strange bugs!
by on (#226956)
@Rahsennor

The reason I like C (to some degree) it that in the dos days, it was a lot of fun to use that and allowed to access the hardware instead of using asm. With Turbo C, you could even add inline asm so it was quite useful. I did use Quick Basic 4.5 or TP 7 but TC was the one I had the most fond memories.

Didn't do any OS programming though. Still, I guess this may be why I like the C syntax. Doesn't mean I like Java though :lol:

@Oziphantom

That's a nasty one :lol: Sometime it's not because it's from a big company that it means there is no bug ^^;;

@Gilbert

Loom.. Fond memory of that too under dos. I remember using that with my new "non continuous read" cd-rom on my 286 with 1 meg of ram!... ^^;;

@za909

I think ca65 had some < to let it know it was some zero page value (many of Shiru's example had that) but it was causing all kind of warning in 2.17 so I just removed them.
Re: Fun with strange bugs!
by on (#226966)
That's one thing turning me off from official console dev. Having to use their (crappy) compiler, in their (crappy) IDE, and most probably on (ewwww) Windows too. I doubt any of them would be amenable to taking a binary from a homebrew toolchain, even if it was compliant with every spec.
Re: Fun with strange bugs!
by on (#226967)
Quote:
what are you calling its concurrents? B? or Comal?

Quote:
Me too! We should start a C-haters club.
[...]
I've been trying to break the cycle - for me at least - by coming up with a freestanding language that's safer/stricter than C, but I'm a self-taught high school dropout. What would I know.

The direct concurents to C was Pascal, and then Ada (which was itself largely inspired by pascal). Both are stricter and safer.
Higher level languages with automatic memory management are not direct concurrents as they do not have the same purpose.
Re: Fun with strange bugs!
by on (#227013)
tokumaru wrote:
I can tell you that I'm way too obsessed about coding mistakes to just roll back and carry on when something seemingly unrelated breaks! Whenever that happens to me, I spend as much time as it takes to figure out *exactly* what went wrong, otherwise something even more sinister may end up happening in the future...


I am the same way. I don't accept not knowing why something works or doesn't work, especially considering that I have direct access to the individual instructions being read by the processor, and can set breakpoints to see the status of registers at basically every moment in time. The chances that the instructions aren't being interpreted by the emulator correctly are extremely slim, so it's a coding mistake almost 100% of the time.

The only time I've used a solution where I didn't understand why it fixed my problem was with a PHP script I was writing for a website. In the script, I called a MySQL routine and tried to then use the same "connection" to execute a MySQL query afterwards. The call to the routine would work, but I kept getting errors right when trying to run the second query. I would remove the call to the routine, and the second query would work. I would replace the call to the routine with another query, and both would work. I could not figure it out, and based on my research, it really looked like I should have been able to do that. My solution was to use two different "connections" to the database (one for the call to the routine, and another for the query), and it started working. I never understood why I had to do that, and it still bothers me today!
Re: Fun with strange bugs!
by on (#227029)
@Celius

Hey, long time no see :D