Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!caen!news.cs.indiana.edu!ariel.unm.edu!cie!jlavin
From: jlavin@cie.uoregon.edu (Jeff Lavin)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: What the #&%@?
Message-ID: <1991Mar06.111450.25191@ariel.unm.edu>
Date: 6 Mar 91 11:14:50 GMT
References: <7823@crash.cts.com>
Sender: jlavin@cie.oregon.edu (Jeff Lavin)
Reply-To: jlavin@cie.oregon.edu
Organization: The Puzzle Factory
Lines: 69

In article <7823@crash.cts.com> lkoop@pnet01.cts.com (Lamonte Koop) writes:
>
>I have come face to face with a rather perplexing problem involving a project
>I am currently working on, to which I cannot find the answer.  I'm hoping
>SOMEONE [read: ANYONE! please!] may have an idea as to what is going on. 
>Anyway, the problem goes like this:  The application I have set up uses a
>fairly standard Intuition interface setup...with the appropriate message
>handling loops and such.  The problem arises when the code I compile is
>executed on a stock 68000-based system (I am currently developing on a
>68030-accelerated system).  The event handling loops run perfectly normal when
>run on the 68030 (or a 68020 for that matter)...unfortunately, things begin to
>flake out when the program is run in the machine's 68000 mode...or any
>68000-based system.  The symptoms are thus:  at VERY random times, selecting a
>menu item will result in an Address error guru.  Now, most of the menu
>selections simply result in a function call or so.  The odd part is that there
>is NO way to predict which menu function will guru...or WHEN...It just
>happens.  This does not happen AT ALL when the program is run under an 020 or
>030 system. [No...the compiler is NOT set to compile for 020/030 specific code
>generation].  The layout of the event loop skeleton is somewhat like this:
>
>while(keepgoing) {
>   Wait(1L << BenchWindow->UserPort->mp_SigBit);
>   while((msg = (struct IntuiMessage *)GetMsg(BenchWindow->UserPort))) {
>     code = msg->Code;  class = msg->Class;
>     gad = ((struct Gadget *)msg->IAddress)->GadgetID;
                                     ^^^^ Right thar!
>     ReplyMsg((struct Message *)msg);
>
>     switch(class) {  /*start of the action-determining section*/
>        case MENUPICK : 
>             mnum = MENUNUM(code);
>             mitem = ITEMNUM(code);
>             subitem = SUBNUM(code);
>             switch(mnum) {  /*Determine action according to which menu*/
>                case 0 :
>                     if(!ShowAbout()) Error("Insufficient Memory!");
>                     break;
>                case 1 :
>                     if(!DoSysInfo()) Error("Unable to open window!");
>                     break;
> 
>Well, anyway that's the general idea.  There's more for processing gadgets,
>(and the rest of the menu items).  For example...case 1 above for menu 0 [the 
>DoSysInfo() call] will guru...SOMETIMES on a 68000 machine...NEVER on an 020
>or 030 machine.  The same goes for various other items.  Generally, the GURUs
>start to appear after I've done some other action first...but I've had them
>happen right off.  I've been trying to figure this out for a week now with no
>ideas at all.
> 
> [stuff deleted]

Your problem has to do with the fact that an '020 or '030 allows access to
words or longwords on odd boundaries.  When you have a 68000 this will cause
an address bus error.

When an IntuiMsg of CLASS(MENUPICK) comes in, im_IAddress is undefined.
As such, it will occasionally happen to be an odd address.  You are having
this problem because you are performing an operation in this field *before*
finding out if it was a GADGETUP or GADGETDOWN class.

The fix is easy: Just store the value in im_IAddress.  Don't extract the
gg_GadgetID or anything else until you know what, if anything, im_IAddress
is pointing to.


The Puzzle Factory, Inc.  | Jeff Lavin -- jlavin@cie.uoregon.edu
Veneta, Oregon            |-------------------------------------
Voice : (503) 935-3709    | Remainder of signature line
Data  : (503) 935-7883    | under construction.