»

[bbond007]

I have been just starting learning the intuition API and amiga software development and I'm using SAS c 6.48.

I have been doing all of my development on my Minimig 1.1 just for fun. Or maybe punishment. I'm not sure which.

I have all the updates to the SAS product I know of except for a Y2K thing I was not sure how to apply, and my Minimig always reverts back to 1994 anyway.

Anyway my application works pretty well for some time but typically I get a guru 80000003 and 8100000F at least once.

The hard part is that the application typically never gurus at the same point and the crashes are not repeatable.

I'm not doing anything super special. I'm just trying (and successfully I might add) to display 3D objects from google's 3D warehouse on my minimig.

I do a bunch of AllocVec initially when I load an object, and eventually FreeVec. but that's not typically when the application crashes. I tried giving the application more stack and that seem to help. I don't think the problem is in the 3D library I'm working on, otherwise it would start to draw erratically I'd think. I got a feeling its some noob thing I'm doing wrong with screens(I'm double buffering) or windows or IDCMP messages. It does the same thing eventually on my A1200 and WunUAE.

What are my options for tracking this down? I know there is Enforcer (and I'll switch to UAE or my A1200/060) but I'm not even sure if that the right tool to use. Or maybe somebody knows of a few common things to check for?

I do like the Amiga API and I think its pretty cool. It really lets you do some cool OS compatible stuff without resorting to taking total control of the machine.

I can show the source if it would help, but I'm asking someone to do my homework for me, but I could use a hint...

Thanks.

[Gilloo]

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.

[bbond007]

Originally Posted by Gilloo

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.

Originally Posted by billyfish

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.

Originally Posted by 560SL

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[i] = 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

[560SL]

Originally Posted by bbond007

by stack variable, you mean I'm doing something like this...

Yep, exactly. And it might not be so obvious either. I work daily with C- programming, for like 15 years now, and I still do mistakes likes this now and then.

Stack problems can be a challenge to track down since they may appear seemingly at random. Can be due to "litter" in uninitialized variables, and can run fine 9 times out of 10. What they do tend is to generate crashes that seem totally unrelated to what youre trying to do in your program, like alignment problems. Weird out program counter etc.

I never got too used with the debugging tools on the Amiga (Enforcer etc), if I need to track down a bug, I usually end up with just staring at the code, trying to figure out whats wrong.

As in love and war, everything is ok when it comes to debugging. Even printf- debugging.

Yeah, Ive heard people getting soft with Java... they dont even have to null- terminate their strings...

[TheBilgeRat]

Originally Posted by 560SL

Yep, exactly. And it might not be so obvious either. I work daily with C- programming, for like 15 years now, and I still do mistakes likes this now and then.

Stack problems can be a challenge to track down since they may appear seemingly at random. Can be due to "litter" in uninitialized variables, and can run fine 9 times out of 10. What they do tend is to generate crashes that seem totally unrelated to what youre trying to do in your program, like alignment problems. Weird out program counter etc.

I never got too used with the debugging tools on the Amiga (Enforcer etc), if I need to track down a bug, I usually end up with just staring at the code, trying to figure out whats wrong.

As in love and war, everything is ok when it comes to debugging. Even printf- debugging.

Yeah, Ive heard people getting soft with Java... they dont even have to null- terminate their strings...

You think those are strings in C?
"string" and "array" are just syntactic sugar.

[bbond007]

Originally Posted by 560SL

I never got too used with the debugging tools on the Amiga (Enforcer etc), if I need to track down a bug, I usually end up with just staring at the code, trying to figure out whats wrong.

As in love and war, everything is ok when it comes to debugging. Even printf- debugging.

Yeah, Ive heard people getting soft with Java... they dont even have to null- terminate their strings...

I was getting into Android programming, but really overall, I'm not terribly impressed with it. I'm sure saying this is like saying all good programs for the Amiga are created in assembler and not c or basic but all good programs for Android are created using the NDK and not SDK and dalvik. The NDK apparently offers like no support at the API level. Also the emulator sux...

Also, you don't get to write code that looks like this in java

if((*((POLYPTR*)a))->z == (*((POLYPTR*)b))->z)
return 0;
else
if((*((POLYPTR*)a))->z > (*((POLYPTR*)b))->z)
return 1;
else
return -1;


Thanks for the help! Like my new GURU?

[bloodline]

Originally Posted by bbond007

I was getting into Android programming, but really overall, I'm not terribly impressed with it. I'm sure saying this is like saying all good programs for the Amiga are created in assembler and not c or basic but all good programs for Android are created using the NDK and not SDK and dalvik. The NDK apparently offers like no support at the API level. Also the emulator sux...

Also, you don't get to write code that looks like this in java

if((*((POLYPTR*)a))->z == (*((POLYPTR*)b))->z)
return 0;
else
if((*((POLYPTR*)a))->z > (*((POLYPTR*)b))->z)
return 1;
else
return -1;


Thanks for the help! Like my new GURU?

Hmmm, I hate java... This can't really find a good excuse to bother to learn the Android API... You should try iPhone programming... Then you're back into good old C... With a weird smalltalk style object oriented API on top (it's more fun than it sounds ).

[billyfish]

What are my options for tracking this down? I know there is Enforcer (and I'll switch to UAE or my A1200/060) but I'm not even sure if that the right tool to use. Or maybe somebody knows of a few common things to check for?

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

[560SL]

Originally Posted by bbond007

I tried giving the application more stack and that seem to help.

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.

[bbond007]

Originally Posted by billyfish

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

MemLib was a good idea. It found one memory leak that I had just recently created when I added an an array of pointers for sorting and apparently neglected to free it in my cleanup function. More interestingly it was able to detect this condition as "trailer trashed". see the "* DisplayBPP" in the AllocVec... I know thats wrong, i just find it strange that it would trash memory. I'd think its simply a waste of memory (MAX_POLY_VERT was already way more than needed) . unless displayBPP was a floating point between 0 and 1... which its not...


if(areaBuffer = AllocVec(MAX_POLY_VERT * DisplayBPP, MEMF_CLEAR))
{
InitArea(&areaInfo, areaBuffer, MAX_POLY_VERT);


thanks for the help.

I'll use Memlib in the future as it beats my previous method of trying to remember what the chip and fast were before I ran the app.

[Piru]

Originally Posted by bbond007

More interestingly it was able to detect this condition as "trailer trashed". see the "* DisplayBPP" in the AllocVec... I know thats wrong, i just find it strange that it would trash memory. I'd think its simply a waste of memory (MAX_POLY_VERT was already way more than needed) . unless displayBPP was a floating point between 0 and 1... which its not...


if(areaBuffer = AllocVec(MAX_POLY_VERT * DisplayBPP, MEMF_CLEAR))
{
InitArea(&areaInfo, areaBuffer, MAX_POLY_VERT);

This is what InitArea autodoc says:

This function provides initialization for the vector collection matrix
such that it has a size of (max vectors ). The size of the region
pointed to by buffer (short pointer) should be five (5) times as large
as maxvectors. This size is in bytes.

The multiplier must be 5. It has nothing to do with display bits per pixel.

[bbond007]

Originally Posted by Piru

This is what InitArea autodoc says:


The multiplier must be 5. It has nothing to do with display bits per pixel.

oh, thanks for clarifying that. I think I'm guilty of not reading the docs. I wonder why 5?

Anyway, the interesting thing was I was getting the corruption on every object, and the vast majority of the objects were comprised of triangles, that 1024 would would have allowed for 170.

I had it set to 1024 so I'm just surprised I had any sort of error detected at all. I'm certainly not complaining.

Thanks!

[Piru]

Originally Posted by bbond007

I wonder why 5?

The buffer provided to InitArea is split into two arrays 1) flag table and 2) vector table.

Flag table is byte array, while vector table holds SHORTs (x, y). This gives you the multiplier of 5 (2 * sizeof(SHORT) + sizeof(UBYTE)).

Ellipse consumes two entries, move and draw one, except when closing a polygon, in which case extra entry for the final draw is added. There are also some internal optimization where unnecessary moves are removed.

[billyfish]

Originally Posted by bbond007

More interestingly it was able to detect this condition as "trailer trashed". see the "* DisplayBPP" in the AllocVec... I know thats wrong, i just find it strange that it would trash memory. I'd think its simply a waste of memory (MAX_POLY_VERT was already way more than needed) . unless displayBPP was a floating point between 0 and 1... which its not...

if(areaBuffer = AllocVec(MAX_POLY_VERT * DisplayBPP, MEMF_CLEAR))
{
InitArea(&areaInfo, areaBuffer, MAX_POLY_VERT);

This one has stung me in the past, areaBuffer needs to be 5 times bigger than the number of max number of points, take a look at

http://amiga.sourceforge.net/amigade...&action=Search

So that could give you the trashed trailer. You can confirm this by looking at the memory directly after the areaBuffer where MemLib will put

"\xBB\xBB\xBB\xBB\xBB\xBB\xBB\xBB"

If you keep watching that address in CodeProbe, you should see it change.

I'll use Memlib in the future as it beats my previous method of trying to remember what the chip and fast were before I ran the app.

It's saved a lot of my hair! :-)

billy