Welcome, Guest. Please login or register.

Author Topic: Find what is causing GURU 8000003  (Read 7746 times)

Description:

0 Members and 3 Guests are viewing this topic.

Offline bbond007Topic starter

  • Hero Member
  • *****
  • Join Date: Mar 2009
  • Posts: 1517
    • Show all replies
Find what is causing GURU 8000003
« on: March 07, 2012, 06:04:24 AM »
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.
« Last Edit: March 07, 2012, 06:10:43 AM by bbond007 »
 

Offline bbond007Topic starter

  • Hero Member
  • *****
  • Join Date: Mar 2009
  • Posts: 1517
    • Show all replies
Re: Find what is causing GURU 8000003
« Reply #1 on: March 07, 2012, 08:20:30 PM »
Quote from: Gilloo;682770
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.

Quote from: billyfish;682783
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.

Quote from: 560SL;682805
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
« Last Edit: March 07, 2012, 08:23:11 PM by bbond007 »
 

Offline bbond007Topic starter

  • Hero Member
  • *****
  • Join Date: Mar 2009
  • Posts: 1517
    • Show all replies
Re: Find what is causing GURU 8000003
« Reply #2 on: March 08, 2012, 12:00:22 AM »
Quote from: 560SL;682844
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?
« Last Edit: March 08, 2012, 12:05:32 AM by bbond007 »
 

Offline bbond007Topic starter

  • Hero Member
  • *****
  • Join Date: Mar 2009
  • Posts: 1517
    • Show all replies
Re: Find what is causing GURU 8000003
« Reply #3 on: March 08, 2012, 12:47:15 AM »
Quote from: bloodline;682869
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.
« Last Edit: March 08, 2012, 01:06:17 AM by bbond007 »
 

Offline bbond007Topic starter

  • Hero Member
  • *****
  • Join Date: Mar 2009
  • Posts: 1517
    • Show all replies
Re: Find what is causing GURU 8000003
« Reply #4 on: March 08, 2012, 11:04:57 PM »
Quote from: billyfish;682783
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.
« Last Edit: March 08, 2012, 11:09:21 PM by bbond007 »
 

Offline bbond007Topic starter

  • Hero Member
  • *****
  • Join Date: Mar 2009
  • Posts: 1517
    • Show all replies
Re: Find what is causing GURU 8000003
« Reply #5 on: March 09, 2012, 12:05:43 AM »
Quote from: Gilloo;682909
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!
 

Offline bbond007Topic starter

  • Hero Member
  • *****
  • Join Date: Mar 2009
  • Posts: 1517
    • Show all replies
Re: Find what is causing GURU 8000003
« Reply #6 on: March 09, 2012, 12:18:29 AM »
Quote from: Piru;682988
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!
 

Offline bbond007Topic starter

  • Hero Member
  • *****
  • Join Date: Mar 2009
  • Posts: 1517
    • Show all replies
Re: Find what is causing GURU 8000003
« Reply #7 on: March 09, 2012, 01:00:50 AM »
Quote from: Piru;682999
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.


Interesting... TmpRas seems pretty logical knowing a little how the blitter works, but I was pretty sketchy about the purpose of AreaBuffer...

thanks.