Find what is causing GURU 8000003

[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.

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

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]

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

[560SL]

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]

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]

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]

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 ).

[bbond007]

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 ).

My real problem with the iPhone is I'd need to develop on a mac. I do have one of the older style core2 minis but no laptop...

Then I'd make some adventure game where you start out taking the wheels off for your car (which is suspended on blocks) and it would offend Apple and I'd get my app removed.

I may try the NDK, I used it to some extent to do a native version of box2d because the java version was pretty jittery because of GC, but communicating between the layers is tedious. There is an example of how to get a straight c program to open an OpenGL window in the NDK, but that's a pretty basic place to start as far as an app...  

I have written a little textured quad sprite engine for Android in java that can also make a basic terminal console type window (used a font called topaz8) for streaming info. I suppose the next step would be to port that to the NDK/c, and finally, Hello World.

I really started messing with the 3D stuff on the Amiga to take a step backwards and really try and learn the basics of 3D because I was struggling with OpenGL ES.

[Gilloo]

hu... you put beer into your structs :-) to make them growing but no overfilled.

when you use registers options, do you include prototypes in your programs ?
Like that:

/* C standards */
#include

/* Amiga specifics */
#include

/* Protos */
#include
#include

int main(int argc, char *argv[])
{
 /* ... */
}

[bbond007]

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]

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.

[billyfish]

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/amigadevhelp/phpwebdev.php?keyword=InitArea&funcgroup=AmigaOS&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

[bbond007]

hu... you put beer into your structs :-) to make them growing but no overfilled.

when you use registers options, do you include prototypes in your programs ?
Like that:

/* C standards */
#include

/* Amiga specifics */
#include

/* Protos */
#include
#include

int main(int argc, char *argv[])
{
 /* ... */
}

I got it to work, it was some dialog requester source i used and modified that used K&R style function headers... it did not like that.. changed the public facing ones to the more contemporary format and it linked.

thanks!