home *** CD-ROM | disk | FTP | other *** search
/ Executor 2.0 / executorv2.0.iso / pc / linux / extra / docs / maillist / text / archive.92 / text0009.txt < prev    next >
Encoding:
Text File  |  1996-04-02  |  4.4 KB  |  134 lines
  1. >>I tried running MacInTax and the 2 utility programs that come with  
  2. >>it.  All of them managed  
  3.  
  4. >>to die with different problems.  While running one of them under  
  5. >>gdb I got the following:
  6. >>
  7. >>Program received signal 11, Segmentation fault
  8. >>0xd0080000 in ?? ()
  9. >>(gdb) bt
  10. >>#0  0xd0080000 in ?? ()
  11. >>#1  0x182a2 in ?? ()
  12. >>#2  0x185b8 in ?? ()
  13. >>#3  0x185f6 in ?? ()
  14. >>#4  0x112d8 in ?? ()
  15. >>#5  0x734c in ?? ()
  16. >>#6  0x0 in ?? ()
  17. >>
  18. >>Is this a case of the program screwing with the high order 8 bits  
  19. >>of a pointer?
  20.  
  21. Hmmm... although there is data in the top eight bits of the address  
  22. (for people not too familiar with the origins of the Mac, the  
  23. original Macintosh had a "straight" 68000 (some people call a 68040 a  
  24. 68000, so "straight" means an honest to goodness 68000 with no  
  25. embellishments) which only supported a 24 bit address bus.  The  
  26. people at Apple, being the wild and wacky guys they were decided to  
  27. use the top eight bits of addresses (address registers were 32 bits  
  28. long) to store information about Handles (pointers to pointers to  
  29. memory, by using a pointer to a pointer memory that was allocated  
  30. could be moved and only the intermediate pointer would need to be  
  31. changed [pardon my long digression]), I don't believe this is such a  
  32. reference because of the "cleanness" of the address "0xd0080000",  
  33. with four zeros at the end, there's a one in 32,768 chance that the  
  34. last bits are going to be zeros (assuming an even address which is a  
  35. good assumption and assuming that addresses are evenly spread out  
  36. which isn't a real bad assumption).  What would really give more  
  37. information would be to look at the instructions that preceeded the  
  38. messed Program Counter.  That can be hard to do with a mystery jump,  
  39. but it would be nice to see what is going on in frame 1, which you  
  40. can do with gdb by saying:
  41.  
  42. (gdb) f 1        <-- "f 1" means set the context to the
  43.                 function that called the function where
  44.                 we died
  45.  
  46. (gdb) x/10i $pc-20    <-- This will display the ten instructions  
  47.                 from 20 bytes previous to where the
  48.                 dieing function was called.  (note if
  49.                 $pc-20 doesn't work you can try $pc-22 or
  50.                 even $pc-24, instruction sizes vary and
  51.                 gdb will not always be able to resync if
  52.                 you try to dissassemble from inside an
  53.                 instruction).  This may give you enough
  54.                 information to see how the program got
  55.                 into deep doo doo.  Usually it isn't
  56.                 sufficient in a case like this. 
  57.  
  58.  
  59. >>MacInTax itself seems to have gotten itself caught in a loop:
  60.  
  61. PLEASE NOTE:  If you're going to run Executor under gdb, then it's  
  62. best to invoke executor with the "-noclock".  When the clock is  
  63. turned on it confuses gdb and so you sometimes will see what appears  
  64. to be a loop but is really gdb getting confused by the clock  
  65. interrupts (at 1/60th of a second between interrupts, gdb is going to  
  66. see an interrupt between every command you type even if you're a real  
  67. fast typist).
  68.  
  69. >>Program received signal 2, Interrupt
  70. >>0x5008360 in syscall ()
  71. >>(gdb) bt
  72. >>#0  0x5008360 in syscall ()
  73. >>#1  0x5bf08 in ?? ()
  74. >>#2  0x24e48 in ?? ()
  75. >>#3  0x500831c in _sigtramp ()
  76. >>#4  0x14920 in ?? ()
  77. >>#5  0x607e in ?? ()
  78. >>#6  0x147542 in ?? ()
  79. >>#7  0x146cdc in ?? ()
  80. >>#8  0x138520 in ?? ()
  81. >>#9  0xffffffff in ?? ()
  82. >>Unable to read inferior memory.
  83. >>vm_read: no space available(3)
  84. >>Accessing page 0xffffe000 - 0x1fff for address 0xffffffff, length  
  85. 4.
  86. >>(gdb) stepi
  87. >>0x5008368 in syscall ()
  88. >>(gdb) stepi
  89. >>0x500836c in syscall ()
  90. >>(gdb) stepi
  91. >>0x5007856 in gettimeofday ()
  92. >>(gdb) stepi
  93. >>0x500785a in gettimeofday ()
  94. >>(gdb) stepi
  95. >>0x500785c in gettimeofday ()
  96. >>(gdb) stepi
  97. >>0x5007862 in gettimeofday ()
  98. >>(gdb) stepi
  99. >>0x5007868 in gettimeofday ()
  100. >>(gdb) stepi
  101. >>0x50078a0 in gettimeofday ()
  102. >>(gdb) stepi
  103. >>0x50078a2 in gettimeofday ()
  104. >>(gdb) stepi
  105. >>0x50078b2 in gettimeofday ()
  106. >>(gdb) stepi
  107. >>0x50078b4 in gettimeofday ()
  108. >>(gdb) stepi
  109. >>0x50078ba in gettimeofday ()
  110. >>(gdb) stepi
  111. >>0x50078bc in gettimeofday ()
  112. >>(gdb) stepi
  113. >>(gdb) stepi
  114. >>0x24e48 in ?? ()
  115. >>(gdb) stepi
  116. >>0x24e4e in ?? ()
  117. >>
  118. >>When I run MacInTax directly (not under gdb) it just crashes.  Oh  
  119. >>well.
  120. >>
  121. >>
  122. >>barry
  123.  
  124. Hmmm... I'm not sure why you saw the different behaviour when you ran  
  125. under gdb, with the possible exception that if the clock is on (which  
  126. it is by default) then running under gdb will be real slow.
  127.  
  128. Did you try running any of these programs with "-dogmeat"?
  129.  
  130.     --Cliff
  131.  
  132.  
  133.  
  134.