• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re:Re:Re: How to contitnule this kind of kernel debug
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re:Re:Re: How to contitnule this kind of kernel debug

  • Subject: Re:Re:Re: How to contitnule this kind of kernel debug
  • From: searockcliff <email@hidden>
  • Date: Mon, 12 Jan 2009 17:37:26 +0800 (CST)
The memory content is below:

@0x85702a08: 0x85702a18      0x0019eed5      0x85702a20      0x75fdcf03

@0x85702a18: 0x00000000      0x00000000      0x0000000e      0xe9660048

0x85702a28:     0xefd10010        0xd8330010      0x8f900010        0xffff0000

0x85702a38:     0x00000144      0x00000000      0x00000000      0x0042ec54

0x85702a48:     0x0efb74d0        0x00000000      0x00000000      0x0000000e

0x85702a58:     0x00000010      0x00000000      0x00000008      0x00010202

0x85702a68:     0x85702ab0      0x00000010      0x00805f80        0x5c75fdcf

0x85702a78:     0x0000000e      0x0019ece0      0x00000010      0x00000000

0x85702a88:     0x00000000      0x00000000      0x00000008      0x00000000

0x85702a98:     0x00010202      0x00000000      0x85702ab0      0x00000000

0x85702aa8:     0x00000010      0x00000000      0x00000000      0x0fd12000

0x85702ab8:     0x0faa4100        0x8555e1d0      0x0fb8e8d0        @0x85702da8

0x85702ac8:     0x0013315e      0x001331fa       0x00000010      0x000000c0

0x85702ad8:     0x00220008      0x00000000      0x00000000      0x0faa4100

0x85702ae8:     0x00000000      0x0000002d      0x00000030      0x00000000

0x85702af8:      0x0faa4100        0x0fd12000       0x8555e1d0      0x0fb8e8d0

0x85702b08:     0x0f962a80        0x1088f640       0xffffffff       0x8558802a

@0x85702b18: 0x85702b38      0x8558805d      0x0fa40400        0x00220008

0x85702b28:     0x0fb8e8c0        0x85702d9c      0x0f1e3000        0x0e28557c


The address with "@" ahead is identified as a stack frame.

 

(gdb) x/i 0x0019eed5

0x19eed5 <trap_from_kernel+26>:     mov    i,%esp

(gdb) x/i 0x0013315e

0x13315e <dummy_putc>:          push   p

(gdb) x/i 0x8558805d

0x8558805d <MyTestUserClient::MyTestFunc2(GNS_COMMAND_EXCHANGE*, GNS_COMMAND_EXCHANGE*, unsigned long, unsigned long*)+51>:      leave 

(gdb)

 


在2009-01-12，searockcliff <email@hidden> 写道：

Thanks, Brian Bechtel
Now I get further in the kernel debug.
But I find that the address 0x0 has symbol IOUSBBus::IOUSBBus.

(gdb) x/4a 0x85702a08
0x85702a08: 0x85702a18 0x19eed5 <trap_from_kernel+26> 0x85702a20 0x75fdcf03
(gdb) x/4a 0x85702a18
0x85702a18: 0x0 <IOUSBBus::IOUSBBus(OSMetaClass const*)> 0x0 <IOUSBBus::IOUSBBus(OSMetaClass const*)> 0xe <IOUSBBus::IOUSBBus(OSMetaClass const*)+14> 0xe9660048
(gdb) x/4a 0x85702a28
0x85702a28: 0xefd10010 0xd8330010 0x8f900010 0xffff0000
(gdb) x/4a 0x85702a38
0x85702a38: 0x144 <IOUSBBus::MetaClass::alloc() const+6> 0x0 <IOUSBBus::IOUSBBus(OSMetaClass const*)> 0x0 <IOUSBBus::IOUSBBus(OSMetaClass const*)> 0x42ec54 <IOGeneralMemoryDescriptor::prepare(IODirection)>
(gdb) x/4a 0x85702a48
0x85702a48: 0xefb74d0 0x0 <IOUSBBus::IOUSBBus(OSMetaClass const*)> 0x0 <IOUSBBus::IOUSBBus(OSMetaClass const*)> 0xe <IOUSBBus::IOUSBBus(OSMetaClass const*)+14>
(gdb) x/4a 0x85702a58
0x85702a58: 0x10 <IOUSBBus::IOUSBBus(OSMetaClass const*)+16> 0x0 <IOUSBBus::IOUSBBus(OSMetaClass const*)> 0x8 <IOUSBBus::IOUSBBus(OSMetaClass const*)+8> 0x10202 <IOUSBWorkLoop::MetaClass::MetaClass()+20>
(gdb) x/4a 0x85702a68
0x85702a68: 0x85702ab0 0x10 <IOUSBBus::IOUSBBus(OSMetaClass const*)+16> 0x805f80 0x5c75fdcf
(gdb) x/4a 0x85702a78
0x85702a78: 0xe <IOUSBBus::IOUSBBus(OSMetaClass const*)+14> 0x19ece0 <lo_alltraps> 0x10 <IOUSBBus::IOUSBBus(OSMetaClass const*)+16> 0x0 <IOUSBBus::IOUSBBus(OSMetaClass const*)>
(gdb) x/4a 0x85702a88
0x85702a88: 0x0 <IOUSBBus::IOUSBBus(OSMetaClass const*)> 0x0 <IOUSBBus::IOUSBBus(OSMetaClass const*)> 0x8 <IOUSBBus::IOUSBBus(OSMetaClass const*)+8> 0x0 <IOUSBBus::IOUSBBus(OSMetaClass const*)>
(gdb) x/4a 0x85702a98
0x85702a98: 0x10202 <IOUSBWorkLoop::MetaClass::MetaClass()+20> 0x0 <IOUSBBus::IOUSBBus(OSMetaClass const*)> 0x85702ab0 0x0 <IOUSBBus::IOUSBBus(OSMetaClass const*)>
(gdb) x/4a 0x85702aa8
0x85702aa8: 0x10 <IOUSBBus::IOUSBBus(OSMetaClass const*)+16> 0x0 <IOUSBBus::IOUSBBus(OSMetaClass const*)> 0x0 <IOUSBBus::IOUSBBus(OSMetaClass const*)> 0xfd12000
(gdb) x/4a 0x85702ab8
0x85702ab8: 0xfaa4100 0x8555e1d0 0xfb8e8d0 0x85702da8
(gdb) x/4a 0x85702ac8
0x85702ac8: 0x13315e <dummy_putc> 0x1331fa <conslog_putc> 0x10 <IOUSBBus::IOUSBBus(OSMetaClass const*)+16> 0xc0 <IOUSBBus::getMetaClass() const>
(gdb) x/4a 0x85702ad8
0x85702ad8: 0x220008 <bond_ioctl+1893> 0x0 <IOUSBBus::IOUSBBus(OSMetaClass const*)> 0x0 <IOUSBBus::IOUSBBus(OSMetaClass const*)> 0xfaa4100
(gdb) x/4a 0x85702ae8
0x85702ae8: 0x0 <IOUSBBus::IOUSBBus(OSMetaClass const*)> 0x2d <IOUSBBus::IOUSBBus(OSMetaClass const*)+5> 0x30 <IOUSBBus::IOUSBBus(OSMetaClass const*)+8> 0x0 <IOUSBBus::IOUSBBus(OSMetaClass const*)>
(gdb) x/4a 0x85702af8
0x85702af8: 0xfaa4100 0xfd12000 0x8555e1d0 0xfb8e8d0
(gdb) x/4a 0x85702b08
0x85702b08: 0xf962a80 0x1088f640 0xffffffff 0x8558802a <MyTestUserClient::MyTestFunc(GNS_COMMAND_EXCHANGE*, GNS_COMMAND_EXCHANGE*, unsigned long, unsigned long*)>
(gdb) x/4a 0x85702b18
0x85702b18: 0x85702b38 0x8558805d <MyTestUserClient::MyTestFunc2(GNS_COMMAND_EXCHANGE*, GNS_COMMAND_EXCHANGE*, unsigned long, unsigned long*)+51> 0xfa40400 0x220008 <bond_ioctl+1893>
(gdb) x/4a 0
0x0 <IOUSBBus::IOUSBBus(OSMetaClass const*)>: Cannot access memory at address 0x0
(gdb) x/i 0
0x0 <IOUSBBus::IOUSBBus(OSMetaClass const*)>: Cannot access memory at address 0x0
(gdb) x/4x 0
0x0 <IOUSBBus::IOUSBBus(OSMetaClass const*)>: Cannot access memory at address 0x0

Ther kernel stack before 0x85702a08(panic handle) or after 0x85702b18(my driver functions) is right, the bad frame is 0x85702a18, with the next frame pointer and instruction both as 0.

 

I get the .sym file by "kextload -s " on the debug target machine before kernel panic occurs.

I begin a new kernel debug,add-symbol-file com.apple.iokit.IOUSBFamily.sym,
 find that the 0(zero) address aslo has symbol IOUSBBus::IOUSBBus, why this happened?

Is the .sym file wrong?
What should I do next?
Thanks a lot!

byangs-imac:k byang$ gdb mach_kernel
GNU gdb 6.3.50-20050815 (Apple version gdb-768) (Tue Oct  2 04:07:49 UTC 2007)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-apple-darwin"...
(gdb) source kgmacros
Loading Kernel GDB Macros package.  Type "help kgm" for more info.
(gdb) x/i 0
0x0: Cannot access memory at address 0x0
(gdb) add-symbol-file /Users/byang/Desktop/symb/com.apple.iokit.IOUSBFamily.sym add symbol table from file "/Users/byang/Desktop/symb/com.apple.iokit.IOUSBFamily.sym"? (y or n) y
Reading symbols from /Users/byang/Desktop/symb/com.apple.iokit.IOUSBFamily.sym...Reading symbols from /Users/byang/Desktop/k/IOUSBFamily.kext.dSYM/Contents/Resources/DWARF/IOUSBFamily...done.
done.
(gdb) x/i 0
0x0 <IOUSBBus::IOUSBBus(OSMetaClass const*)>: Cannot access memory at address 0x0
(gdb)

 

在2009-01-08，"Brian Bechtel" <email@hidden> 写道：
>On Wed, Jan 7, 2009 at 12:27 AM, searockcliff <email@hidden> wrote:
>> Hi All,
>> I meet one kernel panic.
>> When I begin to debug the kernel, I cannot get the back trace.
>> All the backtrace in panic log is about panic handling, except the 0x0
>> instruction :
>> 0x85666a18 : 0x0 (0xe 0xe9660048 0xefd10010 0xd8330010)
>> I find one application's kernel_stack is wrong too.
>> task        vm_map      ipc_space  #acts   pid  proc        command
>> 0x0e58e770  0x0e5d1b40  0x0dc611cc    3   2528  0x0dfc7750  TESTAPP
>>             thread      processor   pri  state  wait_queue  wait_event
>>             0x0e5964f0  0x7c361000   31  R
>>   kernel_stack=0x85664000
>>   stacktop=0x00000000
>>   stackbottom=0xfffffff0
>> Could anybody give some hint about how to continue my kernel debug?
>> Thanks a lot!
>
>dump the memory starting at the kernel_stack address and see if you
>can manually decode stack frames.  Something has destroyed your stack.
>
>> Mon Jan  5 16:50:55 2009
>> panic(cpu 0 caller 0x001A8CEC): Kernel trap at 0x00000000, type 14=page
>> fault, registers:
>> CR0: 0x8001003b, CR2: 0x7c794000, CR3: 0x00f3b000, CR4: 0x00000660
>> EAX: 0x00000000, EBX: 0x0042ec54, ECX: 0x00000000, EDX: 0x0dd09b00
>> CR2: 0x00000000, EBP: 0x00000000, ESI: 0x00000144, EDI: 0xffff0000
>> EFL: 0x00010212, EIP: 0x00000000, CS:  0x00000008, DS:  0x8f900010
>> Error code: 0x00000010
>> Backtrace (CPU 0), Frame : Return Address (4 potential args on stack)
>> 0x856668d8 : 0x12b0fa (0x459234 0x8566690c 0x133243 0x0)
>> 0x85666928 : 0x1a8cec (0x4627a0 0x0 0xe 0x461f50)
>> 0x85666a08 : 0x19eed5 (0x85666a20 0x75fdcf03 0x0 0x0)
>> 0x85666a18 : 0x0 (0xe 0xe9660048 0xefd10010 0xd8330010)
>> Backtrace terminated-invalid frame pointer 0
>> BSD process name corresponding to current thread: SntlKeysSrvrmac
>> Mac OS version:
>> 9F33
>> Kernel version:
>> Darwin Kernel Version 9.5.0: Wed Sep  3 11:29:43 PDT 2008;
>> root:xnu-1228.7.58~1/RELEASE_I386
>> System model name: MacPro3,1 (Mac-F42C88C8)
>
>Something has jumped to location zero.  You should dump the memory for
>the stack frames
>x/256x 0x856668d8
>
>and manually decode the stack frame instead.  Frames usually begin at
>0x???????8, and the first word is a pointer to the next frame.  You
>can also try repeatedly issuing an "x/a" command on the memory of the
>stack and see if any symbols match, i.e. the last known good frame is
>0x85666a18, so
>x/a 0x85666a18
>[return to repeat the command for the next address]
>[return to repeat the command for the next address]
>[return to repeat the command for the next address]
>[return to repeat the command for the next address]
>[return to repeat the command for the next address]
>[return to repeat the command for the next address]
>etc.
>
>Good luck.  A trashed stack can be very tedious to diagnose.

 



《大话西游外传》贺岁新作，送豪宅、送你5000元压岁钱


《大话西游外传》贺岁新作，送豪宅、送你5000元压岁钱 
 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden
References: 
 >Re:Re: How to contitnule this kind of kernel debug (From: searockcliff <email@hidden>)
 >Re: How to contitnule this kind of kernel debug (From: "Brian Bechtel" <email@hidden>)
 >How to contitnule this kind of kernel debug (From: searockcliff <email@hidden>)

  • Prev by Date: Re:Re: How to contitnule this kind of kernel debug
  • Next by Date: Re: How to contitnule this kind of kernel debug
  • Previous by thread: Re: How to contitnule this kind of kernel debug -----Does large memory affects?
  • Next by thread: Notification about a shutdown
  • Index(es):
    • Date
    • Thread