[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