80000003 not enough beer :-) no, it occurs when the processor access on misalign data (critical on 68000)
8100000f, concerns memory list, bad free address, bad memory header.
You should check your all the structures, especially where BYTE or UBYTE are present and add pads to align data.
Yesterday(while researching 8000000f noticed that I had a UCHAR * tempBuffer that was as TmpRas for AreaDraw so I changed that PLANEPTR. The dangers of copping code off the internet
anyway I did change that. After reading your post I went back and looked at my structs and sure enough I had some UBYTEs.
I also saw the not enough beer refrence. I wonder who put that in there? Bil Herd? He was the beer guy
I was interested to see what the compiler was doing so I made a quick program that just printed out sizeof all my structures. They were all even, so I must have some option on the compiler set to do that. To be safe, I added another UBYTE _filler, and ran the program again and the structures stayed the same size.
Enforcer is good. In terms of memory bugs, since you're using SAS, try linking against MemLib which is in its extras folder. I found I had to rebuild MemLib to get it to work ok on my WinUAE but you might be ok. I also seem to recall having similar gurus when I had my PARAMS option in scopts set to "BOTH" rather than "STACK" but that may have been due to specifics in the project I was working on.
Good luck!
billy
I messed with that PARAMS option a while back, I tried register and both but instantly got link errors... I definitely have it on stack now.
Usually this means that some local variables that are on the stack are trashed at some point. Like, filling a char- array too long or similar. It can waste the return instructions from a function call, setting the program counter to absolutley weird addresses and causing the behaviour you describe. Adding stack can sometimes help to preserve the return instructions so you dont experience the problem.
Might sound cryptic, but check your stack variables to begin with.
I think I understand.
by stack variable, you mean I'm doing something like this...
int void broken()
{
char temp[3];
for(i=0;i<5;i++)
temp
= 0x00;
return 0;
}
I don't have many stack variables, in fact most of my local variables are just USHORTs used as counters. I'm mostly accessing the same global array of structures.
I did see a case where I did have that exact issue. It was only in the HAM mode rendering which I really not even testing. I have a few files with this default sketchup person that is drawn with just a few one polygons with like a zillion points each. That would have blown up the HAM mode, and I'm not sure what happens when you overflow AreaDraw, but that was probably happening too. The area draw buffer was buffer was not located on the stack though if I understand the stack variable thing correctly.
Its been a long time and I have gotten soft because I have been programming in C# and java for the last 10 years
Anyway, thanks for the help, I made a few changes based on these suggestions so hopefully the stability increases.
nate