Watch Breaks crash my A1200 (SASC)

[ChaosLord]

There is a random bug in the game.  It appears maybe 10% of the time.

Some printf statements revealed the random bug is caused by
isOverlayTileNotBlank[0] wrongly being set to 1.
  Well this array is only write accessed 2 places in the whole program so its easy to look at and see that the written code is ok.  So its some -other- something that is illegally writing a 1 here, probably a bad subscript error somewhere.

So I logically decided to run the game under the debugger like this:
> run cpr chaos

then I typed:
> d isOverlayTileNotBlank[0]
0

so it starts at the correct value

then I put a watch break on that var so the prog will stop and put the cursor on the offending line of code.

> wb isOverlayTileNotBlank[0]
> g

At this point 1 of 2 things randomly happens:
A: Ramlib gurus with an #80000004
B: cpr reports a bizarre "unknown signal 19", displays some asm code and locks up the computer.

I tried several times and I also tried:
> wb *isOverlayTileNotBlank

All attempts resulted in crashes.


I haven't used a watch break in years but last time I did, it worked perfectly.

So what is causing watch breaks to fail?

A: My elbox mediator?
B: My elbox/p96/cgx S3 Virge gfx driver?
C: My code is too large? (157000+ lines)
D: I am using the patched version of cpr from aminet which removes those dreadful enforcer hits from the original sasc cpr?

E: Other?


Yes I am using SASC v6.58 which I have used for 512 years or since the 1990s, whichever is less.

I have Apollo 060/50Mhz, 32 megs ram

The only hack I have on my Amiga1200 is the elbox stuff and
MagicMenu.  I do not run crazy stuff like Executive or MCP.

[Castellen]

Using Codeprobe ver 6.58 (same as yours?) here and I've not seen that before.  Though I rarely use watch breaks.

I do run crazy stuff like Executive and MCP   :-)


If it helps, send me the relevant source and includes and any other info needed to reproduce the problem, and I'll see if it does it here.  Then you can narrow it down to CPR or something in your setup.

Don't suppose it matters too much, but have you checked what debug options set during compile?  I normally use FULLFLUSH.

[ChaosLord]

Yes I always use Debug=FULLFLUSH
which makes the exe over 4 megs.

Another possibile cause of the problem could be something
to do with I link with several asm modules.
That should work perfectly, right?  But in fact, many times
cpr randomly teleports itself into an asm module that
cannot possibly be executing.  Usually pressing return once or twice fixes things.

[Castellen]

Yeah, I would have expected that should work.  Though I've never used watch breaks when Codeprobe is jumping through assembly modules.
You've got to question why it's going into them if they're not being called though?  Compiled C code can sometimes generate some weird assembly...
Don't forget to disable any optimisation during compile.

I have found a problem with Codeprode that when it opens it's own screen (default) which is 1024 x 768, same as WB, instead of having the C code in the top window, it sometimes only has an assembly listing.  Perhaps that only happens on larger Picasso96 screenmodes?  I haven't looked into it.

Forcing it to open on the WB screen fixes the problem.
cpr -screen Workbench or add the tooltype "-screen Workbench" to the debug icon.

Give that a try.  Doubt if it's related, but you never know.