[Prev][Next][Index][Thread]

Re: Programs that dont't work (MacInTax + gdb note)



>>I tried running MacInTax and the 2 utility programs that come with  
>>it.  All of them managed  

>>to die with different problems.  While running one of them under  
>>gdb I got the following:
>>
>>Program received signal 11, Segmentation fault
>>0xd0080000 in ?? ()
>>(gdb) bt
>>#0  0xd0080000 in ?? ()
>>#1  0x182a2 in ?? ()
>>#2  0x185b8 in ?? ()
>>#3  0x185f6 in ?? ()
>>#4  0x112d8 in ?? ()
>>#5  0x734c in ?? ()
>>#6  0x0 in ?? ()
>>
>>Is this a case of the program screwing with the high order 8 bits  
>>of a pointer?

Hmmm... although there is data in the top eight bits of the address  
(for people not too familiar with the origins of the Mac, the  
original Macintosh had a "straight" 68000 (some people call a 68040 a  
68000, so "straight" means an honest to goodness 68000 with no  
embellishments) which only supported a 24 bit address bus.  The  
people at Apple, being the wild and wacky guys they were decided to  
use the top eight bits of addresses (address registers were 32 bits  
long) to store information about Handles (pointers to pointers to  
memory, by using a pointer to a pointer memory that was allocated  
could be moved and only the intermediate pointer would need to be  
changed [pardon my long digression]), I don't believe this is such a  
reference because of the "cleanness" of the address "0xd0080000",  
with four zeros at the end, there's a one in 32,768 chance that the  
last bits are going to be zeros (assuming an even address which is a  
good assumption and assuming that addresses are evenly spread out  
which isn't a real bad assumption).  What would really give more  
information would be to look at the instructions that preceeded the  
messed Program Counter.  That can be hard to do with a mystery jump,  
but it would be nice to see what is going on in frame 1, which you  
can do with gdb by saying:

(gdb) f 1		<-- "f 1" means set the context to the
			    function that called the function where
			    we died

(gdb) x/10i $pc-20	<-- This will display the ten instructions  
			    from 20 bytes previous to where the
			    dieing function was called.  (note if
			    $pc-20 doesn't work you can try $pc-22 or
			    even $pc-24, instruction sizes vary and
			    gdb will not always be able to resync if
			    you try to dissassemble from inside an
			    instruction).  This may give you enough
			    information to see how the program got
			    into deep doo doo.  Usually it isn't
			    sufficient in a case like this. 


>>MacInTax itself seems to have gotten itself caught in a loop:

PLEASE NOTE:  If you're going to run Executor under gdb, then it's  
best to invoke executor with the "-noclock".  When the clock is  
turned on it confuses gdb and so you sometimes will see what appears  
to be a loop but is really gdb getting confused by the clock  
interrupts (at 1/60th of a second between interrupts, gdb is going to  
see an interrupt between every command you type even if you're a real  
fast typist).

>>Program received signal 2, Interrupt
>>0x5008360 in syscall ()
>>(gdb) bt
>>#0  0x5008360 in syscall ()
>>#1  0x5bf08 in ?? ()
>>#2  0x24e48 in ?? ()
>>#3  0x500831c in _sigtramp ()
>>#4  0x14920 in ?? ()
>>#5  0x607e in ?? ()
>>#6  0x147542 in ?? ()
>>#7  0x146cdc in ?? ()
>>#8  0x138520 in ?? ()
>>#9  0xffffffff in ?? ()
>>Unable to read inferior memory.
>>vm_read: no space available(3)
>>Accessing page 0xffffe000 - 0x1fff for address 0xffffffff, length  
4.
>>(gdb) stepi
>>0x5008368 in syscall ()
>>(gdb) stepi
>>0x500836c in syscall ()
>>(gdb) stepi
>>0x5007856 in gettimeofday ()
>>(gdb) stepi
>>0x500785a in gettimeofday ()
>>(gdb) stepi
>>0x500785c in gettimeofday ()
>>(gdb) stepi
>>0x5007862 in gettimeofday ()
>>(gdb) stepi
>>0x5007868 in gettimeofday ()
>>(gdb) stepi
>>0x50078a0 in gettimeofday ()
>>(gdb) stepi
>>0x50078a2 in gettimeofday ()
>>(gdb) stepi
>>0x50078b2 in gettimeofday ()
>>(gdb) stepi
>>0x50078b4 in gettimeofday ()
>>(gdb) stepi
>>0x50078ba in gettimeofday ()
>>(gdb) stepi
>>0x50078bc in gettimeofday ()
>>(gdb) stepi
>>(gdb) stepi
>>0x24e48 in ?? ()
>>(gdb) stepi
>>0x24e4e in ?? ()
>>
>>When I run MacInTax directly (not under gdb) it just crashes.  Oh  
>>well.
>>
>>
>>barry

Hmmm... I'm not sure why you saw the different behaviour when you ran  
under gdb, with the possible exception that if the clock is on (which  
it is by default) then running under gdb will be real slow.

Did you try running any of these programs with "-dogmeat"?

	--Cliff