Strange hardware breaking bug!

Hi, I have a very peculiar bug that emerges from a seemingly simple line of code and I don't understand how it happens, here is a simplified version of the code

type source
   field toX#, toY#
end type


;Main loop
repeat
   ;....<i>lots of other stuff goes here....</i>
   for s.source=each source
      special(s)
   next
   renderworld
   flip
until endgame 
;end main loop here

function special(s.source)
   repeat
      a=0
      s\toX=rnd(1,3) : s\toY=rnd(1,3)
      for s2.source=each source
      ;THE FOLLOWING LINE IS CAUSING THE BUG, IF I COMMENT IT OUT NO MORE BUG!
         if s2<>s and s2\toX=s\toX and s2\toY=s\toY then a=1
      next
   until a=0
end function

It's part of a much larger framework (4000+ lines) for 2D/3D games, but the algorythm in question is very simple (the "source" type only contains 3 objects at most)

Every time I run this code section, the computer hangs, screen display becomes corrupted(little red dots in a grid appear on screen) and I have to go and reinstall the 3D card drivers or Windows won't even boot!

Anybody has an idea what's going on and what can cause this bug and the hardware corruption?
I know it could be a problem with my 3D card (geforce 6600) but the point is that, this particular line of code, and only this one, will always trigger the problem.
And I don't see anything there that should trigger a problem. As I said it's not a very intensie part of the program (there are much more intensive and complex algorythms in other places of the program) and the list of "source" objects is comprised of 3 objects at most.

Add these lines to the beginning of you program:

Graphics3D 800,600,16,1
SetBuffer BackBuffer()
c=CreateCamera()

And add this line after the ";....lots of stuff goes here...." line:

   If KeyHit(1) Then endgame=True

You needed to enter a screen mode (you forgot that in you example but it was in the original code?)
You need a camera. The "screen corruption" is just an uncleared BackBuffer.
It hangs because you have an endless loop - your "Repeat/Until" exiting variable never gets set to True.

As far as Windows not being able to boot, how can you reinstall the drivers if Windows isn't booted?
Or how can you reinstall the drivers if the screen is corrupted?

When I looked at you code, I added the Graphics3D and If/Then endgame=True lines before running your code. It did indeed have a "corrupted screen" of various rectangles of random colors, some light rectangles and some dark. I exited and the screen was fine. I ran the code again with no modifications and the screen was completely black. I added the CreateCamera line so that the BackBuffer would always get cleared.

Another thought. Were you running it with or without Debug?

Thanks for answering, my code contains screen declaration and camera and a way to exit the main loop and everything, I just didn't want to include them for the sake of getting to the heart of the problem.
It's interesting that you get a corrupted screen too, it's strange given the nature of the code.
With or wthout debug the problem is the same.
when it happens, I have to start windows in failsafe mode, uninstall drivers and reinstall.

Let me guess, it's windows vista?

To me this sounds like you pressed the reset button when directx was doing some "do not disturb" stuff.

But I really never heard of a blitz problem that killed the card driver.

Maybe in the function special you should use:

until a=0 or keydown(1)<>0 instead of only
until a=0

cause this line:
if s2<>s and s2\toX=s\toX and s2\toY=s\toY then a=1
seems to always set a to 1.

No it doesn't because s\tox and s\toY are set to a random value each.
But you' right that it's most likely an infinite loop problem.
And no it's not Vista.

I'm starting to think that maybe I should add parenthesis like this

if (s2<>s) and (s2\toX=s\toX) and (s2\toY=s\toY) then a=1

Maybe blitz is trying to make a logical and between things that it shouldn't?

It should however not break your hardware...

Imagine

Fatal Error $EF3A24:

You missed a bracket, your computer will now explode - press a key to continue.

Bad memory or bad video memory
reseat memory and video card
check your memory

You used to be able to break the BBC from software. If you turned the Cassete auto on and off really fast loads of times.
And Ive been told that you used to be able to crash the heads of HDs if you toldthem to park in the middle of the disk.

However I dont think you are breaking any hardware here.

But anyway, questions to the B3D programers. What does

AofTapeA <> BofTypeA

do?
Does it return True if A is not pointing to the same instance as B? or Does it return True if any of the member fields of A do not equal the member Fields of B?

I want to see the real code.

cyberyoyo: your if statement is fine.
H&K: it tells if A and B are pointing to the same instance.

You only exit when you get two matches of two floating point numbers?

You know how long it will take to get a single matching float out of the random number generator given there are 10,000,000 possible unique floats between the range specified???

I would guess there is a locked vertex or pixel buffer that will be released by the renderworld which is causing the problem of breaking your infinite loop or you are simply running in fullscreen when you should be debugging in windowed mode?

Off topic:



Damn....


You know, I didn't think about that! I had 4 BBCs and all of them ended up with broken tape hardware (It would load "?????.??" and it would be a bad program hehe.
I was using the tape motor control as a form of network device between the machines. Was nothing cooler than hearing a click followed by seeing a pixel appear on the other machine :) (actually, hearing your voice come out of the BBC speaker was better...)

I ended up making a crossover cable. Save on one machine. Load on the other. Hit enter at the same time :D

No, I exit if the numbers are NOT matching. (and in the real case these are not floating point but integers).

Thanks everybody who responded, actually it WAS a hardware problem, and I had to change my graphic adapter.
It's just a (really strange) coincidence that it was only happening in the same spot of the code.

Incidentally I had to revert to my in-board graphic card (geforce 6100) and it's a good thing because it enables me to test and optimize my code on a very slow hardware :).

you need a computer science cource.
ICE 9 you say well.