It is currently Thu Dec 13, 2018 5:15 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 23 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: Fun with strange bugs!
PostPosted: Wed Oct 03, 2018 1:00 am 
Offline
User avatar

Joined: Tue Jun 24, 2008 8:38 pm
Posts: 2129
Location: Fukuoka, Japan
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?


Top
 Profile  
 
PostPosted: Wed Oct 03, 2018 1:17 am 
Offline

Joined: Thu Aug 20, 2015 3:09 am
Posts: 424
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...


Top
 Profile  
 
PostPosted: Wed Oct 03, 2018 1:40 am 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 849
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.


Top
 Profile  
 
PostPosted: Wed Oct 03, 2018 2:54 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11012
Location: Rio de Janeiro - Brazil
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...


Top
 Profile  
 
PostPosted: Wed Oct 03, 2018 3:07 am 
Offline
User avatar

Joined: Fri Jan 24, 2014 9:05 am
Posts: 164
Location: Hungary
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.


Top
 Profile  
 
PostPosted: Wed Oct 03, 2018 8:21 am 
Offline
User avatar

Joined: Tue Jun 24, 2008 8:38 pm
Posts: 2129
Location: Fukuoka, Japan
@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.


Top
 Profile  
 
PostPosted: Wed Oct 03, 2018 6:04 pm 
Offline

Joined: Thu Aug 20, 2015 3:09 am
Posts: 424
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.


Top
 Profile  
 
PostPosted: Wed Oct 03, 2018 6:18 pm 
Offline
User avatar

Joined: Tue Jun 24, 2008 8:38 pm
Posts: 2129
Location: Fukuoka, Japan
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.


Top
 Profile  
 
PostPosted: Wed Oct 03, 2018 6:29 pm 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 2354
Location: DIGDUG
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.

_________________
nesdoug.com -- blog/tutorial on programming for the NES


Top
 Profile  
 
PostPosted: Wed Oct 03, 2018 8:19 pm 
Offline

Joined: Thu Aug 20, 2015 3:09 am
Posts: 424
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.


Top
 Profile  
 
PostPosted: Wed Oct 03, 2018 9:11 pm 
Offline
User avatar

Joined: Tue Jun 24, 2008 8:38 pm
Posts: 2129
Location: Fukuoka, Japan
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!


Top
 Profile  
 
PostPosted: Wed Oct 03, 2018 10:59 pm 
Offline

Joined: Tue Feb 07, 2017 2:03 am
Posts: 629
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...


Top
 Profile  
 
PostPosted: Wed Oct 03, 2018 11:16 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7604
Location: Chexbres, VD, Switzerland
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.


Top
 Profile  
 
PostPosted: Wed Oct 03, 2018 11:20 pm 
Offline

Joined: Tue Feb 07, 2017 2:03 am
Posts: 629
what are you calling its concurrents? B? or Comal?


Top
 Profile  
 
PostPosted: Thu Oct 04, 2018 1:25 am 
Offline
User avatar

Joined: Sun Dec 12, 2010 10:27 pm
Posts: 328
Location: Hong Kong
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).


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 23 posts ]  Go to page 1, 2  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group