Random Compiling Crashes

[Cybearg]

Maybe it's just me, but it seems like things have gotten very unstable of late. I can save and recompile and it's almost a random chance as to whether it will work or not. Sometimes, I'll get a 2600basic.exe crash or an assembly error, then I'll save the project and recompile again (without making any changes) and it will work. It's almost random, and it's making it difficult to continue because I can't trust whether it's having a problem due to a real error or if it's just being fidgety. Any idea what's wrong?

 

I've included a version that I know works, but I saved and recompiled until I got an error, see below:

 

 

[2/18/2013 5:08:56 PM] bblint found the following errors in heartbreak.bas

warning(): Found 24 commands that use end, and 19 "end" commands.

Warning: Unable to open '2600basic_variable_redefs.h'

Warning: Unable to open '2600basic_variable_redefs.h'

Warning: Unable to open '2600basic_variable_redefs.h'

Warning: Unable to open '2600basic_variable_redefs.h'

Warning: Unable to open '2600basic_variable_redefs.h'

Warning: Unable to open '2600basic_variable_redefs.h'

--- Unresolved Symbol List

0.775 0000 ???? (R )

pfcenter 0000 ???? (R )

lifemax 0000 ???? (R )

selection 0000 ???? (R )

pulse 0000 ???? (R )

cooldown 0000 ???? (R )

blkcount 0000 ???? (R )

pfhalfwidth 0000 ???? (R )

 

Fatal assembly error: Source is not resolvable.

Errors were encountered during assembly.

 

After getting the above, I saved and recompiled again (making no changes), which is in the other .zip file.

 

When something like this happens you have to systematically analyze it. I first took Clonespy and compared both folders. Clonespy can tell me if the files are exactly the same by producing an output of matching files:

 

17793 C:\heartbroke\HBKernel10.asm	 17.02.2013 07:52
17793 C:\heartworks\HBKernel10.asm	 17.02.2013 07:52


15867 C:\heartbroke\heartbreak.bas	 18.02.2013 15:08
15867 C:\heartworks\heartbreak.bas	 18.02.2013 15:12

1016 C:\heartbroke\heartincludes.inc 17.02.2013 15:55
1016 C:\heartworks\heartincludes.inc 17.02.2013 15:55

 

So there is no apparent reason why it should fail, as the files are indeed exactly the same. Next we open the list file of the "broken" heart, and search for "error" (without quotation marks). After skipping a few irrelevant error words we arrive at the place where it broke:

 

1346 f50c	 .L068 ; rem if the player has zero lives, skip this part
1347 f50c
1348 f50c	 .L069 ; if lives = 0 then goto 410
1349 f50c
1350 f50c		 a5 f3	 LDA lives
1351 f50e		 c9 00	 CMP #0
heartbreak.bas.asm (1352): error: Illegal Addressing mode 'bne '.
1352 f510		 BNE ; feel free to modify the score graphics - just keep each digit 8 high
1353 f510	 ; and keep the conditional compilation stuff intact

 

BNE is an opcode. It stands for branch if not equal. At a low level programs do operations and go to different parts of the code depending on the result. So if you write "if lives = 0 then goto 410" then at the low level the program loads the value stored in the register you called lives, and compares it to zero. There are 2 possible choices. Either it is equal zero or it's not. In this case it looks like BB was trying to say if it's not zero goto... goto... wait, go where? What is missing is the destination. It really is just plain old missing. The error says illegal addressing mode, which in this case means the address mode is missing the argument (or operand) of where to go to.

 

So if you look at the "working" file it compiled just fine because this time BB put in the destination:

 

1346 f500	 .L068 ; rem if the player has zero lives, skip this part
1347 f500
1348 f500	 .L069 ; if lives = 0 then goto 410
1349 f500
1350 f500		 a5 f3	 LDA lives
1351 f502		 c9 00	 CMP #0
1352 f504		 d0 03	 BNE .skipL069
1353 f506	 .condpart5
1354 f506		 4c 80 f6	 jmp .410
1355 f509
1356 f509	 .skipL069
1357 f509	 .
1358 f509	 ;
1359 f509
1360 f509	 .L070 ; rem set up possible colors

 

You can also see things from the .bas file still in there, which makes it easy to search. The rem comment is there, and the jump statement contains the label 410 that you used as well. So I searched for the rem statement in your .bas file and the code around there seems normal (plus we already know it is 100% the same as the working copy).

 

So all this leads me to conclude that the problem is entirely on the BB side. It almost seems like it just timed out and passed everything along before finishing. It shouldn't do that though. I wonder if this problem is with bblint? Have you tried not using it? You have to start eliminating things until you find out when it works all the time. This is something you should really bring up in the BB forum though, because maybe somebody else who uses BB had this problem. It would be interesting to know if in fact BB simply times out after a while, and if you computer is doing something else in the background it could possibly delay it long enough to hit that timeout. Sounds a little far fetched to me, but I can't think of anything else off the top of my head. I would try without bblint though, that would be the first place I start.

 

... In case anyone has any ideas or is interested.

heartbroke.zip

heartworks.zip

[+Random Terrain]

You said at one time that you downloaded a different version of dasm. Could that be doing anything?

[Omegamatrix]

Its not DASM failing as that comes along later in the process. The "heartbreak.bas.asm" file that gets passed to DASM has been generated incorrectly.

[Cybearg]

And in any case, I'm using the 2003 version of DASM that is included with the Win7_64bit version from the Visual bB thread.

[RevEng]

With various unrelated parts running into weird errors (bblint warnings, 2600basic screwing up when generating internal labels, inability to open the variable redefs) and the error happening only after multiple save+recompile attempts, it sounds like an external problem... I could see this being caused by either resource exhaustion (memory, file handles) or filesystem corruption issues.

[Cybearg]

Hm, maybe. I haven't restarted in a month or two, though we're talking a 64 bit system with 16Gb of RAM.

[RevEng]

Sure, or it could be a bad dimm, or failing fan, or some other thing that can cause random failures.

 

I just don't believe it's a random failing with bB because bblint is a separate component (made by yours truly) and I've never run into random issues with bB before. Either something compiles or it doesn't, no matter how many times I try.

 

That said, I don't use vbb, and I use Linux. If anybody else has seen different non-deterministic behaviour, please chime in.

[+Random Terrain]

There are various times in the past when I tried to compile a program and I'd get an error, but the next time I'd try, it would compile. Restarting my computer always seemed to fix the problem. I also noticed that I'd get some kind of error when I pressed Ctrl + S to save and tried to compile too soon (without waiting a second or two). In other words, trying to compile while the program is saving can also cause a temporary problem. If I always wait a couple of seconds after saving and restart my computer every day, I never get weird errors that I shouldn't be getting.