Use the output of the -i, -q and -c -commands.
-THREAD at 6403c194 VPTR=f8046c18 AccessCount=5 Owner=6403bb4c
Full name t_dmasim::Main
Thread MState READY
Default priority 12 WaitLink Priority 12
ExitInfo 3,0,
Flags 00000002, Handles 6403b418
Supervisor stack base 6571d000 size 1000
User stack base 00403000 size 2000
Id=25, Alctr=00700000, Created alctr=00700000, Frame=00000000
Trap handler=00000000, ActiveScheduler=007000c8, Exception handler=00000000
TempObj=00000000 TempAlloc=00000000
NThread @ 6403c44c Pri 12 NState READY
Next=6403c44c Prev=6403c44c Att=03 iUserContextType=02
HeldFM=00000000 WaitFM=00000000 AddrSp=6403bb4c
Time=0 Timeslice=20 ReqCount=0
SuspendCount=0 CsCount=1 CsFunction=00000000
SavedSP=6571df98
DACR f800bd2c
R13_USR 0d404c38 R14_USR 00000001 SPSR_SVC 00000000
R4 f8022d84 R5 6571dfd4 R6 6571dfbc R7 f8022db8
R8 f800bddc R9 f800a454 R10 00000000 R11 f801daac
PC 60000010
In this example:
--
-
-
-
the kernel stack is the value of SavedSP, i.e. -0x6571df98.
-
- -
-
the user stack is the value of R13_USR, i.e. -0x0d404c38.
-
-
Related tasks
- - + + +Finding the Stack
+To trace back through a thread’s kernel or user stack, you first +need to find the stack pointer value. On the ARM, R13 always +points to the stack, but there are different R13 registers for +each processor mode:
+-
+
In thread context:
+-
+
-
+
R13usr points to the thread’s user +stack,
+
+ -
+
R13svc points to the thread’s kernel +stack.
+
+
+-
+
-
+
When handling interrupts, dedicated stacks are used:
+-
+
-
+
R13Fiq points to the stack used when +processing fast interrupts (FIQ).
+
+ -
+
R13Irq points to the stack used when +processing general purpose interrupts (IRQ)
+
+
+ -
+
To find out which stack to inspect, you need to know what mode the +CPU was in when the fault occurred. The +processor mode is identified by the five least-significant bits of the CPSR +register. To get the value of the CPSR register:
+-
+
-
+
use the f command when the +debug monitor is triggered by a hardware exception.
+
+ -
+
use the r command when the +debug monitor is triggered by a panic.
+
+
The following examples show how to find the stack(s):
+ +Use the f command.
+Fault Category: Exception Fault Reason: 10000000
ExcId 00000001 CodeAddr f816c908 DataAddr 80000001 Extra c0007003
Exc 1 Cpsr=60000010 FAR=80000001 FSR=c0007003
R0=00000000 R1=00000000 R2=30000000 R3=80000001
R4=00000001 R5=00403d88 R6=00002000 R7=f816c768
R8=00000012 R9=00000040 R10=00000000 R11=00403fa4
R12=00403d5c R13=00403d70 R14=f80906f8 R15=f816c908
R13Svc=6571e000 R14Svc=f80074bc SpsrSvc=80000010
In this example:
+-
+
-
+
the kernel stack is the value of R13Svc, i.e. +0x6571e00.
+
+ -
+
the user stack is the value of R13, i.e. +0x00403d70.
+
+
Use the r command.
+MODE_USR:
R0=6571de54 R1=0000002a R2=00000002 R3=ffffffff
R4=0000002a R5=f8170414 R6=6571df14 R7=6403cc50
R8=00000001 R9=6403c44c R10=640002f8 R11=6571de70
R12=00000020 R13=00404e00 R14=f80818c0 R15=f800bfa8
CPSR=60000013
MODE_FIQ:
R8=00000000 R9=ffffffff R10=ffffffff R11=00000000
R12=00000000 R13=64000d0c R14=c080079c SPSR=e00000dc
MODE_IRQ:
R13=6400110c R14=00000013 SPSR=20000013
MODE_SVC:
R13=6571de54 R14=f80328bc SPSR=60000010
MODE_ABT:
R13=6400090c R14=ccbfd0e0 SPSR=b00000d9
MODE_UND:
R13=6400090c R14=b5a39950 SPSR=f000009d
In this example:
+-
+
-
+
the kernel stack is the value of R13 under +MODE_SVC:, i.e. 0x6571de54.
+
+ -
+
the user stack is the value of R13 under +MODE_USR:, i.e. 0x00404e00.
+
+
Use the r command.
+MODE_USR:
R0=6571de54 R1=0000002a R2=00000002 R3=ffffffff
R4=0000002a R5=f8170414 R6=6571df14 R7=6403cc50
R8=00000001 R9=6403c44c R10=640002f8 R11=6571de70
R12=00000020 R13=00404e00 R14=f80818c0 R15=f800bfa8
CPSR=60000013
MODE_FIQ:
R8=00000000 R9=ffffffff R10=ffffffff R11=00000000
R12=00000000 R13=64000d0c R14=c080079c SPSR=e00000dc
MODE_IRQ:
R13=6400110c R14=00000013 SPSR=20000013
MODE_SVC:
R13=6571de54 R14=f80328bc SPSR=60000010
MODE_ABT:
R13=6400090c R14=ccbfd0e0 SPSR=b00000d9
MODE_UND:
R13=6400090c R14=b5a39950 SPSR=f000009d
In this example:
+-
+
-
+
the IRQ stack is the value of R13 under +MODE_IRQ:, i.e. 0x6400110c.
+
+ -
+
the FRQ stack is the value of R13 under +MODE_FIQ:, i.e. 0x64000d0c.
+
+
Use the output of the +i, +q and +c +commands.
+THREAD at 6403c194 VPTR=f8046c18 AccessCount=5 Owner=6403bb4c
Full name t_dmasim::Main
Thread MState READY
Default priority 12 WaitLink Priority 12
ExitInfo 3,0,
Flags 00000002, Handles 6403b418
Supervisor stack base 6571d000 size 1000
User stack base 00403000 size 2000
Id=25, Alctr=00700000, Created alctr=00700000, Frame=00000000
Trap handler=00000000, ActiveScheduler=007000c8, Exception handler=00000000
TempObj=00000000 TempAlloc=00000000
NThread @ 6403c44c Pri 12 NState READY
Next=6403c44c Prev=6403c44c Att=03 iUserContextType=02
HeldFM=00000000 WaitFM=00000000 AddrSp=6403bb4c
Time=0 Timeslice=20 ReqCount=0
SuspendCount=0 CsCount=1 CsFunction=00000000
SavedSP=6571df98
DACR f800bd2c
R13_USR 0d404c38 R14_USR 00000001 SPSR_SVC 00000000
R4 f8022d84 R5 6571dfd4 R6 6571dfbc R7 f8022db8
R8 f800bddc R9 f800a454 R10 00000000 R11 f801daac
PC 60000010
In this example:
+-
+
-
+
the kernel stack is the value of SavedSP, i.e. +0x6571df98.
+
+ -
+
the user stack is the value of R13_USR, i.e. +0x0d404c38.
+
+
Related tasks
+ + \ No newline at end of file diff -r bf0a333d965d -r a690706fd137 debuggercdi/com.nokia.carbide.cpp.debug.crashdebugger/html/DebuggingInformation/CrashDebuggerCallStack.guide04.html --- a/debuggercdi/com.nokia.carbide.cpp.debug.crashdebugger/html/DebuggingInformation/CrashDebuggerCallStack.guide04.html Thu Feb 18 15:22:38 2010 -0600 +++ b/debuggercdi/com.nokia.carbide.cpp.debug.crashdebugger/html/DebuggingInformation/CrashDebuggerCallStack.guide04.html Thu Feb 18 15:23:36 2010 -0600 @@ -1,108 +1,108 @@ - - -Tracing through the Stack Heuristically
--
-
-
-
some data words may look like code addresses in ROM.
-
- -
-
there may be saved return addresses left over from previous -function calls. For example, suppose that F() calls -A() and then B() in sequence. A() itself -calls X(), which calls Y(). If a crash occurs in -B(), the saved return addresses from the calls to X() -and Y() are still present on the stack and may be mistaken for -function calls occuring while B() is active.
-This scenario happens frequently when B() -allocates a buffer (e.g. TBuf) on the stack which overlaps -old stack frames.
---
-
-
If you want to trace applications loaded into RAM, then stack -tracing is more difficult because RAM-loaded DLLs are given addresses assigned -at load time.
-On ARM, the stack pointer starts at the higher address end and -moves 'down' towards the lower address end. This means that values at the top -of the memory dump are more recent. You need to look back through this for code -addresses. For ROM code this will be words with most significant byte in the -range 0xF8 to 0xFF, remembering that they are -little-endian. This can either be done manually, or automatically using the -printsym.pl perl script, which can be found in -...\epoc32\tools.
-Let's follow this in an example session:
--
-
-
-
Decide whether the crash has been caused by a panic or an -exception using the f command:
-.f
-
Fault Category: EXAMPLE Fault Reason: 0000002a
ExcId 00000000 CodeAddr 00000000 DataAddr 00000000 Extra 00000000
- -
-
This shows that the crash was caused by a panic, so now use the -r command to find -the CPU mode and the stack pointer:
-.r
-
MODE_USR:
R0=6571de54 R1=0000002a R2=00000002 R3=ffffffff
R4=0000002a R5=f8170414 R6=6571df14 R7=6403cba8
R8=00000001 R9=6403c41c R10=640002f8 R11=6571de70
R12=00000020 R13=00404e00 R14=f80818c0 R15=f800bfa8
CPSR=60000013
MODE_FIQ:
R8=00000000 R9=ffffffff R10=ffffffff R11=00000000
R12=00000000 R13=64000d0c R14=c080079c SPSR=e00000dc
MODE_IRQ:
R13=6400110c R14=00000013 SPSR=20000013
MODE_SVC:
R13=6571de54 R14=f80328bc SPSR=60000010
MODE_ABT:
R13=6400090c R14=ffff0010 SPSR=400000d7
MODE_UND:
R13=6400090c R14=95221110 SPSR=f000009dThe panic happened in supervisor mode, because CPSR & -0x1F == 0x13, so R13Svc, i.e. the value of R13 -shown under MODE_SVC: in the above display, is the stack pointer -to look at; this has the value 0x6571DE54.
-
- -
-
Using the -m command to look -at memory starting at location 0x6571DE54 gives:
-.m6571de54+200
-
6571de54: 07 00 00 10 14 04 17 f8 00 00 00 00 d4 4e 40 00 .............N@.
6571de64: e8 de 71 65 74 de 71 65 74 fb 16 f8 88 28 03 f8 ..qet.qet....(..
6571de74: 0c d4 03 f8 64 35 03 f8 00 00 00 00 00 00 00 00 ....d5..........
6571de84: d0 00 00 00 14 df 71 65 a8 cb 03 64 a8 cb 03 64 ......qe...d...d
6571de94: d0 00 00 00 14 df 71 65 1c df 71 65 ec 4e 40 00 ......qe..qe.N@.
6571dea4: 1c c4 03 64 b4 2a 03 f8 00 00 00 00 14 df 71 65 ...d.*........qe
6571deb4: d0 de 71 65 c4 de 71 65 b0 ab 03 f8 00 00 00 00 ..qe..qe........
6571dec4: e0 ba 03 64 14 df 71 65 1c df 71 65 01 00 00 00 ...d..qe..qe....
6571ded4: 1c c4 03 64 f8 02 00 64 10 df 71 65 ec de 71 65 ...d...d..qe..qe
6571dee4: 84 da 01 f8 5c fb 16 f8 00 4e 40 00 00 00 00 00 ....\....N@.....
6571def4: 00 4e 40 00 00 00 00 00 d3 00 00 00 ec 4e 40 00 .N@..........N@.
6571df04: d4 df 71 65 14 df 71 65 e0 db 01 f8 c0 d9 01 f8 ..qe..qe........
6571df14: a8 cb 03 64 e0 ba 03 64 01 00 01 00 00 00 00 00 ...d...d........
6571df24: 00 00 00 00 d4 4e 40 00 00 00 00 30 40 00 00 00 .....N@....0@...
6571df34: 13 00 00 60 98 df 71 65 48 df 71 65 f4 81 00 f8 ...`..qeH.qe....
6571df44: 8c 7a 00 f8 68 df 71 65 58 df 71 65 6c df 71 65 .z..h.qeX.qel.qe
6571df54: 60 df 71 65 0c 2b 00 f8 bc 2a 00 f8 84 df 71 65 `.qe.+...*....qe
6571df64: 70 df 71 65 e4 7d 04 f8 08 2b 00 f8 0d 00 00 00 p.qe.}...+......
6571df74: 0a 00 00 30 40 00 00 00 54 65 73 74 44 6d 61 53 ...0@...TestDmaS
6571df84: 69 6d 04 f8 a9 4b 40 00 b8 df 71 65 9c df 71 65 im...K@...qe..qe
6571df94: 2c be 00 f8 2c bd 00 f8 38 4c 40 0d 01 00 00 00 ,...,...8L@.....
6571dfa4: 00 00 00 00 84 2d 02 f8 d4 df 71 65 bc df 71 65 .....-....qe..qe
6571dfb4: b8 2d 02 f8 dc bd 00 f8 54 a4 00 f8 00 00 00 00 .-......T.......
6571dfc4: ac da 01 f8 10 00 00 60 d8 df 71 65 70 74 00 f8 .......`..qept..
6571dfd4: b8 da 01 f8 d4 4e 40 00 20 f7 16 f8 d0 4e 40 00 .....N@. ....N@.
6571dfe4: 00 00 00 00 00 00 00 00 ec 4e 40 00 40 00 00 00 .........N@.@...We can look for potential ROM addresses by scanning the log and -look up the corresponding function name in the symbol file generated -using the MAKSYM tool . The first -one is 0xF8170414 at offset 4 in the memory dump. -
-
- -
-
Alternatively, we can use the printsym.pl perl -script, passing it the dump output. The following is part of the output:
-R:\base\e32\rombuild>perl -S printsym.pl ASSABETARM4D.symbol
-
ROM Symbols from ASSABETARM4D.symbol
Please enter data to be decoded
6571de54: 07 00 00 10 14 04 17 f8 00 00 00 00 d4 4e 40 00 .............N@.
= 10000007 ....
= f8170414 .... etext=. + 0x0
= 00000000 ....
= 00404ed4 .N@.
6571de64: e8 de 71 65 74 de 71 65 74 fb 16 f8 88 28 03 f8 ..qet.qet....(..
= 6571dee8 ..qe
= 6571de74 t.qe
= f816fb74 t... DDmaTestChannel::DoCreate(int, TDesC8 const *, TVersion const &
) + 0x24
= f8032888 .(.. Kern::Fault(char const *, int) + 0xc
6571de74: 0c d4 03 f8 64 35 03 f8 00 00 00 00 00 00 00 00 ....d5..........
= f803d40c .... RHeap::Alloc(int) + 0xf4
= f8033564 d5.. Kern::MutexSignal(DMutex &) + 0xc
= 00000000 ....
= 00000000 ....
[............ truncated ...............]
= f801da84 .... DLogicalDevice::ChannelCreate(DLogicalChannelBase *&, TChannelC
reateInfo &) + 0xd0
= f816fb5c \... DDmaTestChannel::DoCreate(int, TDesC8 const *, TVersion const &
) + 0xc
= 00404e00 .N@.
= 00000000 ....
6571def4: 00 4e 40 00 00 00 00 00 d3 00 00 00 ec 4e 40 00 .N@..........N@.
= 00404e00 .N@.
= 00000000 ....
= 000000d3 ....
= 00404eec .N@.
6571df04: d4 df 71 65 14 df 71 65 e0 db 01 f8 c0 d9 01 f8 ..qe..qe........
= 6571dfd4 ..qe
= 6571df14 ..qe
= f801dbe0 .... ExecHandler::ChannelCreate(TDesC8 const &, TChannelCreateInfo &
, int) + 0x134
= f801d9c0 .... DLogicalDevice::ChannelCreate(DLogicalChannelBase *&, TChannelC
reateInfo &) + 0xc
[.......................... truncated .........................]
= f8022db8 .-.. ExecHandler::DebugPrint(void *, int) + 0x34
= f800bddc .... A::UserDebugPrint(unsigned char const *, int, int) + 0xc
= f800a454 T... EpocSlowExecTable + 0xc
= 00000000 ....
6571dfc4: ac da 01 f8 10 00 00 60 d8 df 71 65 70 74 00 f8 .......`..qept..
= f801daac .... ExecHandler::ChannelCreate(TDesC8 const &, TChannelCreateInfo &
, int) + 0x0
= 60000010 ...`
= 6571dfd8 ..qe
= f8007470 pt.. __ArmVectorSwi + 0xd8
6571dfd4: b8 da 01 f8 d4 4e 40 00 20 f7 16 f8 d0 4e 40 00 .....N@. ....N@.
= f801dab8 .... ExecHandler::ChannelCreate(TDesC8 const &, TChannelCreateInfo &
, int) + 0xc
= 00404ed4 .N@.
= f816f720 ... etext=. + 0x560
= 00404ed0 .N@.
6571dfe4: 00 00 00 00 00 00 00 00 ec 4e 40 00 40 00 00 00 .........N@.@...
= 00000000 ....
= 00000000 ....
= 00404eec .N@.
= 00000040 @...
^C
R:\base\e32\rombuild>There are several false positives in this output (and even more -in the truncated parts). So some study of the source code is needed to discard -the noise and find the actual call stack. Here it is (innermost frame -first):
--
-
-
-
Kern::Fault
-
- -
-
DDmaTestChannel::DoCreate
-
- -
-
ExecHandler::ChannelCreate
-
- -
-
__ArmVectorSwi
-
-
Note that for the sake of the example, a call to Kern::Fault() was deliberately inserted into -DDmaTestChannel::DoCreate().
-All other function names are false positives and should be -ignored
-
- -
-
Related tasks
- - + + +Tracing through the Stack Heuristically
+-
+
-
+
some data words may look like code addresses in ROM.
+
+ -
+
there may be saved return addresses left over from previous +function calls. For example, suppose that F() calls +A() and then B() in sequence. A() itself +calls X(), which calls Y(). If a crash occurs in +B(), the saved return addresses from the calls to X() +and Y() are still present on the stack and may be mistaken for +function calls occuring while B() is active.
+This scenario happens frequently when B() +allocates a buffer (e.g. TBuf) on the stack which overlaps +old stack frames.
+++
+
+
If you want to trace applications loaded into RAM, then stack +tracing is more difficult because RAM-loaded DLLs are given addresses assigned +at load time.
+On ARM, the stack pointer starts at the higher address end and +moves 'down' towards the lower address end. This means that values at the top +of the memory dump are more recent. You need to look back through this for code +addresses. For ROM code this will be words with most significant byte in the +range 0xF8 to 0xFF, remembering that they are +little-endian. This can either be done manually, or automatically using the +printsym.pl perl script, which can be found in +...\epoc32\tools.
+Let's follow this in an example session:
+-
+
-
+
Decide whether the crash has been caused by a panic or an +exception using the f command:
+.f
+
Fault Category: EXAMPLE Fault Reason: 0000002a
ExcId 00000000 CodeAddr 00000000 DataAddr 00000000 Extra 00000000
+ -
+
This shows that the crash was caused by a panic, so now use the +r command to find +the CPU mode and the stack pointer:
+.r
+
MODE_USR:
R0=6571de54 R1=0000002a R2=00000002 R3=ffffffff
R4=0000002a R5=f8170414 R6=6571df14 R7=6403cba8
R8=00000001 R9=6403c41c R10=640002f8 R11=6571de70
R12=00000020 R13=00404e00 R14=f80818c0 R15=f800bfa8
CPSR=60000013
MODE_FIQ:
R8=00000000 R9=ffffffff R10=ffffffff R11=00000000
R12=00000000 R13=64000d0c R14=c080079c SPSR=e00000dc
MODE_IRQ:
R13=6400110c R14=00000013 SPSR=20000013
MODE_SVC:
R13=6571de54 R14=f80328bc SPSR=60000010
MODE_ABT:
R13=6400090c R14=ffff0010 SPSR=400000d7
MODE_UND:
R13=6400090c R14=95221110 SPSR=f000009dThe panic happened in supervisor mode, because CPSR & +0x1F == 0x13, so R13Svc, i.e. the value of R13 +shown under MODE_SVC: in the above display, is the stack pointer +to look at; this has the value 0x6571DE54.
+
+ -
+
Using the +m command to look +at memory starting at location 0x6571DE54 gives:
+.m6571de54+200
+
6571de54: 07 00 00 10 14 04 17 f8 00 00 00 00 d4 4e 40 00 .............N@.
6571de64: e8 de 71 65 74 de 71 65 74 fb 16 f8 88 28 03 f8 ..qet.qet....(..
6571de74: 0c d4 03 f8 64 35 03 f8 00 00 00 00 00 00 00 00 ....d5..........
6571de84: d0 00 00 00 14 df 71 65 a8 cb 03 64 a8 cb 03 64 ......qe...d...d
6571de94: d0 00 00 00 14 df 71 65 1c df 71 65 ec 4e 40 00 ......qe..qe.N@.
6571dea4: 1c c4 03 64 b4 2a 03 f8 00 00 00 00 14 df 71 65 ...d.*........qe
6571deb4: d0 de 71 65 c4 de 71 65 b0 ab 03 f8 00 00 00 00 ..qe..qe........
6571dec4: e0 ba 03 64 14 df 71 65 1c df 71 65 01 00 00 00 ...d..qe..qe....
6571ded4: 1c c4 03 64 f8 02 00 64 10 df 71 65 ec de 71 65 ...d...d..qe..qe
6571dee4: 84 da 01 f8 5c fb 16 f8 00 4e 40 00 00 00 00 00 ....\....N@.....
6571def4: 00 4e 40 00 00 00 00 00 d3 00 00 00 ec 4e 40 00 .N@..........N@.
6571df04: d4 df 71 65 14 df 71 65 e0 db 01 f8 c0 d9 01 f8 ..qe..qe........
6571df14: a8 cb 03 64 e0 ba 03 64 01 00 01 00 00 00 00 00 ...d...d........
6571df24: 00 00 00 00 d4 4e 40 00 00 00 00 30 40 00 00 00 .....N@....0@...
6571df34: 13 00 00 60 98 df 71 65 48 df 71 65 f4 81 00 f8 ...`..qeH.qe....
6571df44: 8c 7a 00 f8 68 df 71 65 58 df 71 65 6c df 71 65 .z..h.qeX.qel.qe
6571df54: 60 df 71 65 0c 2b 00 f8 bc 2a 00 f8 84 df 71 65 `.qe.+...*....qe
6571df64: 70 df 71 65 e4 7d 04 f8 08 2b 00 f8 0d 00 00 00 p.qe.}...+......
6571df74: 0a 00 00 30 40 00 00 00 54 65 73 74 44 6d 61 53 ...0@...TestDmaS
6571df84: 69 6d 04 f8 a9 4b 40 00 b8 df 71 65 9c df 71 65 im...K@...qe..qe
6571df94: 2c be 00 f8 2c bd 00 f8 38 4c 40 0d 01 00 00 00 ,...,...8L@.....
6571dfa4: 00 00 00 00 84 2d 02 f8 d4 df 71 65 bc df 71 65 .....-....qe..qe
6571dfb4: b8 2d 02 f8 dc bd 00 f8 54 a4 00 f8 00 00 00 00 .-......T.......
6571dfc4: ac da 01 f8 10 00 00 60 d8 df 71 65 70 74 00 f8 .......`..qept..
6571dfd4: b8 da 01 f8 d4 4e 40 00 20 f7 16 f8 d0 4e 40 00 .....N@. ....N@.
6571dfe4: 00 00 00 00 00 00 00 00 ec 4e 40 00 40 00 00 00 .........N@.@...We can look for potential ROM addresses by scanning the log and +look up the corresponding function name in the symbol file generated +using the MAKSYM tool . The first +one is 0xF8170414 at offset 4 in the memory dump. +
+
+ -
+
Alternatively, we can use the printsym.pl perl +script, passing it the dump output. The following is part of the output:
+R:\base\e32\rombuild>perl -S printsym.pl ASSABETARM4D.symbol
+
ROM Symbols from ASSABETARM4D.symbol
Please enter data to be decoded
6571de54: 07 00 00 10 14 04 17 f8 00 00 00 00 d4 4e 40 00 .............N@.
= 10000007 ....
= f8170414 .... etext=. + 0x0
= 00000000 ....
= 00404ed4 .N@.
6571de64: e8 de 71 65 74 de 71 65 74 fb 16 f8 88 28 03 f8 ..qet.qet....(..
= 6571dee8 ..qe
= 6571de74 t.qe
= f816fb74 t... DDmaTestChannel::DoCreate(int, TDesC8 const *, TVersion const &
) + 0x24
= f8032888 .(.. Kern::Fault(char const *, int) + 0xc
6571de74: 0c d4 03 f8 64 35 03 f8 00 00 00 00 00 00 00 00 ....d5..........
= f803d40c .... RHeap::Alloc(int) + 0xf4
= f8033564 d5.. Kern::MutexSignal(DMutex &) + 0xc
= 00000000 ....
= 00000000 ....
[............ truncated ...............]
= f801da84 .... DLogicalDevice::ChannelCreate(DLogicalChannelBase *&, TChannelC
reateInfo &) + 0xd0
= f816fb5c \... DDmaTestChannel::DoCreate(int, TDesC8 const *, TVersion const &
) + 0xc
= 00404e00 .N@.
= 00000000 ....
6571def4: 00 4e 40 00 00 00 00 00 d3 00 00 00 ec 4e 40 00 .N@..........N@.
= 00404e00 .N@.
= 00000000 ....
= 000000d3 ....
= 00404eec .N@.
6571df04: d4 df 71 65 14 df 71 65 e0 db 01 f8 c0 d9 01 f8 ..qe..qe........
= 6571dfd4 ..qe
= 6571df14 ..qe
= f801dbe0 .... ExecHandler::ChannelCreate(TDesC8 const &, TChannelCreateInfo &
, int) + 0x134
= f801d9c0 .... DLogicalDevice::ChannelCreate(DLogicalChannelBase *&, TChannelC
reateInfo &) + 0xc
[.......................... truncated .........................]
= f8022db8 .-.. ExecHandler::DebugPrint(void *, int) + 0x34
= f800bddc .... A::UserDebugPrint(unsigned char const *, int, int) + 0xc
= f800a454 T... EpocSlowExecTable + 0xc
= 00000000 ....
6571dfc4: ac da 01 f8 10 00 00 60 d8 df 71 65 70 74 00 f8 .......`..qept..
= f801daac .... ExecHandler::ChannelCreate(TDesC8 const &, TChannelCreateInfo &
, int) + 0x0
= 60000010 ...`
= 6571dfd8 ..qe
= f8007470 pt.. __ArmVectorSwi + 0xd8
6571dfd4: b8 da 01 f8 d4 4e 40 00 20 f7 16 f8 d0 4e 40 00 .....N@. ....N@.
= f801dab8 .... ExecHandler::ChannelCreate(TDesC8 const &, TChannelCreateInfo &
, int) + 0xc
= 00404ed4 .N@.
= f816f720 ... etext=. + 0x560
= 00404ed0 .N@.
6571dfe4: 00 00 00 00 00 00 00 00 ec 4e 40 00 40 00 00 00 .........N@.@...
= 00000000 ....
= 00000000 ....
= 00404eec .N@.
= 00000040 @...
^C
R:\base\e32\rombuild>There are several false positives in this output (and even more +in the truncated parts). So some study of the source code is needed to discard +the noise and find the actual call stack. Here it is (innermost frame +first):
+-
+
-
+
Kern::Fault
+
+ -
+
DDmaTestChannel::DoCreate
+
+ -
+
ExecHandler::ChannelCreate
+
+ -
+
__ArmVectorSwi
+
+
Note that for the sake of the example, a call to Kern::Fault() was deliberately inserted into +DDmaTestChannel::DoCreate().
+All other function names are false positives and should be +ignored
+
+ -
+
Related tasks
+ +Walking through the Call Stack
-The heuristic method is quick but produces lots of false positives. -Another option is to manually reconstitute the call stack from the memory dump. -This is relatively easy for debug builds because GCC uses R11 as a frame -pointer (FP) and generates the same prologue/epilogue for every -function.
-For release builds, there is no generic solution. It is necessary -to check the generated assembler code as there is no standard prologue/epilogue -and R11 is not used as frame pointer.
-A typical prologue for a debug ARM function looks like this:
-mov ip, sp
stmfd sp!, {fp, ip, lr, pc}
sub fp, ip, #4 /* FP now points to base of stack frame */
sub sp, sp, #16 /* space for local variables */
noting that: SP = R13, FP = R11, IP -= R12, LR = R14, and PC = R15.
-This code creates the following stack frame:
-
Looking at the example session listed in when -tracing through the stack heuristically. in which the crash is due to a panic, the FP value is the -R11 value; this is 0x6571de70. This gives us the innermost stack -frame:
-6571de64: e8 de 71 65 <------------- pointer to previous stack frame
74 de 71 65
74 fb 16 f8 <------------- Saved return address
88 28 03 f8 <------------- FP points to this word
Looking up the saved return address, 0xf816fb74, in -the symbol file shows that the current function was called from -DDmaChannel::DoCreate().
-f816fb50 0198 DDmaTestChannel::DoCreate(int, TDesC8 const *, TVersion const &)
f816fce8 007c DDmaTestChannel::~DDmaTestChannel(void)
f816fd64 0294 DDmaTestChannel::Request(int, void *, void *)
Using the pointer to the previous stack frame saved into the -current frame, we can decode the next frame:
-6571ded4: 1c c4 03 64
f8 02 00 64
10 df 71 65 <------------- pointer to previous stack frame
ec de 71 65
6571dee4: 84 da 01 f8 <------------- saved return address
5c fb 16 f8 <------------- start of second stack frame
00 4e 40 00
00 00 00 00
Looking up the saved return address, 0xf801da84, in -the symbol file shows that DDmaTestChannel::DoCreate() was called -from DLogicalDevice::ChannelCreate().
-f801d9b4 00f8 DLogicalDevice::ChannelCreate(DLogicalChannelBase *&, TChannelCreateInfo &)
f801daac 01b8 ExecHandler::ChannelCreate(TDesC8 const &, TChannelCreateInfo &, int)
f801dc64 00e4 ExecHandler::ChannelRequest(DLogicalChannelBase *, int, void *, void *)
And here is the third stack frame:
-6571df04: d4 df 71 65 <------------- pointer to previous stack frame
14 df 71 65
e0 db 01 f8 <------------- saved return address
c0 d9 01 f8 <------------- start of third stack frame
So DLogicalDevice::ChannelCreate() was called from -ExecHandler::ChannelCreate().
-Note that this mechanical way of walking the stack is valid only -for debug functions. For release functions, it is necessary to study the code -generated by the compiler.
-For completness, this is a typical prologue for a debug THUMB -function:
-push { r7, lr }
sub sp, #28
add r7, sp, #12 /* R7 is THUMB frame pointer */
and this creates the following stack frame:
-
A call stack can mix ARM and THUMB frames. Odd return addresses are -used for THUMB code and even ones for ARM code.
- -Related tasks
- - - - + + +Walking through the Call Stack
+The heuristic method is quick but produces lots of false positives. +Another option is to manually reconstitute the call stack from the memory dump. +This is relatively easy for debug builds because GCC uses R11 as a frame +pointer (FP) and generates the same prologue/epilogue for every +function.
+For release builds, there is no generic solution. It is necessary +to check the generated assembler code as there is no standard prologue/epilogue +and R11 is not used as frame pointer.
+A typical prologue for a debug ARM function looks like this:
+mov ip, sp
stmfd sp!, {fp, ip, lr, pc}
sub fp, ip, #4 /* FP now points to base of stack frame */
sub sp, sp, #16 /* space for local variables */
noting that: SP = R13, FP = R11, IP += R12, LR = R14, and PC = R15.
+This code creates the following stack frame:
+
Looking at the example session listed in when +tracing through the stack heuristically. in which the crash is due to a panic, the FP value is the +R11 value; this is 0x6571de70. This gives us the innermost stack +frame:
+6571de64: e8 de 71 65 <------------- pointer to previous stack frame
74 de 71 65
74 fb 16 f8 <------------- Saved return address
88 28 03 f8 <------------- FP points to this word
Looking up the saved return address, 0xf816fb74, in +the symbol file shows that the current function was called from +DDmaChannel::DoCreate().
+f816fb50 0198 DDmaTestChannel::DoCreate(int, TDesC8 const *, TVersion const &)
f816fce8 007c DDmaTestChannel::~DDmaTestChannel(void)
f816fd64 0294 DDmaTestChannel::Request(int, void *, void *)
Using the pointer to the previous stack frame saved into the +current frame, we can decode the next frame:
+6571ded4: 1c c4 03 64
f8 02 00 64
10 df 71 65 <------------- pointer to previous stack frame
ec de 71 65
6571dee4: 84 da 01 f8 <------------- saved return address
5c fb 16 f8 <------------- start of second stack frame
00 4e 40 00
00 00 00 00
Looking up the saved return address, 0xf801da84, in +the symbol file shows that DDmaTestChannel::DoCreate() was called +from DLogicalDevice::ChannelCreate().
+f801d9b4 00f8 DLogicalDevice::ChannelCreate(DLogicalChannelBase *&, TChannelCreateInfo &)
f801daac 01b8 ExecHandler::ChannelCreate(TDesC8 const &, TChannelCreateInfo &, int)
f801dc64 00e4 ExecHandler::ChannelRequest(DLogicalChannelBase *, int, void *, void *)
And here is the third stack frame:
+6571df04: d4 df 71 65 <------------- pointer to previous stack frame
14 df 71 65
e0 db 01 f8 <------------- saved return address
c0 d9 01 f8 <------------- start of third stack frame
So DLogicalDevice::ChannelCreate() was called from +ExecHandler::ChannelCreate().
+Note that this mechanical way of walking the stack is valid only +for debug functions. For release functions, it is necessary to study the code +generated by the compiler.
+For completness, this is a typical prologue for a debug THUMB +function:
+push { r7, lr }
sub sp, #28
add r7, sp, #12 /* R7 is THUMB frame pointer */
and this creates the following stack frame:
+
A call stack can mix ARM and THUMB frames. Odd return addresses are +used for THUMB code and even ones for ARM code.
+ +Related tasks
+ + + + \ No newline at end of file diff -r bf0a333d965d -r a690706fd137 debuggercdi/com.nokia.carbide.cpp.debug.crashdebugger/html/DebuggingInformation/CrashDebuggerExaminingMemory.guide.html --- a/debuggercdi/com.nokia.carbide.cpp.debug.crashdebugger/html/DebuggingInformation/CrashDebuggerExaminingMemory.guide.html Thu Feb 18 15:22:38 2010 -0600 +++ b/debuggercdi/com.nokia.carbide.cpp.debug.crashdebugger/html/DebuggingInformation/CrashDebuggerExaminingMemory.guide.html Thu Feb 18 15:23:36 2010 -0600 @@ -1,34 +1,34 @@ - - -Examining Memory
-The m -command allows you to view a dump of memory.
-This command has two formats:
-m start end
-m start+length
-Using the first format you provide the start and end addresses that -you want to inspect; for example:
-m 81240000 8124003F
-Using the second form you provide the start address and the number of -bytes to dump (in hex); for example:
-m 81240000 +40
-Both of the above examples dump 64 bytes from address 0x81240000. The -output is a standard hex-dump:
-.m 81240000 +40
- 81240000: 00 00 FF EB 08 01 BF D7 00 04 7D B6 02 00 BF EF ..........}.....
81240010: 00 01 DF EE 0A 40 7F F7 00 80 BF FF 20 10 FF EA .....@...... ...
81240020: 00 82 FF 77 04 24 FD FF 40 01 FF 7F 00 01 FF FF ...w.$..@.......
81240030: 08 10 FF BF 08 00 BF DE 08 00 EF FB 00 00 FF DF ................
Examining Memory
+The m +command allows you to view a dump of memory.
+This command has two formats:
+m start end
+m start+length
+Using the first format you provide the start and end addresses that +you want to inspect; for example:
+m 81240000 8124003F
+Using the second form you provide the start address and the number of +bytes to dump (in hex); for example:
+m 81240000 +40
+Both of the above examples dump 64 bytes from address 0x81240000. The +output is a standard hex-dump:
+.m 81240000 +40
+ 81240000: 00 00 FF EB 08 01 BF D7 00 04 7D B6 02 00 BF EF ..........}.....
81240010: 00 01 DF EE 0A 40 7F F7 00 80 BF FF 20 10 FF EA .....@...... ...
81240020: 00 82 FF 77 04 24 FD FF 40 01 FF 7F 00 01 FF FF ...w.$..@.......
81240030: 08 10 FF BF 08 00 BF DE 08 00 EF FB 00 00 FF DF ................
Dumping the Contents of Classes
-You can use the -m command to -inspect the contents of structures and class instances, but you need to be -aware of a few things about the memory layout:
--
-
-
-
Symbian OS is little-endian, which means that all values are -stored so that the least significant bytes are stored at the lower addresses in -memory (or “backwards” as commonly perceived).
-For example, the value 0x1234ABCD would be shown in the memory -dump as:
-CD AB 34 12
-
- -
-
The compiler may add padding between variables either to speed -up access or to avoid alignment restrictions; for example, words cannot be on -odd addresses.
-As an example, the following struct:
-struct SExample
-
- {
- TUint8 iByte;
- TInt iInteger;
- };would be laid out in memory as:
-+0(1) iByte
-
- +1(3) padding
- +4(4) iIntegerThe padding and alignment is compiler-dependent. Generally, -fields must be aligned on a boundary equal to their size; for example, a TUint32 is 4 bytes wide so it must lie on a 4-byte -boundary, i.e. the least significant two bits of the address must be -zero.
-When using GCC, classes which derive from CBase will have a virtual table pointer as the first word -in the class data and classes which derive from DBase will -have a virtual table pointer as the second word in the class data.
-When using an EABI-compliant compiler, the virtual table -pointer is always the first word of the class.
-
-
Dumping the Contents of Classes
+You can use the +m command to +inspect the contents of structures and class instances, but you need to be +aware of a few things about the memory layout:
+-
+
-
+
Symbian OS is little-endian, which means that all values are +stored so that the least significant bytes are stored at the lower addresses in +memory (or “backwards” as commonly perceived).
+For example, the value 0x1234ABCD would be shown in the memory +dump as:
+CD AB 34 12
+
+ -
+
The compiler may add padding between variables either to speed +up access or to avoid alignment restrictions; for example, words cannot be on +odd addresses.
+As an example, the following struct:
+struct SExample
+
+ {
+ TUint8 iByte;
+ TInt iInteger;
+ };would be laid out in memory as:
++0(1) iByte
+
+ +1(3) padding
+ +4(4) iIntegerThe padding and alignment is compiler-dependent. Generally, +fields must be aligned on a boundary equal to their size; for example, a TUint32 is 4 bytes wide so it must lie on a 4-byte +boundary, i.e. the least significant two bits of the address must be +zero.
+When using GCC, classes which derive from CBase will have a virtual table pointer as the first word +in the class data and classes which derive from DBase will +have a virtual table pointer as the second word in the class data.
+When using an EABI-compliant compiler, the virtual table +pointer is always the first word of the class.
+
+
Finding the Type of Fault
-The type of fault is the first piece of information that you need. -There are two possibilities:
- -To start, use the -f command. You -will see something like this:
-Fault Category: Exception Fault Reason: 10000000
- ExcId 00000001 CodeAddr f800415c DataAddr 00000000 Extra 00000005
Exc 1 Cpsr=60000013 FAR=00000000 FSR=00000005
-R0=64007328 R1=00000000 R2=00000000 R3=00000001
-R4=64007328 R5=640074c0 R6=00000000 R7=f8047ba4
-R8=64006f80 R9=64006fec R10=00000013 R11=64006ec4
-R12=00000001 R13=000029b4 R14=0000016c R15=f800415c
R13Svc=64006ea8 R14Svc=f8002b2c SpsrSvc=600000ff
The Fault Category field shows the type of fault, in -this case an exception.
- -Finding the Type of Fault
+The type of fault is the first piece of information that you need. +There are two possibilities:
+ +To start, use the +f command. You +will see something like this:
+Fault Category: Exception Fault Reason: 10000000
+ ExcId 00000001 CodeAddr f800415c DataAddr 00000000 Extra 00000005
Exc 1 Cpsr=60000013 FAR=00000000 FSR=00000005
+R0=64007328 R1=00000000 R2=00000000 R3=00000001
+R4=64007328 R5=640074c0 R6=00000000 R7=f8047ba4
+R8=64006f80 R9=64006fec R10=00000013 R11=64006ec4
+R12=00000001 R13=000029b4 R14=0000016c R15=f800415c
R13Svc=64006ea8 R14Svc=f8002b2c SpsrSvc=600000ff
The Fault Category field shows the type of fault, in +this case an exception.
+ +Unhandled Exceptions
-If the Fault Category is Exception, then -the fault is caused by an unhandled processor exception. You can get further -information on the type of exception by looking at the first three lines of the -generated output:
-Fault Category: Exception Fault Reason: 10000000
- ExcId 00000001 CodeAddr f800415c DataAddr 00000000 Extra 00000005
Exc 1 Cpsr=60000013 FAR=00000000 FSR=00000005
The CodeAddr and DataAddr fields show -the address of the instruction that caused the exception and, depending on the -type of exception and instruction, the address of the data the instruction was -trying to access. You can use the CodeAddr value to find the -function which was being executed by using the MAKSYM tool.
-The number after ExcId is the type of exception, in -hexadecimal, and is one of the -ARM exception types. The meaning of the numbers depends on the type of -processor.
--
-
-
-
If the exception is a prefetch abort, then the code address is -invalid.
-
- -
-
A data abort means that the code address is invalid.
-
-
The number after FAR is the fault address register; -this is the address that caused the fault.
-The number after FSR is the -fault status register value and shows why the MMU raised an exception.
-The number after CPSR is the value of the CPU's CPSR register when -the exception occurred. The 5 least-significant bits of the CPSR register -indicate the ARM processor mode.
-Unhandled Exceptions
+If the Fault Category is Exception, then +the fault is caused by an unhandled processor exception. You can get further +information on the type of exception by looking at the first three lines of the +generated output:
+Fault Category: Exception Fault Reason: 10000000
+ ExcId 00000001 CodeAddr f800415c DataAddr 00000000 Extra 00000005
Exc 1 Cpsr=60000013 FAR=00000000 FSR=00000005
The CodeAddr and DataAddr fields show +the address of the instruction that caused the exception and, depending on the +type of exception and instruction, the address of the data the instruction was +trying to access. You can use the CodeAddr value to find the +function which was being executed by using the MAKSYM tool.
+The number after ExcId is the type of exception, in +hexadecimal, and is one of the +ARM exception types. The meaning of the numbers depends on the type of +processor.
+-
+
-
+
If the exception is a prefetch abort, then the code address is +invalid.
+
+ -
+
A data abort means that the code address is invalid.
+
+
The number after FAR is the fault address register; +this is the address that caused the fault.
+The number after FSR is the +fault status register value and shows why the MMU raised an exception.
+The number after CPSR is the value of the CPU's CPSR register when +the exception occurred. The 5 least-significant bits of the CPSR register +indicate the ARM processor mode.
+Panics
-If the Fault Category is not Exception, -then the fault is due to a panic. In this case the only other valid field is -the Fault reason; the values of all other fields are -meaningless.
-The panic number is the low 16-bits of the fault reason, shown in -hexadecimal.
-For example, a KERN 27 panic would generate:
-Fault Category: KERN Fault Reason: 0000001b
- ExcId ffffee5e CodeAddr ffff99a9 DataAddr bfff3e54 Extra fffec4cd
If the panic is KERN 4, then a thread or process marked as -protected has panicked. For other panics, kernel side code has panicked; this -code is either in the kernel itself or in a device driver.
-See Extracting information about the kernel to find out which process and thread were -running at the time of the panic.
- -Panics
+If the Fault Category is not Exception, +then the fault is due to a panic. In this case the only other valid field is +the Fault reason; the values of all other fields are +meaningless.
+The panic number is the low 16-bits of the fault reason, shown in +hexadecimal.
+For example, a KERN 27 panic would generate:
+Fault Category: KERN Fault Reason: 0000001b
+ ExcId ffffee5e CodeAddr ffff99a9 DataAddr bfff3e54 Extra fffec4cd
If the panic is KERN 4, then a thread or process marked as +protected has panicked. For other panics, kernel side code has panicked; this +code is either in the kernel itself or in a device driver.
+See Extracting information about the kernel to find out which process and thread were +running at the time of the panic.
+ +Extracting Information About the Kernel
-To find more information about the kernel, use the -i command. This -will give you detailed information on the current process, the current thread, -the current user process, the current user thread, and the state of the -kernel. We use the example shown below to illustrate how information can be extracted about the:
--
-
- - - -
- - - -
- - - -
- Current data section process -
The output shown below is a typical result of using the i command.
-SCHEDULER @64000348: CurrentThread 640396b0
- RescheduleNeeded=00 DfcPending=00 KernCSLocked=00000001
DFCS: next 64000458 prev 64000458
ProcessHandler=f8014904, AddressSpace=64038d5c
SYSLOCK: HoldingThread 00000000 iWaiting 00000000
Extras 0: 64038d5c 1: 64038d5c 2: 64038d5c 3: 00000000
Extras 4: 00000000 5: 00000000 6: 00000000 7: 00000000
Extras 8: 00000000 9: 00000000 A: 00000000 B: 00000000
Extras C: 00000000 D: 00000000 E: 00000000 F: 00000000
TheCurrentThread=64039408
THREAD at 64039408 VPTR=f803423c AccessCount=3 Owner=64038d5c
Full name test2.exe::Main
Thread MState READY
Default priority 16 WaitLink Priority 16
ExitInfo 2,100,USER
Flags 00000004, Handles 640330bc
Supervisor stack base 6571f000 size 1000
User stack base 00402000 size 2000
Id=26, Alctr=00600000, Created alctr=00600000, Frame=00000000
Trap handler=00000000, ActiveScheduler=00000000, Exception handler=00000000
TempObj=00000000 TempAlloc=00000000 IpcCount=00000000
NThread @ 640396b0 Pri 16 NState READY
Next=640396b0 Prev=640396b0 Att=03 iUserContextType=0b
HeldFM=00000000 WaitFM=00000000 AddrSp=64038d5c
Time=17 Timeslice=20 ReqCount=0
SuspendCount=0 CsCount=1 CsFunction=fffffffe
SavedSP=6571ff34 ExtraContext=00000000 ExtraContextSize=0000
DACR 63990000
R13_USR 6571ff88 R14_USR f8025bc0 SPSR_SVC 10000004
R4 f8033794 R5 64039408 R6 640396b0 R7 f8028518
R8 640396b0 R9 640396b0 R10 00000000 R11 f80284d8
PC 00000000
TheCurrentProcess=64038d5c
PROCESS at 64038d5c VPTR=f80342a4 AccessCount=6 Owner=00000000
Full name test2.exe
ExitInfo 3,0,
Flags a0000000, Handles 6403860c, Attributes 60010000
DataBssChunk 64039234, CodeSeg 6403919c
DllLock 64039044, Process Lock 64038eec SID 00000000
TempCodeSeg 00000000 CodeSeg 6403919c Capability 00000000 0003ffff
CodeSegs: Count=0
NumChunks=2
0: Chunk 64039234, run 00400000, access count 1
1: Chunk 6403613c, run 00600000, access count 1
Process shared IO buffers cookie 0000031d
Process has no shared IO buffers
Domain -1, DACR 55555507
TheCurrentAddressSpace=64038d5c
TheCurrentVMProcess=64038d5c
PROCESS at 64038d5c VPTR=f80342a4 AccessCount=6 Owner=00000000
Full name test2.exe
ExitInfo 3,0,
Flags a0000000, Handles 6403860c, Attributes 60010000
DataBssChunk 64039234, CodeSeg 6403919c
DllLock 64039044, Process Lock 64038eec SID 00000000
TempCodeSeg 00000000 CodeSeg 6403919c Capability 00000000 0003ffff
CodeSegs: Count=0
NumChunks=2
0: Chunk 64039234, run 00400000, access count 1
1: Chunk 6403613c, run 00600000, access count 1
Process shared IO buffers cookie 0000031d
Process has no shared IO buffers
Domain -1, DACR 55555507
TheCurrentDataSectionProcess=64038d5c
TheCompleteDataSectionProcess=64038d5c
PROCESS at 64038d5c VPTR=f80342a4 AccessCount=6 Owner=00000000
Full name test2.exe
ExitInfo 3,0,
Flags a0000000, Handles 6403860c, Attributes 60010000
DataBssChunk 64039234, CodeSeg 6403919c
DllLock 64039044, Process Lock 64038eec SID 00000000
TempCodeSeg 00000000 CodeSeg 6403919c Capability 00000000 0003ffff
CodeSegs: Count=0
NumChunks=2
0: Chunk 64039234, run 00400000, access count 1
1: Chunk 6403613c, run 00600000, access count 1
Process shared IO buffers cookie 0000031d
Process has no shared IO buffers
Domain -1, DACR 55555507
Extracting Information About the Kernel
+To find more information about the kernel, use the +i command. This +will give you detailed information on the current process, the current thread, +the current user process, the current user thread, and the state of the +kernel. We use the example shown below to illustrate how information can be extracted about the:
+-
+
- + + +
- + + +
- + + +
- Current data section process +
The output shown below is a typical result of using the i command.
+SCHEDULER @64000348: CurrentThread 640396b0
+ RescheduleNeeded=00 DfcPending=00 KernCSLocked=00000001
DFCS: next 64000458 prev 64000458
ProcessHandler=f8014904, AddressSpace=64038d5c
SYSLOCK: HoldingThread 00000000 iWaiting 00000000
Extras 0: 64038d5c 1: 64038d5c 2: 64038d5c 3: 00000000
Extras 4: 00000000 5: 00000000 6: 00000000 7: 00000000
Extras 8: 00000000 9: 00000000 A: 00000000 B: 00000000
Extras C: 00000000 D: 00000000 E: 00000000 F: 00000000
TheCurrentThread=64039408
THREAD at 64039408 VPTR=f803423c AccessCount=3 Owner=64038d5c
Full name test2.exe::Main
Thread MState READY
Default priority 16 WaitLink Priority 16
ExitInfo 2,100,USER
Flags 00000004, Handles 640330bc
Supervisor stack base 6571f000 size 1000
User stack base 00402000 size 2000
Id=26, Alctr=00600000, Created alctr=00600000, Frame=00000000
Trap handler=00000000, ActiveScheduler=00000000, Exception handler=00000000
TempObj=00000000 TempAlloc=00000000 IpcCount=00000000
NThread @ 640396b0 Pri 16 NState READY
Next=640396b0 Prev=640396b0 Att=03 iUserContextType=0b
HeldFM=00000000 WaitFM=00000000 AddrSp=64038d5c
Time=17 Timeslice=20 ReqCount=0
SuspendCount=0 CsCount=1 CsFunction=fffffffe
SavedSP=6571ff34 ExtraContext=00000000 ExtraContextSize=0000
DACR 63990000
R13_USR 6571ff88 R14_USR f8025bc0 SPSR_SVC 10000004
R4 f8033794 R5 64039408 R6 640396b0 R7 f8028518
R8 640396b0 R9 640396b0 R10 00000000 R11 f80284d8
PC 00000000
TheCurrentProcess=64038d5c
PROCESS at 64038d5c VPTR=f80342a4 AccessCount=6 Owner=00000000
Full name test2.exe
ExitInfo 3,0,
Flags a0000000, Handles 6403860c, Attributes 60010000
DataBssChunk 64039234, CodeSeg 6403919c
DllLock 64039044, Process Lock 64038eec SID 00000000
TempCodeSeg 00000000 CodeSeg 6403919c Capability 00000000 0003ffff
CodeSegs: Count=0
NumChunks=2
0: Chunk 64039234, run 00400000, access count 1
1: Chunk 6403613c, run 00600000, access count 1
Process shared IO buffers cookie 0000031d
Process has no shared IO buffers
Domain -1, DACR 55555507
TheCurrentAddressSpace=64038d5c
TheCurrentVMProcess=64038d5c
PROCESS at 64038d5c VPTR=f80342a4 AccessCount=6 Owner=00000000
Full name test2.exe
ExitInfo 3,0,
Flags a0000000, Handles 6403860c, Attributes 60010000
DataBssChunk 64039234, CodeSeg 6403919c
DllLock 64039044, Process Lock 64038eec SID 00000000
TempCodeSeg 00000000 CodeSeg 6403919c Capability 00000000 0003ffff
CodeSegs: Count=0
NumChunks=2
0: Chunk 64039234, run 00400000, access count 1
1: Chunk 6403613c, run 00600000, access count 1
Process shared IO buffers cookie 0000031d
Process has no shared IO buffers
Domain -1, DACR 55555507
TheCurrentDataSectionProcess=64038d5c
TheCompleteDataSectionProcess=64038d5c
PROCESS at 64038d5c VPTR=f80342a4 AccessCount=6 Owner=00000000
Full name test2.exe
ExitInfo 3,0,
Flags a0000000, Handles 6403860c, Attributes 60010000
DataBssChunk 64039234, CodeSeg 6403919c
DllLock 64039044, Process Lock 64038eec SID 00000000
TempCodeSeg 00000000 CodeSeg 6403919c Capability 00000000 0003ffff
CodeSegs: Count=0
NumChunks=2
0: Chunk 64039234, run 00400000, access count 1
1: Chunk 6403613c, run 00600000, access count 1
Process shared IO buffers cookie 0000031d
Process has no shared IO buffers
Domain -1, DACR 55555507
Scheduler State
-The first three lines and the fifth line of the output show the -state of the kernel scheduler. This information is mainly of interest to kernel -engineers, although the state of the kernel and the system locks can be useful -when debugging device driver crashes.
-SCHEDULER @64000348: CurrentThread 640396b0
- RescheduleNeeded=00 DfcPending=00 KernCSLocked=00000001
DFCS: next 64000458 prev 64000458
...
SYSLOCK: HoldingThread 00000000 iWaiting 00000000
The values are interpreted as follows:
|
-
Related tasks
--
-
- Extracting Kernel Information -
- Current Thread State -
- Current Process State -
- Current Data Section Process -
Scheduler State
+The first three lines and the fifth line of the output show the +state of the kernel scheduler. This information is mainly of interest to kernel +engineers, although the state of the kernel and the system locks can be useful +when debugging device driver crashes.
+SCHEDULER @64000348: CurrentThread 640396b0
+ RescheduleNeeded=00 DfcPending=00 KernCSLocked=00000001
DFCS: next 64000458 prev 64000458
...
SYSLOCK: HoldingThread 00000000 iWaiting 00000000
The values are interpreted as follows:
|
+
Related tasks
+-
+
- Extracting Kernel Information +
- Current Thread State +
- Current Process State +
- Current Data Section Process +
Current Thread State
-The current thread is the thread that was executing when the fault -occurred. The 23 lines starting at line 10 of the output gives information -relating to the current thread:
-TheCurrentThread=64039408
- THREAD at 64039408 VPTR=f803423c AccessCount=3 Owner=64038d5c
Full name test2.exe::Main
Thread MState READY
Default priority 16 WaitLink Priority 16
ExitInfo 2,100,USER
Flags 00000004, Handles 640330bc
Supervisor stack base 6571f000 size 1000
User stack base 00402000 size 2000
Id=26, Alctr=00600000, Created alctr=00600000, Frame=00000000
Trap handler=00000000, ActiveScheduler=00000000, Exception handler=00000000
TempObj=00000000 TempAlloc=00000000 IpcCount=00000000
NThread @ 640396b0 Pri 16 NState READY
Next=640396b0 Prev=640396b0 Att=03 iUserContextType=0b
HeldFM=00000000 WaitFM=00000000 AddrSp=64038d5c
Time=17 Timeslice=20 ReqCount=0
SuspendCount=0 CsCount=1 CsFunction=fffffffe
SavedSP=6571ff34 ExtraContext=00000000 ExtraContextSize=0000
DACR 63990000
R13_USR 6571ff88 R14_USR f8025bc0 SPSR_SVC 10000004
-R4 f8033794 R5 64039408 R6 640396b0 R7 f8028518
-R8 640396b0 R9 640396b0 R10 00000000 R11 f80284d8
-PC 00000000
-
-
- - - -
- - - -
- - - -
- - - -
- - - -
- - - -
- - - -
-
-
Trap handler, active scheduler and user-side exception handler
-
- - - - -
- - - -
- - - -
- - - -
THREAD at 64039408 VPTR=f803423c AccessCount=3 Owner=64038d5c
-The THread at field contains a pointer to the -DThread object representing the thread.
-The AccessCount field contains the reference count -on the thread object.
-The owner field contains a pointer to the object -that owns this DThread object.
- -Full name test2.exe::Main
-The thread name is the part after the colons. The part before the -colons is the process name. This means that the thread is called -Main inside the process test2.exe.
- -Thread MState READY
Default priority 16 WaitLink Priority 16
ExitInfo 2,100,USER
The information that characterises the thread exit is described -by ExitInfo; this is shown as exit type, exit reason and exit -category. In this example:
--
-
-
-
the thread has panicked, as indicated by: exit type -2; See also TExitType.
-
- -
-
the panic category was: USER
-
- -
-
the panic number was:100
-
- -
-
the thread was running or it was in a ready-to-run state: -MState READY
-
-
The priority shown is for the underlying thread, see also -Process and thread priorities.
- -Flags 00000004, Handles 640330bc
-The Flags field contains information about the state -of the thread. The possible values in this field are defined by the -KThread... constants in u32std.h. While the symbols -are internal to Symbian OS, the following table summarises the values and their -meaning.
-
|
Flags 00000004, Handles 640330bc
-The Handles field contains the address of a -DObjectIx object that contains the handles owned by the -thread.
- -Supervisor stack base 6571f000 size 1000
User stack base 00402000 size 2000
These fields give the base address and size, in bytes, of the -kernel and user stacks respectively.
- -Id=26, Alctr=00600000, Created alctr=00600000, Frame=00000000
-The Id field contains the thread id.
-The Alctr field contains a pointer to the current RAllocator instance used for heap allocation.
-The Created alctr field contains a pointer to the -original RAllocator instance used for heap allocation. -This may be different from the current instance if User::SwitchAllocator() has been called.
-The Frame field contains a pointer to the current -trap frame, an instance of the TTrap class, on the cleanup -stack.
- -Trap handler=00000000, ActiveScheduler=00000000, Exception handler=00000000
-The Trap handler field contains a pointer to the -current trap handler, an instance of TTrapHandler, for the -cleanup stack.
-The ActiveScheduler field contains a pointer to the -current active scheduler.
-The Exception handler field contains a pointer to -the current user-side exception handler.
- -TempObj=00000000 TempAlloc=00000000 IpcCount=00000000
-The Tempobj field contains a pointer to an instance -of a DObject derived class that must be closed when the -thread terminates.
-The TempAlloc field contains a pointer to a kernel -heap cell that must be freed when the thread terminates. Both this and -Tempobj are used to avoid leaks if the thread terminates -unexpectedly.
-The IpcCount field contains the number of messages -currently queued to this thread.
- -NThread @ 640396b0 Pri 16 NState READY
Next=640396b0 Prev=640396b0 Att=03 iUserContextType=0b
The NThread field contains a pointer to the -underlying nanokernel thread object, an instance of the -NThread class.
-The Pri field contains the current priority of the -underlying nanokernel thread.
-The NState field shows the current state of the -underlying nanokernel thread. Note that this state is often referred to as the -N-state, as compared to the to M-state, the state of a Symbian OS thread. See -the Thread state summary.
-The Next field points to the next nanokernel thread -object.
-The Prev field points to the previous nanokernel -thread object.
-The Att field contains the nanokernel thread -attributes, which is an 8-bit mask that controls how the thread is scheduled in -certain cases. Two attributes are defined:
|
HeldFM=00000000 WaitFM=00000000 AddrSp=64038d5c
-The HeldFM field contains a pointer to the fast -mutex held by this thread; this is NULL if no fast mutext was held.
-The WaitFM field contains a pointer to the fast -mutex that this thread was waiting on; this is NULL if this thread was not -waiting on a fast mutex.
-The AddrSp field is the address space identifier -used by the scheduler to determine whether an address space change is required -when scheduling in a new thread.
- -Time=17 Timeslice=20 ReqCount=0
-The Time field contains the number of nanokernel -ticks, usually in milliseconds, to go before the thread is preempted.
-The Timeslice field contains the maximum number of -ticks for which the thread can run before being preempted.
-The ReqCount contains the request semaphore counter. -If the value is negative, then the thread is blocked waiting for a request to -complete; if it is positive, then one or more requests have completed.
- -SuspendCount=0 CsCount=1 CsFunction=fffffffe
SavedSP=6571ff34 ExtraContext=00000000 ExtraContextSize=0000
DACR 63990000
R13_USR 6571ff88 R14_USR f8025bc0 SPSR_SVC 10000004
R4 f8033794 R5 64039408 R6 640396b0 R7 f8028518
R8 640396b0 R9 640396b0 R10 00000000 R11 f80284d8
PC 00000000
The SuspendCount field contains the number of times -that the thread has been suspended.
-The CsCount field critical section counter. When -this value is greater than zero, then the thread is in a critical section and -cannot be suspended or killed.
-The remaining content is a list of register values. Note -that they are not the register values when the thread panicked. They are -the values in the registers the last time that this thread was -pre-empted.
-Related tasks
--
-
- Extracting Kernel Information -
- Scheduler State -
- Current Process State -
- Current Data Section Process -
Current Thread State
+The current thread is the thread that was executing when the fault +occurred. The 23 lines starting at line 10 of the output gives information +relating to the current thread:
+TheCurrentThread=64039408
+ THREAD at 64039408 VPTR=f803423c AccessCount=3 Owner=64038d5c
Full name test2.exe::Main
Thread MState READY
Default priority 16 WaitLink Priority 16
ExitInfo 2,100,USER
Flags 00000004, Handles 640330bc
Supervisor stack base 6571f000 size 1000
User stack base 00402000 size 2000
Id=26, Alctr=00600000, Created alctr=00600000, Frame=00000000
Trap handler=00000000, ActiveScheduler=00000000, Exception handler=00000000
TempObj=00000000 TempAlloc=00000000 IpcCount=00000000
NThread @ 640396b0 Pri 16 NState READY
Next=640396b0 Prev=640396b0 Att=03 iUserContextType=0b
HeldFM=00000000 WaitFM=00000000 AddrSp=64038d5c
Time=17 Timeslice=20 ReqCount=0
SuspendCount=0 CsCount=1 CsFunction=fffffffe
SavedSP=6571ff34 ExtraContext=00000000 ExtraContextSize=0000
DACR 63990000
R13_USR 6571ff88 R14_USR f8025bc0 SPSR_SVC 10000004
+R4 f8033794 R5 64039408 R6 640396b0 R7 f8028518
+R8 640396b0 R9 640396b0 R10 00000000 R11 f80284d8
+PC 00000000
-
+
- + + +
- + + +
- + + +
- + + +
- + + +
- + + +
- + + +
-
+
Trap handler, active scheduler and user-side exception handler
+
+ - + + +
- + + +
- + + +
- + + +
THREAD at 64039408 VPTR=f803423c AccessCount=3 Owner=64038d5c
+The THread at field contains a pointer to the +DThread object representing the thread.
+The AccessCount field contains the reference count +on the thread object.
+The owner field contains a pointer to the object +that owns this DThread object.
+ +Full name test2.exe::Main
+The thread name is the part after the colons. The part before the +colons is the process name. This means that the thread is called +Main inside the process test2.exe.
+ +Thread MState READY
Default priority 16 WaitLink Priority 16
ExitInfo 2,100,USER
The information that characterises the thread exit is described +by ExitInfo; this is shown as exit type, exit reason and exit +category. In this example:
+-
+
-
+
the thread has panicked, as indicated by: exit type +2; See also TExitType.
+
+ -
+
the panic category was: USER
+
+ -
+
the panic number was:100
+
+ -
+
the thread was running or it was in a ready-to-run state: +MState READY
+
+
The priority shown is for the underlying thread, see also +Process and thread priorities.
+ +Flags 00000004, Handles 640330bc
+The Flags field contains information about the state +of the thread. The possible values in this field are defined by the +KThread... constants in u32std.h. While the symbols +are internal to Symbian OS, the following table summarises the values and their +meaning.
+
|
Flags 00000004, Handles 640330bc
+The Handles field contains the address of a +DObjectIx object that contains the handles owned by the +thread.
+ +Supervisor stack base 6571f000 size 1000
User stack base 00402000 size 2000
These fields give the base address and size, in bytes, of the +kernel and user stacks respectively.
+ +Id=26, Alctr=00600000, Created alctr=00600000, Frame=00000000
+The Id field contains the thread id.
+The Alctr field contains a pointer to the current RAllocator instance used for heap allocation.
+The Created alctr field contains a pointer to the +original RAllocator instance used for heap allocation. +This may be different from the current instance if User::SwitchAllocator() has been called.
+The Frame field contains a pointer to the current +trap frame, an instance of the TTrap class, on the cleanup +stack.
+ +Trap handler=00000000, ActiveScheduler=00000000, Exception handler=00000000
+The Trap handler field contains a pointer to the +current trap handler, an instance of TTrapHandler, for the +cleanup stack.
+The ActiveScheduler field contains a pointer to the +current active scheduler.
+The Exception handler field contains a pointer to +the current user-side exception handler.
+ +TempObj=00000000 TempAlloc=00000000 IpcCount=00000000
+The Tempobj field contains a pointer to an instance +of a DObject derived class that must be closed when the +thread terminates.
+The TempAlloc field contains a pointer to a kernel +heap cell that must be freed when the thread terminates. Both this and +Tempobj are used to avoid leaks if the thread terminates +unexpectedly.
+The IpcCount field contains the number of messages +currently queued to this thread.
+ +NThread @ 640396b0 Pri 16 NState READY
Next=640396b0 Prev=640396b0 Att=03 iUserContextType=0b
The NThread field contains a pointer to the +underlying nanokernel thread object, an instance of the +NThread class.
+The Pri field contains the current priority of the +underlying nanokernel thread.
+The NState field shows the current state of the +underlying nanokernel thread. Note that this state is often referred to as the +N-state, as compared to the to M-state, the state of a Symbian OS thread. See +the Thread state summary.
+The Next field points to the next nanokernel thread +object.
+The Prev field points to the previous nanokernel +thread object.
+The Att field contains the nanokernel thread +attributes, which is an 8-bit mask that controls how the thread is scheduled in +certain cases. Two attributes are defined:
|
HeldFM=00000000 WaitFM=00000000 AddrSp=64038d5c
+The HeldFM field contains a pointer to the fast +mutex held by this thread; this is NULL if no fast mutext was held.
+The WaitFM field contains a pointer to the fast +mutex that this thread was waiting on; this is NULL if this thread was not +waiting on a fast mutex.
+The AddrSp field is the address space identifier +used by the scheduler to determine whether an address space change is required +when scheduling in a new thread.
+ +Time=17 Timeslice=20 ReqCount=0
+The Time field contains the number of nanokernel +ticks, usually in milliseconds, to go before the thread is preempted.
+The Timeslice field contains the maximum number of +ticks for which the thread can run before being preempted.
+The ReqCount contains the request semaphore counter. +If the value is negative, then the thread is blocked waiting for a request to +complete; if it is positive, then one or more requests have completed.
+ +SuspendCount=0 CsCount=1 CsFunction=fffffffe
SavedSP=6571ff34 ExtraContext=00000000 ExtraContextSize=0000
DACR 63990000
R13_USR 6571ff88 R14_USR f8025bc0 SPSR_SVC 10000004
R4 f8033794 R5 64039408 R6 640396b0 R7 f8028518
R8 640396b0 R9 640396b0 R10 00000000 R11 f80284d8
PC 00000000
The SuspendCount field contains the number of times +that the thread has been suspended.
+The CsCount field critical section counter. When +this value is greater than zero, then the thread is in a critical section and +cannot be suspended or killed.
+The remaining content is a list of register values. Note +that they are not the register values when the thread panicked. They are +the values in the registers the last time that this thread was +pre-empted.
+Related tasks
+-
+
- Extracting Kernel Information +
- Scheduler State +
- Current Process State +
- Current Data Section Process +
Current Process State
-The current process is the process in whose address space the -current thread was executing when the fault occurred. The 15 lines starting at -line 33 of the output gives information relating to the current process. This -has some similarities with the current thread information:
-TheCurrentProcess=64038d5c
- PROCESS at 64038d5c VPTR=f80342a4 AccessCount=6 Owner=00000000
Full name test2.exe
ExitInfo 3,0,
Flags a0000000, Handles 6403860c, Attributes 60010000
DataBssChunk 64039234, CodeSeg 6403919c
DllLock 64039044, Process Lock 64038eec SID 00000000
TempCodeSeg 00000000 CodeSeg 6403919c Capability 00000000 0003ffff
CodeSegs: Count=0
NumChunks=2
0: Chunk 64039234, run 00400000, access count 1
1: Chunk 6403613c, run 00600000, access count 1
Process shared IO buffers cookie 0000031d
Process has no shared IO buffers
Domain -1, DACR 55555507
The information includes:
--
-
- - - -
- - - -
- - - -
- - - -
- - - -
- - - -
- - - -
- - - -
- - - -
- - - -
- - - -
- - - -
- - - -
PROCESS at 64038d5c VPTR=f80342a4 AccessCount=6 Owner=00000000
-The Process at field contains a pointer to the -DProcess object representing the process.
-The AccessCount field contains the reference count -on the process object.
-The owner field contains a pointer to the object -that owns this DProcess object.
-Full name test2.exe
-The Full name field gives the name of the process. -In this example, the name of the process is test2.exe.
-See the thread name.
-ExitInfo 3,0,
-The ExitInfo field contains the information that -characterises the process exit. In this example, the value is 3, meaning that -this process has not exited. See also TExitType.
-Flags a0000000, Handles 6403860c, Attributes 60010000
-The Flags field contains information about the state -of the process. The possible values in this field are defined by the -KProcess... constants in u32std.h. While the symbols -are internal to Symbian OS, the following table summarises the values and their -meaning.
-
|
Flags a0000000, Handles 6403860c, Attributes 60010000
-The Handles field contains the address of a -DObjectIx object that contains the handles owned by the -process.
-Flags a0000000, Handles 6403860c, Attributes 60010000
-The Attributes field contains the attributes of the -process. Some are generic, as defined by -DProcess::TProcessAttributes, but others depend on the -memory model.
-Information about memory
- -DataBssChunk 64039234, CodeSeg 6403919c
-The DataBssChunk field contains a pointer to the -DChunk object representing the chunk that contains the process -data and .bss memory. Be aware that this is not the same as the -heap - heaps are allocated to threads, and chunk information is found in the -DThread object.
-The CodeSeg field contains a pointer to the -DCodeSeg object that represents the code segment.
-DllLock 64039044, Process Lock 64038eec SID 00000000
-The SID field contains the secure id of the -process.
-TempCodeSeg 00000000 CodeSeg 6403919c Capability 00000000 0003ffff
-The second four bytes of the Capability field contains the set of -bits that define the capability for this process. This defines what the process -can and cannot do.
-CodeSegs: Count=0
-The CodeSegs: Count field contains the number of -code segments that have been dynamically loaded into the process. This will be -zero if the process is XIP.
-NumChunks=2
0: Chunk 64039234, run 00400000, access count 1
1: Chunk 6403613c, run 00600000, access count 1
The NumChunks field contains the number of chunks owned by the -process.
-Successive lines contain information about each chunk:
--
-
-
-
the Chunk field contains the address of a kernel -DChunk object.
-
- -
-
the run field contains the virtual address at -which the chunk resides when this is the current process.
-
- -
-
the access count field contains the reference -count of the object.
-
-
Process shared IO buffers cookie 0000031d
Process has no shared IO buffers
This is information about shared IO buffers. The cookie is only -really of interest to base engineers.
-Domain -1, DACR 55555507
-This is ARM MMU-specific protection information. Processes have -domain -1 and DACR 0xFFFFFFFF.
-Related tasks
--
-
- Extracting Kernel Information -
- Scheduler State -
- Current Thread State -
- Current Data Section Process -
Current Process State
+The current process is the process in whose address space the +current thread was executing when the fault occurred. The 15 lines starting at +line 33 of the output gives information relating to the current process. This +has some similarities with the current thread information:
+TheCurrentProcess=64038d5c
+ PROCESS at 64038d5c VPTR=f80342a4 AccessCount=6 Owner=00000000
Full name test2.exe
ExitInfo 3,0,
Flags a0000000, Handles 6403860c, Attributes 60010000
DataBssChunk 64039234, CodeSeg 6403919c
DllLock 64039044, Process Lock 64038eec SID 00000000
TempCodeSeg 00000000 CodeSeg 6403919c Capability 00000000 0003ffff
CodeSegs: Count=0
NumChunks=2
0: Chunk 64039234, run 00400000, access count 1
1: Chunk 6403613c, run 00600000, access count 1
Process shared IO buffers cookie 0000031d
Process has no shared IO buffers
Domain -1, DACR 55555507
The information includes:
+-
+
- + + +
- + + +
- + + +
- + + +
- + + +
- + + +
- + + +
- + + +
- + + +
- + + +
- + + +
- + + +
- + + +
PROCESS at 64038d5c VPTR=f80342a4 AccessCount=6 Owner=00000000
+The Process at field contains a pointer to the +DProcess object representing the process.
+The AccessCount field contains the reference count +on the process object.
+The owner field contains a pointer to the object +that owns this DProcess object.
+Full name test2.exe
+The Full name field gives the name of the process. +In this example, the name of the process is test2.exe.
+See the thread name.
+ExitInfo 3,0,
+The ExitInfo field contains the information that +characterises the process exit. In this example, the value is 3, meaning that +this process has not exited. See also TExitType.
+Flags a0000000, Handles 6403860c, Attributes 60010000
+The Flags field contains information about the state +of the process. The possible values in this field are defined by the +KProcess... constants in u32std.h. While the symbols +are internal to Symbian OS, the following table summarises the values and their +meaning.
+
|
Flags a0000000, Handles 6403860c, Attributes 60010000
+The Handles field contains the address of a +DObjectIx object that contains the handles owned by the +process.
+Flags a0000000, Handles 6403860c, Attributes 60010000
+The Attributes field contains the attributes of the +process. Some are generic, as defined by +DProcess::TProcessAttributes, but others depend on the +memory model.
+Information about memory
+ +DataBssChunk 64039234, CodeSeg 6403919c
+The DataBssChunk field contains a pointer to the +DChunk object representing the chunk that contains the process +data and .bss memory. Be aware that this is not the same as the +heap - heaps are allocated to threads, and chunk information is found in the +DThread object.
+The CodeSeg field contains a pointer to the +DCodeSeg object that represents the code segment.
+DllLock 64039044, Process Lock 64038eec SID 00000000
+The SID field contains the secure id of the +process.
+TempCodeSeg 00000000 CodeSeg 6403919c Capability 00000000 0003ffff
+The second four bytes of the Capability field contains the set of +bits that define the capability for this process. This defines what the process +can and cannot do.
+CodeSegs: Count=0
+The CodeSegs: Count field contains the number of +code segments that have been dynamically loaded into the process. This will be +zero if the process is XIP.
+NumChunks=2
0: Chunk 64039234, run 00400000, access count 1
1: Chunk 6403613c, run 00600000, access count 1
The NumChunks field contains the number of chunks owned by the +process.
+Successive lines contain information about each chunk:
+-
+
-
+
the Chunk field contains the address of a kernel +DChunk object.
+
+ -
+
the run field contains the virtual address at +which the chunk resides when this is the current process.
+
+ -
+
the access count field contains the reference +count of the object.
+
+
Process shared IO buffers cookie 0000031d
Process has no shared IO buffers
This is information about shared IO buffers. The cookie is only +really of interest to base engineers.
+Domain -1, DACR 55555507
+This is ARM MMU-specific protection information. Processes have +domain -1 and DACR 0xFFFFFFFF.
+Related tasks
+-
+
- Extracting Kernel Information +
- Scheduler State +
- Current Thread State +
- Current Data Section Process +
Current Data Section Process
-In the moving memory model the current process could be a fixed -process, in which case there is also a current moving process. The current data -section process is the current moving process.
-TheCurrentDataSectionProcess=64038d5c
-This field contains a pointer to the DProcess object -for the current moving process. This line is followed by detailed information -about the process itself; the format is the same as that described for the -current process state.
- -Related tasks
- - - - + + +Current Data Section Process
+In the moving memory model the current process could be a fixed +process, in which case there is also a current moving process. The current data +section process is the current moving process.
+TheCurrentDataSectionProcess=64038d5c
+This field contains a pointer to the DProcess object +for the current moving process. This line is followed by detailed information +about the process itself; the format is the same as that described for the +current process state.
+ +Related tasks
+ + + + \ No newline at end of file diff -r bf0a333d965d -r a690706fd137 debuggercdi/com.nokia.carbide.cpp.debug.crashdebugger/html/DebuggingInformation/CrashDebuggerMemoryMap.guide.html --- a/debuggercdi/com.nokia.carbide.cpp.debug.crashdebugger/html/DebuggingInformation/CrashDebuggerMemoryMap.guide.html Thu Feb 18 15:22:38 2010 -0600 +++ b/debuggercdi/com.nokia.carbide.cpp.debug.crashdebugger/html/DebuggingInformation/CrashDebuggerMemoryMap.guide.html Thu Feb 18 15:23:36 2010 -0600 @@ -1,23 +1,23 @@ - - -Symbian OS Memory Map
-
Symbian OS Memory Map
+
Kernel Objects
-Kernel objects such as DProcess, DThread, -DSemaphore, DChunk are all instances of classes -derived from DObject.
-To show basic information about a DObject, use -the o -command.
-To show more detail, use the -q command.
-As an example, use these commands to show information about a -DProcess object whose address is shown using the -i command:
-...
- TheCurrentDataSectionProcess=6403bb4c
- ...
> o 6403bb4c
-This gives:
-.o 6403bb4c
PROCESS at 6403bb4c VPTR=f8046c78 AccessCount=6 Owner=00000000
Full name crash
All objects derived from DBase have a virtual -table pointer, access count, owner and name. Using the -q command on this -address would you give you the full process information.
-You can use o to examine other -types of objects, for example chunks. The thread information for the current -data section process shows two chunks:
-NumChunks=2
0: Chunk 6403c044, run 00400000, access count 1
1: Chunk 64039688, run 00600000, access count 1
Using the o command on the first -of these chunk objects gives you the basic information:
-.o 6403c044
CHUNK at 6403c044 VPTR=f8046b50 AccessCount=1 Owner=6403bb4c
Full name crash::$DAT
Using the q command gives you -more detailed information:
-.q 6403c044
CHUNK at 6403c044 VPTR=f8046b50 AccessCount=1 Owner=6403bb4c
Full name crash::$DAT
Owning Process 6403bb4c
Size 2000, MaxSize 200000, Base 00400000
Attrib 6, StartPos 0
Type 6, State 2, Home Base 68900000
Home Region Offset 00000000
Home Region Base 68900000
Home Region Size 00100000
PTE: 0000055e, PDE: 00000021 00000001 00000001
NumPdes=1, iPdes=61000010, iHomePdes=61001a24
PdeBitMap=00000001, PageBitMap=6403c0c8
Domain -1
The information displayed is memory model dependent. It is -shown here for the moving memory model.
-Notes:
--
-
-
-
Size 2000, MaxSize 200000, Base 00400000
-The Size field shows the current size of the -chunk, in bytes.
-The MaxSize field shows the maximum size of the -chunk, in bytes.
-The Base field shows the base address in the run -region.
-
- -
-
Attrib 6, StartPos 0
-The Attrib field shows the attributes of the -chunk.
-The StartPos field shows the offset, in bytes, -between the base address and the start of the committed area. This is non-zero -for double-ended chunks only.
-
- -
-
Type 6, State 2, Home Base 68900000
-The Type field shows the type of chunk. This -corresponds to a TChunkType enum value.
-The State field shows the current state of the -chunk. This corresponds to a TChunkState enum value, which is -itself defined within the scope of the Symbian OS internal class -DMemModelChunk.
-The Home Base field is the base address of the -chunk in the home region.
-
- -
-
Home Region Offset 00000000
-
Home Region Base 68900000
Home Region Size 00100000These three lines show the offset, base address and size (the -reserved size) of the chunk in the home region.
-
-
Kernel Objects
+Kernel objects such as DProcess, DThread, +DSemaphore, DChunk are all instances of classes +derived from DObject.
+To show basic information about a DObject, use +the o +command.
+To show more detail, use the +q command.
+As an example, use these commands to show information about a +DProcess object whose address is shown using the +i command:
+...
+ TheCurrentDataSectionProcess=6403bb4c
+ ...
> o 6403bb4c
+This gives:
+.o 6403bb4c
PROCESS at 6403bb4c VPTR=f8046c78 AccessCount=6 Owner=00000000
Full name crash
All objects derived from DBase have a virtual +table pointer, access count, owner and name. Using the +q command on this +address would you give you the full process information.
+You can use o to examine other +types of objects, for example chunks. The thread information for the current +data section process shows two chunks:
+NumChunks=2
0: Chunk 6403c044, run 00400000, access count 1
1: Chunk 64039688, run 00600000, access count 1
Using the o command on the first +of these chunk objects gives you the basic information:
+.o 6403c044
CHUNK at 6403c044 VPTR=f8046b50 AccessCount=1 Owner=6403bb4c
Full name crash::$DAT
Using the q command gives you +more detailed information:
+.q 6403c044
CHUNK at 6403c044 VPTR=f8046b50 AccessCount=1 Owner=6403bb4c
Full name crash::$DAT
Owning Process 6403bb4c
Size 2000, MaxSize 200000, Base 00400000
Attrib 6, StartPos 0
Type 6, State 2, Home Base 68900000
Home Region Offset 00000000
Home Region Base 68900000
Home Region Size 00100000
PTE: 0000055e, PDE: 00000021 00000001 00000001
NumPdes=1, iPdes=61000010, iHomePdes=61001a24
PdeBitMap=00000001, PageBitMap=6403c0c8
Domain -1
The information displayed is memory model dependent. It is +shown here for the moving memory model.
+Notes:
+-
+
-
+
Size 2000, MaxSize 200000, Base 00400000
+The Size field shows the current size of the +chunk, in bytes.
+The MaxSize field shows the maximum size of the +chunk, in bytes.
+The Base field shows the base address in the run +region.
+
+ -
+
Attrib 6, StartPos 0
+The Attrib field shows the attributes of the +chunk.
+The StartPos field shows the offset, in bytes, +between the base address and the start of the committed area. This is non-zero +for double-ended chunks only.
+
+ -
+
Type 6, State 2, Home Base 68900000
+The Type field shows the type of chunk. This +corresponds to a TChunkType enum value.
+The State field shows the current state of the +chunk. This corresponds to a TChunkState enum value, which is +itself defined within the scope of the Symbian OS internal class +DMemModelChunk.
+The Home Base field is the base address of the +chunk in the home region.
+
+ -
+
Home Region Offset 00000000
+
Home Region Base 68900000
Home Region Size 00100000These three lines show the offset, base address and size (the +reserved size) of the chunk in the home region.
+
+
Kernel Containers
-Internally, the kernel maintains lists of all current objects, -organized by type. Each list is a container, a DObjectCon object, -with one for each object type.
-The c -command will walk through all objects in a given list. The type of object is -identified by appending a number after the command. For example, -DProcess objects are identified by the number 1, so to walk -through all current DProcess objects type:
-> c1
-The command effectively executes a -q command on each -object in the "processes" container.
- -Kernel Containers
+Internally, the kernel maintains lists of all current objects, +organized by type. Each list is a container, a DObjectCon object, +with one for each object type.
+The c +command will walk through all objects in a given list. The type of object is +identified by appending a number after the command. For example, +DProcess objects are identified by the number 1, so to walk +through all current DProcess objects type:
+> c1
+The command effectively executes a +q command on each +object in the "processes" container.
+ +Process, Thread, Stack and Memory Useful Information
--
-
- - - -
- - - -
- - - -
- - - -
- - - -
- - - -
- - - -
Process, Thread, Stack and Memory Useful Information
+-
+
- + + +
- + + +
- + + +
- + + +
- + + +
- + + +
- + + +
Process and Thread Priorities
--Internally the scheduler always deals with nanokernel threads, -NThread objects, and their associated priority between 0 (lowest) -and 63 (highest). In general, a thread with a higher priority that is ready to -run will always run in preference to threads with a lower priority. The only -exception is where a higher priority thread waits on a nanokernel fast mutex -held by a lower priority thread. In this case, the higher priority thread will -yield to the lower priority thread holding the mutex. -
--A Symbian OS thread, a DThread object, has an embedded -NThread, which enables it to be scheduled by the nanokernel. -
--There are two ways of setting a priority for Symbian OS thread: -
--
-
-
-
-using the two-level priority scheme -
-
- -
-
-using an absolute priority. -
-
-
-In this scheme, a Symbian OS thread priority is relative to the -priority of its owning process. By default, Symbian OS threads inherit the -priority of their owning process when they are created. This priority can be -raised or lowered relative to the process priority - this just sets the -thread’s priority to the process priority plus or minus a specified priority -weighting. If the priority of the process is changed, the priority of its -threads will change relative to other threads in the system but will remain the -same relative to each other. -
--The default priority of a process is -EPriorityForgeround, which is an absolute priority of 350. Threads -by default are created with relative priority EPriorityNormal -which sets them to the same priority as the owning process. The window server -lowers the priority of background UI processes to -EPriorityBackground (250). -
--The NULL thread, also known as the idle thread, runs at priority 0, -and means that it will only run when there are no other threads ready to run. -
--Symbian OS thread priorities map onto NThread priorities -in the range 1 to 31 as shown in the table below. -
|
-where: -
--
-
-
-
-the process priority values are defined by the internal Symbian -OS enum TProcPriority, defined in -...\e32\include\kernel\kern_priv.h. The symbols in the table -correspond to the symbols in the enum. -
-
- -
-
-the thread priority values are defined by the internal Symbian OS -enum TThrdPriority, defined in -...\e32\include\kernel\kern_priv.h. The symbols in the table -correspond to the symbols in the enum. -
-
-
-It is possible to set an absolute priority that is not relative to -the process priority; it is not affected by changes in the process priority. -
-Process and Thread Priorities
++Internally the scheduler always deals with nanokernel threads, +NThread objects, and their associated priority between 0 (lowest) +and 63 (highest). In general, a thread with a higher priority that is ready to +run will always run in preference to threads with a lower priority. The only +exception is where a higher priority thread waits on a nanokernel fast mutex +held by a lower priority thread. In this case, the higher priority thread will +yield to the lower priority thread holding the mutex. +
++A Symbian OS thread, a DThread object, has an embedded +NThread, which enables it to be scheduled by the nanokernel. +
++There are two ways of setting a priority for Symbian OS thread: +
+-
+
-
+
+using the two-level priority scheme +
+
+ -
+
+using an absolute priority. +
+
+
+In this scheme, a Symbian OS thread priority is relative to the +priority of its owning process. By default, Symbian OS threads inherit the +priority of their owning process when they are created. This priority can be +raised or lowered relative to the process priority - this just sets the +thread’s priority to the process priority plus or minus a specified priority +weighting. If the priority of the process is changed, the priority of its +threads will change relative to other threads in the system but will remain the +same relative to each other. +
++The default priority of a process is +EPriorityForgeround, which is an absolute priority of 350. Threads +by default are created with relative priority EPriorityNormal +which sets them to the same priority as the owning process. The window server +lowers the priority of background UI processes to +EPriorityBackground (250). +
++The NULL thread, also known as the idle thread, runs at priority 0, +and means that it will only run when there are no other threads ready to run. +
++Symbian OS thread priorities map onto NThread priorities +in the range 1 to 31 as shown in the table below. +
|
+where: +
+-
+
-
+
+the process priority values are defined by the internal Symbian +OS enum TProcPriority, defined in +...\e32\include\kernel\kern_priv.h. The symbols in the table +correspond to the symbols in the enum. +
+
+ -
+
+the thread priority values are defined by the internal Symbian OS +enum TThrdPriority, defined in +...\e32\include\kernel\kern_priv.h. The symbols in the table +correspond to the symbols in the enum. +
+
+
+It is possible to set an absolute priority that is not relative to +the process priority; it is not affected by changes in the process priority. +
+Thread State Summary
--This is a brief summary about nanokernel thread states and Symbian OS -thread states. -
- --The state of a nanokernel thread is referred to as the NState (or -N-state). This is to disambiguate it from any other state, such as the state of -a Symbian OS thread (referred to as the MState or M-state). -
--The states of a nanokernel thread are defined by the values of the NThreadBase::NThreadState enumeration. -
- --The state of a Symbian OS thread is referred to as the MState (or -M_state). This is in addition to the nanokernel N-state, and tracks threads -waiting on Symbian OS synchronisation objects. The DThread class -representing a Symbian OS thread is internal to Symbian, but the following -table defines its possible states. The values in the left-hand column are the -enumerators of the internal enumeration DThread::TThreadState. -
-
|
Thread State Summary
++This is a brief summary about nanokernel thread states and Symbian OS +thread states. +
+ ++The state of a nanokernel thread is referred to as the NState (or +N-state). This is to disambiguate it from any other state, such as the state of +a Symbian OS thread (referred to as the MState or M-state). +
++The states of a nanokernel thread are defined by the values of the NThreadBase::NThreadState enumeration. +
+ ++The state of a Symbian OS thread is referred to as the MState (or +M_state). This is in addition to the nanokernel N-state, and tracks threads +waiting on Symbian OS synchronisation objects. The DThread class +representing a Symbian OS thread is internal to Symbian, but the following +table defines its possible states. The values in the left-hand column are the +enumerators of the internal enumeration DThread::TThreadState. +
+
|
Thread and Process Exit Information Summary
--User threads and processes have “exit information”. When a thread or -process terminates the reason for the termination is found in the exit -information. For example, a panic will store the panic category and reason in -the exit information. Exit information has three parts: the exit type, exit -reason and exit category. -
--Exit type is defined by the TExitType enum. -
--When a thread or process is created, its exit type is set to 3. An exit -type of 3 indicates that the thread is still active, though not necessarily -running. If the thread terminates for any reason, then the exit type is changed -to reflect the cause of the exit. -
--Once the thread or process has exited, the exit reason and exit type -fields will contain useful information. The contents depends on the type of -exit. -
--Note that if the main thread in a process exits, then the process will -exit with the same exit information as the thread. -
- --if RThread::Terminate() or RProcess::Terminate() is called, then the exit category is -Terminate, and the exit reason is the value of the -aReason argument passed to these functions. -
- --If RThread::Kill() or RProcess::Kill() is called, then the exit category is -Kill, and the exit reason is the value of the aReason -argument passed to these functions. -
- --If a thread panics, then the exit category is panic, and -the exit reason is the panic number. For example a USER-19 panic would give the -following exit information: -
-exit type = 2
- exit category = “USER”
exit reason = 19
Thread and Process Exit Information Summary
++User threads and processes have “exit information”. When a thread or +process terminates the reason for the termination is found in the exit +information. For example, a panic will store the panic category and reason in +the exit information. Exit information has three parts: the exit type, exit +reason and exit category. +
++Exit type is defined by the TExitType enum. +
++When a thread or process is created, its exit type is set to 3. An exit +type of 3 indicates that the thread is still active, though not necessarily +running. If the thread terminates for any reason, then the exit type is changed +to reflect the cause of the exit. +
++Once the thread or process has exited, the exit reason and exit type +fields will contain useful information. The contents depends on the type of +exit. +
++Note that if the main thread in a process exits, then the process will +exit with the same exit information as the thread. +
+ ++if RThread::Terminate() or RProcess::Terminate() is called, then the exit category is +Terminate, and the exit reason is the value of the +aReason argument passed to these functions. +
+ ++If RThread::Kill() or RProcess::Kill() is called, then the exit category is +Kill, and the exit reason is the value of the aReason +argument passed to these functions. +
+ ++If a thread panics, then the exit category is panic, and +the exit reason is the panic number. For example a USER-19 panic would give the +following exit information: +
+exit type = 2
+ exit category = “USER”
exit reason = 19
Critical Threads and Processes
--Marking a thread or process as “system critical” means that it is an -integral and essential part of the system, for example, the file server. In -effect the thread or process is being declared necessary for correct -functioning of the device. If a system critical thread exits or panics then the -device will reboot; during development it will enter the debug monitor. A -thread can be set as process critical, which means that if it panics the -process will be panicked. -
-Critical Threads and Processes
++Marking a thread or process as “system critical” means that it is an +integral and essential part of the system, for example, the file server. In +effect the thread or process is being declared necessary for correct +functioning of the device. If a system critical thread exits or panics then the +device will reboot; during development it will enter the debug monitor. A +thread can be set as process critical, which means that if it panics the +process will be panicked. +
+Kernel Calls and Thread Context
--When a user thread makes a call into any kernel code, the kernel code -continues to run in the context of the user thread. This applies to device -driver code. -
--The stack is swapped to a kernel-side stack and the permissions of the -thread are increased to kernel privilege, but otherwise the user thread is -still running. Each thread has a small kernel stack used to handle kernel calls -– it would be dangerous to continue using the normal thread stack in case it -overflows. Some calls are handled in this state, others – typically device -drivers – will post a message to a kernel side thread to carry out the request. -
-Kernel Calls and Thread Context
++When a user thread makes a call into any kernel code, the kernel code +continues to run in the context of the user thread. This applies to device +driver code. +
++The stack is swapped to a kernel-side stack and the permissions of the +thread are increased to kernel privilege, but otherwise the user thread is +still running. Each thread has a small kernel stack used to handle kernel calls +– it would be dangerous to continue using the normal thread stack in case it +overflows. Some calls are handled in this state, others – typically device +drivers – will post a message to a kernel side thread to carry out the request. +
+Stacks
--When a process is created, a chunk is allocated to hold the process -executable's .data section (initialised data) and -.bss section (zero filled data). Sufficient space (default 2Mb) is -also reserved as user-side stack space for threads that run in that process. -
--By default, each thread is allocated 8k of user-side stack space. A -guard of 8k is also allocated. -
--The stack area follows the .data and .bss -sections, and each thread's user side stack follows. On ARM processors the -stack is descending, so that as items are added to the stack, the stack pointer -is decremented. This means that if the stack overflows, the stack pointer -points into the guard area and causes a processor exception, with the result -that the kernel panics the thread. -
-
-Return addresses are stored by pushing them on to the stack so at any -point you can trace through the stack looking at the saved return addresses to -see the chain of function calls up to the present function. -
--The size of the user-side stack space has an indirect effect on the -number of of threads that a process can have. There are other factors involved, -but this is an important one. The limit is a consequence of the fact that a -process can have a maximum of 8 chunks. This means that if threads within a -process can share a heap (allocated from a single chunk), then it is possible -to have a maximum of 128 threads per process [2Mb/(8K + 8K)]. More threads may -be possible if you allow only 4K of stack per thread. -
--Apart from the kernel stack attached to each thread, the kernel also -maintains stacks that are used during processing of interrupts, exceptions and -certain CPU states. Interrupts and exceptions can occur at any time, with the -system in any state, and it would be dangerous to allow them to use the current -stack which may not even be valid or may overflow and panic the kernel. The -kernel stacks are guaranteed to be large enough for all interrupt and exception -processing. -
-Stacks
++When a process is created, a chunk is allocated to hold the process +executable's .data section (initialised data) and +.bss section (zero filled data). Sufficient space (default 2Mb) is +also reserved as user-side stack space for threads that run in that process. +
++By default, each thread is allocated 8k of user-side stack space. A +guard of 8k is also allocated. +
++The stack area follows the .data and .bss +sections, and each thread's user side stack follows. On ARM processors the +stack is descending, so that as items are added to the stack, the stack pointer +is decremented. This means that if the stack overflows, the stack pointer +points into the guard area and causes a processor exception, with the result +that the kernel panics the thread. +
+
+Return addresses are stored by pushing them on to the stack so at any +point you can trace through the stack looking at the saved return addresses to +see the chain of function calls up to the present function. +
++The size of the user-side stack space has an indirect effect on the +number of of threads that a process can have. There are other factors involved, +but this is an important one. The limit is a consequence of the fact that a +process can have a maximum of 8 chunks. This means that if threads within a +process can share a heap (allocated from a single chunk), then it is possible +to have a maximum of 128 threads per process [2Mb/(8K + 8K)]. More threads may +be possible if you allow only 4K of stack per thread. +
++Apart from the kernel stack attached to each thread, the kernel also +maintains stacks that are used during processing of interrupts, exceptions and +certain CPU states. Interrupts and exceptions can occur at any time, with the +system in any state, and it would be dangerous to allow them to use the current +stack which may not even be valid or may overflow and panic the kernel. The +kernel stacks are guaranteed to be large enough for all interrupt and exception +processing. +
+Virtual Memory and Run Addresses
--Symbian OS devices have an MMU which is used to map the addresses seen -by running code to real addresses of memory and I/O. The MMU in effect creates -a virtual memory map, allowing scattered blocks of RAM to appear contiguous, or -for a section of memory to appear at different addresses in different -processes, or not at all. -
--Symbian OS uses the MMU to provide memory protection between processes, -to allow sharing of memory, efficient allocation of RAM and to make all -processes “see” the same memory layout. Three different memory models are -supported by Symbian OS on ARM CPUs: -
--
-
-
-
-moving model: this is the model familiar from EKA1 where processes -are moved to a run-address in low memory when executing and moved back to a -home-address in high memory when not running. -
-
- -
-
-direct model: this is used when the CPU does not have an MMU, or is -emulating a system without an MMU. Not normally used, but occasionally useful -for development boards -
-
- -
-
-multiple model: only supported in ARM architecture V6 and above, -each process has its own set of MMU tables. A context switch changes the -current MMU table to the new thread’s table, instead of moving memory about in -a single table as with moving model. -
-
-
-For ARM architectures with a virtually-tagged cache, fixed processes -avoid the need to flush the cache on context switches by keeping all the code -and data at a fixed address. This implies that there can only ever be one -instance of each fixed process because the data chunk address cannot be -changed. -
--Important servers such as the file server and window server are -fixed. -
--There is no limit to the number of fixed processes that can be -supported. The kernel will attempt to use ARM domains for fixed process -protection, but there are a limited number of domains so when they are -exhausted normal MMU techniques will be used. Domains are slightly faster in a -context switch but this is negligible compared to the real purpose of the fixed -process in avoiding the cache flush. -
- -Virtual Memory and Run Addresses
++Symbian OS devices have an MMU which is used to map the addresses seen +by running code to real addresses of memory and I/O. The MMU in effect creates +a virtual memory map, allowing scattered blocks of RAM to appear contiguous, or +for a section of memory to appear at different addresses in different +processes, or not at all. +
++Symbian OS uses the MMU to provide memory protection between processes, +to allow sharing of memory, efficient allocation of RAM and to make all +processes “see” the same memory layout. Three different memory models are +supported by Symbian OS on ARM CPUs: +
+-
+
-
+
+moving model: this is the model familiar from EKA1 where processes +are moved to a run-address in low memory when executing and moved back to a +home-address in high memory when not running. +
+
+ -
+
+direct model: this is used when the CPU does not have an MMU, or is +emulating a system without an MMU. Not normally used, but occasionally useful +for development boards +
+
+ -
+
+multiple model: only supported in ARM architecture V6 and above, +each process has its own set of MMU tables. A context switch changes the +current MMU table to the new thread’s table, instead of moving memory about in +a single table as with moving model. +
+
+
+For ARM architectures with a virtually-tagged cache, fixed processes +avoid the need to flush the cache on context switches by keeping all the code +and data at a fixed address. This implies that there can only ever be one +instance of each fixed process because the data chunk address cannot be +changed. +
++Important servers such as the file server and window server are +fixed. +
++There is no limit to the number of fixed processes that can be +supported. The kernel will attempt to use ARM domains for fixed process +protection, but there are a limited number of domains so when they are +exhausted normal MMU techniques will be used. Domains are slightly faster in a +context switch but this is negligible compared to the real purpose of the fixed +process in avoiding the cache flush. +
+ +Debug Monitor
-The debug monitor is entered when the kernel crashes, if a system -process panics, or an unhandled processor exception occurs. Under normal -circumstances this ought not to happen, but when the kernel faults, the device -enters the kernel debug monitor. The Debug Monitor appears in Carbide as a view within the Crash Debugger perspective. Use the Crash Debugger Console view to enter commands and interact with the Debug Monitor on the device.
-Notes:
--
-
-
-
the EKA2 debug monitor is very similar to the EKA1 version, -although the details displayed may be different.
-
- -
-
you will occasionally find references to the crash -debugger; this is the same as the debug monitor
-
-
Related tasks
- -Related references
- - - - + + +Debug Monitor
+The debug monitor is entered when the kernel crashes, if a system +process panics, or an unhandled processor exception occurs. Under normal +circumstances this ought not to happen, but when the kernel faults, the device +enters the kernel debug monitor. The Debug Monitor appears in Carbide as a view within the Crash Debugger perspective. Use the Crash Debugger Console view to enter commands and interact with the Debug Monitor on the device.
+Notes:
+-
+
-
+
the EKA2 debug monitor is very similar to the EKA1 version, +although the details displayed may be different.
+
+ -
+
you will occasionally find references to the crash +debugger; this is the same as the debug monitor
+
+
Related tasks
+ +Related references
+ + + + \ No newline at end of file diff -r bf0a333d965d -r a690706fd137 debuggercdi/com.nokia.carbide.cpp.debug.crashdebugger/html/DebuggingInformation/CrashDebuggerUsingMAKSYM-Ref.guide.html --- a/debuggercdi/com.nokia.carbide.cpp.debug.crashdebugger/html/DebuggingInformation/CrashDebuggerUsingMAKSYM-Ref.guide.html Thu Feb 18 15:22:38 2010 -0600 +++ b/debuggercdi/com.nokia.carbide.cpp.debug.crashdebugger/html/DebuggingInformation/CrashDebuggerUsingMAKSYM-Ref.guide.html Thu Feb 18 15:23:36 2010 -0600 @@ -1,51 +1,51 @@ - - -Using the MAKSYM Tool
-MAKSYM is a command line tool that processes the log file generated -when building a ROM image, and creates a text file that lists the address of -every global and exported function in the ROM.
-Reference: tools: MAKSYM outlines -the syntax of the command.
-If you know the address of the instruction which caused an exception, -you can compare this address with the MAKSYM log to see which function this is -in. You can narrow this down to the exact code within the function by using -ABLD LISTING to get the assembler output from the compiler.
-The following example MAKSYM log is taken from an EKA1 build; -however, the principle is the same for EKA2.
-From \Epoc32\Release\Misa\UREL\ekern.exe
-
50003040 0094 _E32Startup
500030d4 002c ImpDma::Init1(void)
50003100 0004 ImpDma::Init3(void)
50003104 0008 ImpDma::MaxBlockSize(void)
If, for example, the code address of the exception is at -0x500030dc, then you can see from the log that this is in the -ImpDma::Init1() function, at offset 8 from the start of the -function. This function is in the file -...\e32\ekern\epoc\arm\sa1100\ka_dma.cpp, so use ABLD LISTING to -obtain the assembler:
-> cd \e32
-> abld listing misa urel ekern ka_dma
-Notice that you must specify the component that the file is part of, -in this case EKERN, and that you do not put the .cpp extension on -the source file name. If you do not specify a source file ABLD will create an -assembler listing for every file in component EKERN.
-The listing file will be placed in the same directory as -ka_dma.cpp, and will be called ka_dma.lis. If you -look at this file you will see something like this:
-7 Init1__6ImpDma:
8 @ args = 0, pretend = 0, frame = 0
9 @ frame_needed = 0, current_function_anonymous_args = 0
10 @ I don't think this function clobbers lr
11 0000 18209FE5 ldr r2, .L793
12 0004 0630A0E3 mov r3, #6
13 0008 003082E5 str r3, [r2, #0]
14 000c 10309FE5 ldr r3, .L793+4
15 0010 10009FE5 ldr r0, .L793+8
16 0014 000083E5 str r0, [r3, #0]
17 0018 1810A0E3 mov r1, #24
18 001c FEFFFFEA b FillZ__3MemPvi
Offset 8 is the first STR instruction. Comparing this with the C++ -source:
-void ImpDma::Init1()
//
// Phase 1 initialisation of the Dma channels
//
{
PP::DmaMaxChannels=KNumberOfDmaChannels;
PP::DmaChannelTable=(TDma **)(&DmaChannels[0]);
Mem::FillZ(PP::DmaChannelTable,sizeof(TDma *)*KNumberOfDmaChannels);
}
The first store is to PP::DmaMaxChannels, so clearly there is a -problem writing this memory.
- -Using the MAKSYM Tool
+MAKSYM is a command line tool that processes the log file generated +when building a ROM image, and creates a text file that lists the address of +every global and exported function in the ROM.
+Reference: tools: MAKSYM outlines +the syntax of the command.
+If you know the address of the instruction which caused an exception, +you can compare this address with the MAKSYM log to see which function this is +in. You can narrow this down to the exact code within the function by using +ABLD LISTING to get the assembler output from the compiler.
+The following example MAKSYM log is taken from an EKA1 build; +however, the principle is the same for EKA2.
+From \Epoc32\Release\Misa\UREL\ekern.exe
+
50003040 0094 _E32Startup
500030d4 002c ImpDma::Init1(void)
50003100 0004 ImpDma::Init3(void)
50003104 0008 ImpDma::MaxBlockSize(void)
If, for example, the code address of the exception is at +0x500030dc, then you can see from the log that this is in the +ImpDma::Init1() function, at offset 8 from the start of the +function. This function is in the file +...\e32\ekern\epoc\arm\sa1100\ka_dma.cpp, so use ABLD LISTING to +obtain the assembler:
+> cd \e32
+> abld listing misa urel ekern ka_dma
+Notice that you must specify the component that the file is part of, +in this case EKERN, and that you do not put the .cpp extension on +the source file name. If you do not specify a source file ABLD will create an +assembler listing for every file in component EKERN.
+The listing file will be placed in the same directory as +ka_dma.cpp, and will be called ka_dma.lis. If you +look at this file you will see something like this:
+7 Init1__6ImpDma:
8 @ args = 0, pretend = 0, frame = 0
9 @ frame_needed = 0, current_function_anonymous_args = 0
10 @ I don't think this function clobbers lr
11 0000 18209FE5 ldr r2, .L793
12 0004 0630A0E3 mov r3, #6
13 0008 003082E5 str r3, [r2, #0]
14 000c 10309FE5 ldr r3, .L793+4
15 0010 10009FE5 ldr r0, .L793+8
16 0014 000083E5 str r0, [r3, #0]
17 0018 1810A0E3 mov r1, #24
18 001c FEFFFFEA b FillZ__3MemPvi
Offset 8 is the first STR instruction. Comparing this with the C++ +source:
+void ImpDma::Init1()
//
// Phase 1 initialisation of the Dma channels
//
{
PP::DmaMaxChannels=KNumberOfDmaChannels;
PP::DmaChannelTable=(TDma **)(&DmaChannels[0]);
Mem::FillZ(PP::DmaChannelTable,sizeof(TDma *)*KNumberOfDmaChannels);
}
The first store is to PP::DmaMaxChannels, so clearly there is a +problem writing this memory.
+ +Setting Up the Debug Monitor
-When the kernel faults, the device enters the debug monitor, called the Crash Debugger Console view of the Crash Debugger perspective.
-Using the Debug Monitor
--
-
- Plug the main adaptor into the DC jack -
- Connect the target device COM port to your PC
-
-
-
- In Carbide, create a launch configuration and set the serial port info as shown below -
- If not using Carbide, set the PC - serial port to 115200 baud, 8 bits, no parity, 1 stop bit, XON/XOFF flow - control -
- - Press the ON key on the target device -
- Start a terminal program on the PC
-
-
-
- In Carbide, output appears in the Crash Debugger Console view of the Crash Debugger Perspective -
- For external verification of the COM port you can use HyperTerminal -
- - Press RETURN on the PC. The target device
- should reply with the prompt:
-
-
-Password:
-
- - Enter the password "replacement" (all lower case, but without the quotes) on the PC. -
The target device should now reply:
---*** DEBUG MONITOR ***
-
You can now enter debug monitor commands.
-Related concepts
- -Related references
- - - - - + + +Setting Up the Debug Monitor
+When the kernel faults, the device enters the debug monitor, called the Crash Debugger Console view of the Crash Debugger perspective.
+Using the Debug Monitor
+-
+
- Plug the main adaptor into the DC jack +
- Connect the target device COM port to your PC
+
-
+
- In Carbide, create a launch configuration and set the serial port info as shown below +
- If not using Carbide, set the PC + serial port to 115200 baud, 8 bits, no parity, 1 stop bit, XON/XOFF flow + control +
+ - Press the ON key on the target device +
- Start a terminal program on the PC
+
-
+
- In Carbide, output appears in the Crash Debugger Console view of the Crash Debugger Perspective +
- For external verification of the COM port you can use HyperTerminal +
+ - Press RETURN on the PC. The target device
+ should reply with the prompt:
+
+
+Password:
+
+ - Enter the password "replacement" (all lower case, but without the quotes) on the PC. +
The target device should now reply:
+++*** DEBUG MONITOR ***
+
You can now enter debug monitor commands.
+Related concepts
+ +Related references
+ + + + + \ No newline at end of file diff -r bf0a333d965d -r a690706fd137 debuggercdi/com.nokia.carbide.cpp.debug.crashdebugger/html/DebuggingInformation/CrashDebugger_cmd.guide.html --- a/debuggercdi/com.nokia.carbide.cpp.debug.crashdebugger/html/DebuggingInformation/CrashDebugger_cmd.guide.html Thu Feb 18 15:22:38 2010 -0600 +++ b/debuggercdi/com.nokia.carbide.cpp.debug.crashdebugger/html/DebuggingInformation/CrashDebugger_cmd.guide.html Thu Feb 18 15:23:36 2010 -0600 @@ -1,77 +1,77 @@ - - -Crash Debugger Commands
-Commands consist of a single letter describing the operation to be -performed, followed by any arguments. Not all commands take arguments. Commands -are case sensitive; the majority are lower case. Commands should be entered at -the command prompt, on the PC. The set of supported commands is as -follows:
--
-
- h - show all debugger commands -
- x - leaves the debugger, does a cold restart of the same ROM image; (nb lower case) -
- - - -
- - - -
-
-
m - -does a memory dump
-
- -
-
z - -does a memory dump, but skips over unmapped memory space
-
- -
-
i - -displays information on the current thread and the current process
-
- - - - -
- - - -
- - - -
- - - -
- - - -
Related concepts
- -Related tasks
- - - - + + +Crash Debugger Commands
+Commands consist of a single letter describing the operation to be +performed, followed by any arguments. Not all commands take arguments. Commands +are case sensitive; the majority are lower case. Commands should be entered at +the command prompt, on the PC. The set of supported commands is as +follows:
+-
+
- h - show all debugger commands +
- x - leaves the debugger, does a cold restart of the same ROM image; (nb lower case) +
- + + +
- + + +
-
+
m - +does a memory dump
+
+ -
+
z - +does a memory dump, but skips over unmapped memory space
+
+ -
+
i - +displays information on the current thread and the current process
+
+ - + + +
- + + +
- + + +
- + + +
- + + +
Related concepts
+ +Related tasks
+ + + + \ No newline at end of file diff -r bf0a333d965d -r a690706fd137 debuggercdi/com.nokia.carbide.cpp.debug.crashdebugger/html/DebuggingInformation/CrashDebugger_cmd_CC.guide.html --- a/debuggercdi/com.nokia.carbide.cpp.debug.crashdebugger/html/DebuggingInformation/CrashDebugger_cmd_CC.guide.html Thu Feb 18 15:22:38 2010 -0600 +++ b/debuggercdi/com.nokia.carbide.cpp.debug.crashdebugger/html/DebuggingInformation/CrashDebugger_cmd_CC.guide.html Thu Feb 18 15:23:36 2010 -0600 @@ -1,29 +1,29 @@ - - -C - Display Contents of Object -Container
-This is exactly the same as the lower case -c command except -that the display of output pauses between pages. If you need to dump output as -fast as possible without pauses, use the lower case version.
-Related concepts
--
-
- Debug Monitor -
Related references
- - - - + + +C - Display Contents of Object +Container
+This is exactly the same as the lower case +c command except +that the display of output pauses between pages. If you need to dump output as +fast as possible without pauses, use the lower case version.
+Related concepts
+-
+
- Debug Monitor +
Related references
+ + + + \ No newline at end of file diff -r bf0a333d965d -r a690706fd137 debuggercdi/com.nokia.carbide.cpp.debug.crashdebugger/html/DebuggingInformation/CrashDebugger_cmd_XX.guide.html --- a/debuggercdi/com.nokia.carbide.cpp.debug.crashdebugger/html/DebuggingInformation/CrashDebugger_cmd_XX.guide.html Thu Feb 18 15:22:38 2010 -0600 +++ b/debuggercdi/com.nokia.carbide.cpp.debug.crashdebugger/html/DebuggingInformation/CrashDebugger_cmd_XX.guide.html Thu Feb 18 15:23:36 2010 -0600 @@ -1,27 +1,27 @@ - - -X - Leave Debugger, Return to -Bootloader
-This command, in upper case, leaves the debugger, and returns to -the bootloader to wait for a new ROM image to be downloaded.
-Related concepts
--
-
- Debug Monitor -
Related references
- - - - - + + +X - Leave Debugger, Return to +Bootloader
+This command, in upper case, leaves the debugger, and returns to +the bootloader to wait for a new ROM image to be downloaded.
+Related concepts
+-
+
- Debug Monitor +
Related references
+ + + + + \ No newline at end of file diff -r bf0a333d965d -r a690706fd137 debuggercdi/com.nokia.carbide.cpp.debug.crashdebugger/html/DebuggingInformation/CrashDebugger_cmd_c.guide.html --- a/debuggercdi/com.nokia.carbide.cpp.debug.crashdebugger/html/DebuggingInformation/CrashDebugger_cmd_c.guide.html Thu Feb 18 15:22:38 2010 -0600 +++ b/debuggercdi/com.nokia.carbide.cpp.debug.crashdebugger/html/DebuggingInformation/CrashDebugger_cmd_c.guide.html Thu Feb 18 15:23:36 2010 -0600 @@ -1,215 +1,215 @@ - - -c - Display Contents of Object -Container
-This command displays the contents of one of the kernel's object -containers, a DObjectCon type. Note that information is dumped -very quickly without page breaks, which is useful in situations where the -kernel is likely to become very unstable very shortly after crashing. There is -an upper case version of this command, -C, which generates -output with a pause between pages.
-The command has the following syntax:
-c type
-where type is a single hexadecimal digit between 0 and -D inclusive that specifies which kernel container is to be dumped. The mapping -between the hexadecimal digit and the kernel container is:
-
|
For example:
-> c A
-Container 10 at 640275c4 contains 3 PHYSICAL DEVICES:
- PHYSICAL DEVICE at 64032dac VPTR=f805d9fc AccessCount=2 Owner=00000000
- Full name Media.IRam
- PHYSICAL DEVICE at 640339e8 VPTR=f8067e44 AccessCount=2 Owner=00000000
- Full name Media.Flash
- PHYSICAL DEVICE at 64033a64 VPTR=f806b9f8 AccessCount=2 Owner=00000000
- Full name Media.Ata
> c 0
-Container 0 at 807022b8 contains 12 THREADS:
- THREAD at 807011c0 VPTR=50052b04 AccessCount=1 Owner=8070107c
- Full name EKern::Null
- Thread MState READY
- Default priority 0 WaitLink Priority 0
- ExitInfo 3,0,
- Flags 0000000c, Handles 80701520
- Supervisor stack base 80700000 size 1000
- User stack base 00000000 size 0
- Id=0, Heap=00000000, Created heap=00000000, Frame=00000000
- Trap handler=00000000, ActiveScheduler=00000000, Exception
- handler=00000000
- TempObj=00000000 TempAlloc=00000000
- NThread @ 8070147c Pri 0 NState READY
- Next=8070147c Prev=8070147c Att=00 ExcInUserMode=00
- HeldFM=00000000 WaitFM=00000000 AddrSp=8070107c
- Time=-1 Timeslice=-1 ReqCount=0
- SuspendCount=0 CsCount=0 CsFunction=00000000
- SavedSP=80700f50
- CAR 00000001
- DACR 55555547
- R13_USR 00403ed4 R14_USR 500c88b4 SPSR_SVC 200000d3
- R4 00000009 R5 5004b7ec R6 50000000 R7 dc911000
- R8 00000000 R9 807103c0 R10 50002140 R11 80700fb4
- PC 500481b4
The information displayed for each object is the same as that shown -after using the q command. After displaying the information for each object, the debugger pauses -until you press a key.
-Notes
--
-
-
-
the DObjectCon class is internal to Symbian -OS.
-
- - the type value passed as an argument to the command is one of -the enum values of the TObjectType enum; this enum is internal to -Symbian OS. -
Related concepts
--
-
- Debug Monitor -
Related references
- - - - - + + +c - Display Contents of Object +Container
+This command displays the contents of one of the kernel's object +containers, a DObjectCon type. Note that information is dumped +very quickly without page breaks, which is useful in situations where the +kernel is likely to become very unstable very shortly after crashing. There is +an upper case version of this command, +C, which generates +output with a pause between pages.
+The command has the following syntax:
+c type
+where type is a single hexadecimal digit between 0 and +D inclusive that specifies which kernel container is to be dumped. The mapping +between the hexadecimal digit and the kernel container is:
+
|
For example:
+> c A
+Container 10 at 640275c4 contains 3 PHYSICAL DEVICES:
+ PHYSICAL DEVICE at 64032dac VPTR=f805d9fc AccessCount=2 Owner=00000000
+ Full name Media.IRam
+ PHYSICAL DEVICE at 640339e8 VPTR=f8067e44 AccessCount=2 Owner=00000000
+ Full name Media.Flash
+ PHYSICAL DEVICE at 64033a64 VPTR=f806b9f8 AccessCount=2 Owner=00000000
+ Full name Media.Ata
> c 0
+Container 0 at 807022b8 contains 12 THREADS:
+ THREAD at 807011c0 VPTR=50052b04 AccessCount=1 Owner=8070107c
+ Full name EKern::Null
+ Thread MState READY
+ Default priority 0 WaitLink Priority 0
+ ExitInfo 3,0,
+ Flags 0000000c, Handles 80701520
+ Supervisor stack base 80700000 size 1000
+ User stack base 00000000 size 0
+ Id=0, Heap=00000000, Created heap=00000000, Frame=00000000
+ Trap handler=00000000, ActiveScheduler=00000000, Exception
+ handler=00000000
+ TempObj=00000000 TempAlloc=00000000
+ NThread @ 8070147c Pri 0 NState READY
+ Next=8070147c Prev=8070147c Att=00 ExcInUserMode=00
+ HeldFM=00000000 WaitFM=00000000 AddrSp=8070107c
+ Time=-1 Timeslice=-1 ReqCount=0
+ SuspendCount=0 CsCount=0 CsFunction=00000000
+ SavedSP=80700f50
+ CAR 00000001
+ DACR 55555547
+ R13_USR 00403ed4 R14_USR 500c88b4 SPSR_SVC 200000d3
+ R4 00000009 R5 5004b7ec R6 50000000 R7 dc911000
+ R8 00000000 R9 807103c0 R10 50002140 R11 80700fb4
+ PC 500481b4
The information displayed for each object is the same as that shown +after using the q command. After displaying the information for each object, the debugger pauses +until you press a key.
+Notes
+-
+
-
+
the DObjectCon class is internal to Symbian +OS.
+
+ - the type value passed as an argument to the command is one of +the enum values of the TObjectType enum; this enum is internal to +Symbian OS. +
Related concepts
+-
+
- Debug Monitor +
Related references
+ + + + + \ No newline at end of file diff -r bf0a333d965d -r a690706fd137 debuggercdi/com.nokia.carbide.cpp.debug.crashdebugger/html/DebuggingInformation/CrashDebugger_cmd_f.guide.html --- a/debuggercdi/com.nokia.carbide.cpp.debug.crashdebugger/html/DebuggingInformation/CrashDebugger_cmd_f.guide.html Thu Feb 18 15:22:38 2010 -0600 +++ b/debuggercdi/com.nokia.carbide.cpp.debug.crashdebugger/html/DebuggingInformation/CrashDebugger_cmd_f.guide.html Thu Feb 18 15:23:36 2010 -0600 @@ -1,41 +1,41 @@ - - -f - Display Kernel Fault -Information
-This command displays information about the the kernel fault that -caused the debugger to be entered. The information has the following -format.
-Fault Category: Exception Fault Reason: 10000000
- ExcId 00000001 CodeAddr ffe0016c DataAddr 80000001 Extra 00000013
Exc 1 Cpsr=68000010 FAR=80000001 FSR=00000013
R0=00000000 R1=00000000 R2=30000000 R3=80000001
R4=00000001 R5=00403d68 R6=00002000 R7=00000000
R8=00000000 R9=00000000 R10=00000000 R11=00403fa0
R12=00403d34 R13=00403d48 R14=500d41e8 R15=ffe0016c
R13Svc=81716000 R14Svc=500480b8 SpsrSvc=20000010
Notes:
--
-
-
-
R15 is the program counter
-
- -
-
R14 is the link register,
-
- -
-
R13 is the stack pointer
-
-
Related concepts
--
-
- Debug Monitor -
Related references
- - - - - + + +f - Display Kernel Fault +Information
+This command displays information about the the kernel fault that +caused the debugger to be entered. The information has the following +format.
+Fault Category: Exception Fault Reason: 10000000
+ ExcId 00000001 CodeAddr ffe0016c DataAddr 80000001 Extra 00000013
Exc 1 Cpsr=68000010 FAR=80000001 FSR=00000013
R0=00000000 R1=00000000 R2=30000000 R3=80000001
R4=00000001 R5=00403d68 R6=00002000 R7=00000000
R8=00000000 R9=00000000 R10=00000000 R11=00403fa0
R12=00403d34 R13=00403d48 R14=500d41e8 R15=ffe0016c
R13Svc=81716000 R14Svc=500480b8 SpsrSvc=20000010
Notes:
+-
+
-
+
R15 is the program counter
+
+ -
+
R14 is the link register,
+
+ -
+
R13 is the stack pointer
+
+
Related concepts
+-
+
- Debug Monitor +
Related references
+ + + + + \ No newline at end of file diff -r bf0a333d965d -r a690706fd137 debuggercdi/com.nokia.carbide.cpp.debug.crashdebugger/html/DebuggingInformation/CrashDebugger_cmd_i.guide.html --- a/debuggercdi/com.nokia.carbide.cpp.debug.crashdebugger/html/DebuggingInformation/CrashDebugger_cmd_i.guide.html Thu Feb 18 15:22:38 2010 -0600 +++ b/debuggercdi/com.nokia.carbide.cpp.debug.crashdebugger/html/DebuggingInformation/CrashDebugger_cmd_i.guide.html Thu Feb 18 15:23:36 2010 -0600 @@ -1,36 +1,36 @@ - - -i - Display Information for the Current -Process and Thread
-This command displays information for the current process and -thread.
-SCHEDULER @80000d98: CurrentThread 8070dd28
- RescheduleNeeded=00 DfcPending=00 KernCSLocked=00000001
DFCS: next 80000ea8 prev 80000ea8
ProcessHandler=5004b040, AddressSpace=8070d7c8
SYSLOCK: HoldingThread 8070dd28 iWaiting 00000000
Extras 0: 8070d7c8 1: 8070d7c8 2: 8070d7c8 3: 00000000
Extras 4: 00000000 5: 00000000 6: 00000000 7: 00000000
Extras 8: 00000000 9: 00000000 A: 00000000 B: 00000000
Extras C: 00000000 D: 00000000 E: 00000000 F: 00000000
The format for the thread is:
-TheCurrentThread=8070da6c
- THREAD at 8070da6c VPTR=50052b50 AccessCount=3 Owner=8070d7c8
Full name crash::Main
Thread MState READY
Default priority 28 WaitLink Priority 28
ExitInfo 3,0,
Flags 80000004, Handles 8070a79c
Superviso81715000 size 1000
User stack base 00402000 size 2000
Id=19, Heap=00600000, Created heap=00600000, Frame=00000000
Trap handler=00000000, ActiveScheduler=00000000, Exception
handler=00000000
TempObj=00000000 TempAlloc=00000000
NThread @ 8070dd28 Pri 28 NState READY
Next=8070dd28 Prev=8070dd28 Att=03 ExcInUserMode=10
HeldFM=80000eb8 WaitFM=00000000 AddrSp=8070d7c8
Time=0 Timeslice=20 ReqCount=0
SuspendCount=0 CsCount=0 CsFunction=00000000
SavedSP=81715d6c
CAR 00000001
DACR 30315507
R13_USR 00000000 R14_USR 81715dc4 SPSR_SVC 81715e10
R4 30303031 R5 30303030 R6 81715dc4 R7 81715e14
R8 81715dac R9 81715da0 R10 50055c88 R11 50055c3c
PC 81715dc0
The format for the process is:
-TheCurrentProcess=8070d7c8
- PROCESS at 8070d7c8 VPTR=50052bc4 AccessCount=5 Owner=00000000
Full name crash
ExitInfo 3,0,
Flags 00040000, Handles 80709c98, Attributes 60010000
DataBssChunk 8070a514, CodeChunk 8070a9a8
DllDataChunk 00000000, Process Lock 8070d90c
NumChunks=2
0: Chunk 8070a514, run 00400000, access count 1
1: Chunk 8070a704, run 00600000, access count 1
Domain -1, DACR 55555507
TheCurrentAddressSpace=8070d7c8
TheCurrentVMProcess=8070d7c8
PROCESS at 8070d7c8 VPTR=50052bc4 AccessCount=5 Owner=00000000
Full name crash
ExitInfo 3,0,
Flags 00040000, Handles 80709c98, Attributes 60010000
DataBssChunk 8070a514, CodeChunk 8070a9a8
DllDataChunk 00000000, Process Lock 8070d90c
NumChunks=2
0: Chunk 8070a514, run 00400000, access count 1
1: Chunk 8070a704, run 00600000, access count 1
Domain -1, DACR 55555507
TheCurrentDataSectionProcess=8070d7c8
TheCompleteDataSectionProcess=8070d7c8
PROCESS at 8070d7c8 VPTR=50052bc4 AccessCount=5 Owner=00000000
Full name crash
ExitInfo 3,0,
Flags 00040000, Handles 80709c98, Attributes 60010000
DataBssChunk 8070a514, CodeChunk 8070a9a8
DllDataChunk 00000000, Process Lock 8070d90c
NumChunks=2
0: Chunk 8070a514, run 00400000, access count 1
1: Chunk 8070a704, run 00600000, access count 1
Domain -1, DACR 55555507
Related concepts
--
-
- Debug Monitor -
Related references
- - - - - + + +i - Display Information for the Current +Process and Thread
+This command displays information for the current process and +thread.
+SCHEDULER @80000d98: CurrentThread 8070dd28
+ RescheduleNeeded=00 DfcPending=00 KernCSLocked=00000001
DFCS: next 80000ea8 prev 80000ea8
ProcessHandler=5004b040, AddressSpace=8070d7c8
SYSLOCK: HoldingThread 8070dd28 iWaiting 00000000
Extras 0: 8070d7c8 1: 8070d7c8 2: 8070d7c8 3: 00000000
Extras 4: 00000000 5: 00000000 6: 00000000 7: 00000000
Extras 8: 00000000 9: 00000000 A: 00000000 B: 00000000
Extras C: 00000000 D: 00000000 E: 00000000 F: 00000000
The format for the thread is:
+TheCurrentThread=8070da6c
+ THREAD at 8070da6c VPTR=50052b50 AccessCount=3 Owner=8070d7c8
Full name crash::Main
Thread MState READY
Default priority 28 WaitLink Priority 28
ExitInfo 3,0,
Flags 80000004, Handles 8070a79c
Superviso81715000 size 1000
User stack base 00402000 size 2000
Id=19, Heap=00600000, Created heap=00600000, Frame=00000000
Trap handler=00000000, ActiveScheduler=00000000, Exception
handler=00000000
TempObj=00000000 TempAlloc=00000000
NThread @ 8070dd28 Pri 28 NState READY
Next=8070dd28 Prev=8070dd28 Att=03 ExcInUserMode=10
HeldFM=80000eb8 WaitFM=00000000 AddrSp=8070d7c8
Time=0 Timeslice=20 ReqCount=0
SuspendCount=0 CsCount=0 CsFunction=00000000
SavedSP=81715d6c
CAR 00000001
DACR 30315507
R13_USR 00000000 R14_USR 81715dc4 SPSR_SVC 81715e10
R4 30303031 R5 30303030 R6 81715dc4 R7 81715e14
R8 81715dac R9 81715da0 R10 50055c88 R11 50055c3c
PC 81715dc0
The format for the process is:
+TheCurrentProcess=8070d7c8
+ PROCESS at 8070d7c8 VPTR=50052bc4 AccessCount=5 Owner=00000000
Full name crash
ExitInfo 3,0,
Flags 00040000, Handles 80709c98, Attributes 60010000
DataBssChunk 8070a514, CodeChunk 8070a9a8
DllDataChunk 00000000, Process Lock 8070d90c
NumChunks=2
0: Chunk 8070a514, run 00400000, access count 1
1: Chunk 8070a704, run 00600000, access count 1
Domain -1, DACR 55555507
TheCurrentAddressSpace=8070d7c8
TheCurrentVMProcess=8070d7c8
PROCESS at 8070d7c8 VPTR=50052bc4 AccessCount=5 Owner=00000000
Full name crash
ExitInfo 3,0,
Flags 00040000, Handles 80709c98, Attributes 60010000
DataBssChunk 8070a514, CodeChunk 8070a9a8
DllDataChunk 00000000, Process Lock 8070d90c
NumChunks=2
0: Chunk 8070a514, run 00400000, access count 1
1: Chunk 8070a704, run 00600000, access count 1
Domain -1, DACR 55555507
TheCurrentDataSectionProcess=8070d7c8
TheCompleteDataSectionProcess=8070d7c8
PROCESS at 8070d7c8 VPTR=50052bc4 AccessCount=5 Owner=00000000
Full name crash
ExitInfo 3,0,
Flags 00040000, Handles 80709c98, Attributes 60010000
DataBssChunk 8070a514, CodeChunk 8070a9a8
DllDataChunk 00000000, Process Lock 8070d90c
NumChunks=2
0: Chunk 8070a514, run 00400000, access count 1
1: Chunk 8070a704, run 00600000, access count 1
Domain -1, DACR 55555507
Related concepts
+-
+
- Debug Monitor +
Related references
+ + + + + \ No newline at end of file diff -r bf0a333d965d -r a690706fd137 debuggercdi/com.nokia.carbide.cpp.debug.crashdebugger/html/DebuggingInformation/CrashDebugger_cmd_m.guide.html --- a/debuggercdi/com.nokia.carbide.cpp.debug.crashdebugger/html/DebuggingInformation/CrashDebugger_cmd_m.guide.html Thu Feb 18 15:22:38 2010 -0600 +++ b/debuggercdi/com.nokia.carbide.cpp.debug.crashdebugger/html/DebuggingInformation/CrashDebugger_cmd_m.guide.html Thu Feb 18 15:23:36 2010 -0600 @@ -1,42 +1,42 @@ - - -m - Do a Memory Dump
-This command dumps memory in both hexadecimal and ASCII format. Use -one of the following command formats:
-m start end
-m start+length
--start specifies the start address in hexadecimal, and -end specifies the end address in hexadecimal. If the second -parameter starts with a + character, then the following hexadecimal characters -are interpreted as a length.
-Address parameters are always virtual addresses (the MMU is still -on).
-The resulting format is similar to the EKA1 format.
-For example:
-> .m 81c01c60+30
-81C01C60: 00 00 00 00 15 00 00 10 E0 6A 13 50 01 00 00 80 .........j.P....
- 81C01C70: 30 3B C0 81 34 D9 03 50 00 00 FF FF E8 1C C0 81 0;..4..P........
- 81C01C80: 34 D9 03 50 30 3B C0 81 FC 4A 13 50 E8 1C C0 81 4..P0;...J.P.....
If an illegal memory access occurs, the debugger traps the -exception and displays an error message.
-Related concepts
--
-
- Debug Monitor -
Related references
- - - - - + + +m - Do a Memory Dump
+This command dumps memory in both hexadecimal and ASCII format. Use +one of the following command formats:
+m start end
+m start+length
++start specifies the start address in hexadecimal, and +end specifies the end address in hexadecimal. If the second +parameter starts with a + character, then the following hexadecimal characters +are interpreted as a length.
+Address parameters are always virtual addresses (the MMU is still +on).
+The resulting format is similar to the EKA1 format.
+For example:
+> .m 81c01c60+30
+81C01C60: 00 00 00 00 15 00 00 10 E0 6A 13 50 01 00 00 80 .........j.P....
+ 81C01C70: 30 3B C0 81 34 D9 03 50 00 00 FF FF E8 1C C0 81 0;..4..P........
+ 81C01C80: 34 D9 03 50 30 3B C0 81 FC 4A 13 50 E8 1C C0 81 4..P0;...J.P.....
If an illegal memory access occurs, the debugger traps the +exception and displays an error message.
+Related concepts
+-
+
- Debug Monitor +
Related references
+ + + + + \ No newline at end of file diff -r bf0a333d965d -r a690706fd137 debuggercdi/com.nokia.carbide.cpp.debug.crashdebugger/html/DebuggingInformation/CrashDebugger_cmd_o.guide.html --- a/debuggercdi/com.nokia.carbide.cpp.debug.crashdebugger/html/DebuggingInformation/CrashDebugger_cmd_o.guide.html Thu Feb 18 15:22:38 2010 -0600 +++ b/debuggercdi/com.nokia.carbide.cpp.debug.crashdebugger/html/DebuggingInformation/CrashDebugger_cmd_o.guide.html Thu Feb 18 15:23:36 2010 -0600 @@ -1,32 +1,32 @@ - - -o - Display Brief DObject Information
-This command displays basic information about the DObject. The command has the following syntax:
-o address
-where address specifies the address of the DObject.
-For example:
-> o 6403c170
-THREAD at 6403c170 VPTR=f8046c18 AccessCount=3 Owner=6403bb4c
- Full name crash::Main
Related concepts
--
-
- Debug Monitor -
Related references
- - - - - + + +o - Display Brief DObject Information
+This command displays basic information about the DObject. The command has the following syntax:
+o address
+where address specifies the address of the DObject.
+For example:
+> o 6403c170
+THREAD at 6403c170 VPTR=f8046c18 AccessCount=3 Owner=6403bb4c
+ Full name crash::Main
Related concepts
+-
+
- Debug Monitor +
Related references
+ + + + + \ No newline at end of file diff -r bf0a333d965d -r a690706fd137 debuggercdi/com.nokia.carbide.cpp.debug.crashdebugger/html/DebuggingInformation/CrashDebugger_cmd_q.guide.html --- a/debuggercdi/com.nokia.carbide.cpp.debug.crashdebugger/html/DebuggingInformation/CrashDebugger_cmd_q.guide.html Thu Feb 18 15:22:38 2010 -0600 +++ b/debuggercdi/com.nokia.carbide.cpp.debug.crashdebugger/html/DebuggingInformation/CrashDebugger_cmd_q.guide.html Thu Feb 18 15:23:36 2010 -0600 @@ -1,30 +1,30 @@ - - -q - Display Full DObject Information
-This command displays full information about the DObject. The exact format displayed depends on the exact -type of the DObject being referenced, for example, whether -it is a thread, process, or a chunk. The command has the following -syntax:
-q address
-where address specifies the address of the DObject.
-Related concepts
--
-
- Debug Monitor -
Related references
- - - - + + +q - Display Full DObject Information
+This command displays full information about the DObject. The exact format displayed depends on the exact +type of the DObject being referenced, for example, whether +it is a thread, process, or a chunk. The command has the following +syntax:
+q address
+where address specifies the address of the DObject.
+Related concepts
+-
+
- Debug Monitor +
Related references
+ + + + \ No newline at end of file diff -r bf0a333d965d -r a690706fd137 debuggercdi/com.nokia.carbide.cpp.debug.crashdebugger/html/DebuggingInformation/CrashDebugger_cmd_r.guide.html --- a/debuggercdi/com.nokia.carbide.cpp.debug.crashdebugger/html/DebuggingInformation/CrashDebugger_cmd_r.guide.html Thu Feb 18 15:22:38 2010 -0600 +++ b/debuggercdi/com.nokia.carbide.cpp.debug.crashdebugger/html/DebuggingInformation/CrashDebugger_cmd_r.guide.html Thu Feb 18 15:23:36 2010 -0600 @@ -1,47 +1,47 @@ - - -r - Dump Register Contents
-This command dumps the full ARM register set.
-On ARM this dumps the full set of user mode registers and all the -alternate registers for other modes.
-For example:
-> r
-MODE_USR:
- R0=6571de54 R1=0000002a R2=00000002 R3=ffffffff
- R4=0000002a R5=f8170414 R6=6571df14 R7=6403cba8
- R8=00000001 R9=6403c41c R10=640002f8 R11=6571de70
- R12=00000020 R13=00404e00 R14=f80818c0 R15=f800bfa8
- CPSR=60000013
- MODE_FIQ:
- R8=00000000 R9=ffffffff R10=ffffffff R11=00000000
- R12=00000000 R13=64000d0c R14=c080079c SPSR=e00000dc
- MODE_IRQ:
- R13=6400110c R14=00000013 SPSR=20000013
- MODE_SVC:
- R13=6571de54 R14=f80328bc SPSR=60000010
- MODE_ABT:
- R13=6400090c R14=ffff0010 SPSR=400000d7
- MODE_UND:
- R13=6400090c R14=95221110 SPSR=f000009d
Related concepts
--
-
- Debug Monitor -
Related references
- - - - + + +r - Dump Register Contents
+This command dumps the full ARM register set.
+On ARM this dumps the full set of user mode registers and all the +alternate registers for other modes.
+For example:
+> r
+MODE_USR:
+ R0=6571de54 R1=0000002a R2=00000002 R3=ffffffff
+ R4=0000002a R5=f8170414 R6=6571df14 R7=6403cba8
+ R8=00000001 R9=6403c41c R10=640002f8 R11=6571de70
+ R12=00000020 R13=00404e00 R14=f80818c0 R15=f800bfa8
+ CPSR=60000013
+ MODE_FIQ:
+ R8=00000000 R9=ffffffff R10=ffffffff R11=00000000
+ R12=00000000 R13=64000d0c R14=c080079c SPSR=e00000dc
+ MODE_IRQ:
+ R13=6400110c R14=00000013 SPSR=20000013
+ MODE_SVC:
+ R13=6571de54 R14=f80328bc SPSR=60000010
+ MODE_ABT:
+ R13=6400090c R14=ffff0010 SPSR=400000d7
+ MODE_UND:
+ R13=6400090c R14=95221110 SPSR=f000009d
Related concepts
+-
+
- Debug Monitor +
Related references
+ + + + \ No newline at end of file diff -r bf0a333d965d -r a690706fd137 debuggercdi/com.nokia.carbide.cpp.debug.crashdebugger/html/DebuggingInformation/CrashDebugger_cmd_x.guide.html --- a/debuggercdi/com.nokia.carbide.cpp.debug.crashdebugger/html/DebuggingInformation/CrashDebugger_cmd_x.guide.html Thu Feb 18 15:22:38 2010 -0600 +++ b/debuggercdi/com.nokia.carbide.cpp.debug.crashdebugger/html/DebuggingInformation/CrashDebugger_cmd_x.guide.html Thu Feb 18 15:23:36 2010 -0600 @@ -1,27 +1,27 @@ - - -x - Leave debugger, Cold Restart ROM -Image
-This command, in lower case, leaves the debugger and does a cold -restart of the current ROM image.
-Related concepts
--
-
- Debug Monitor -
Related references
- - - - - + + +x - Leave debugger, Cold Restart ROM +Image
+This command, in lower case, leaves the debugger and does a cold +restart of the current ROM image.
+Related concepts
+-
+
- Debug Monitor +
Related references
+ + + + + \ No newline at end of file diff -r bf0a333d965d -r a690706fd137 debuggercdi/com.nokia.carbide.cpp.debug.crashdebugger/html/DebuggingInformation/CrashDebugger_cmd_z.guide.html --- a/debuggercdi/com.nokia.carbide.cpp.debug.crashdebugger/html/DebuggingInformation/CrashDebugger_cmd_z.guide.html Thu Feb 18 15:22:38 2010 -0600 +++ b/debuggercdi/com.nokia.carbide.cpp.debug.crashdebugger/html/DebuggingInformation/CrashDebugger_cmd_z.guide.html Thu Feb 18 15:23:36 2010 -0600 @@ -1,30 +1,30 @@ - - -z - Do a Memory Dump, Skipping over -Unmapped Memory
-This command dumps memory in both hexadecimal and ASCII format, but -excludes any unmapped memory space. If an illegal memory access occurs, it does -not stop, but skips to the next page instead. This is useful to inspect the -content of discontiguous chunks.
-The syntax and the display format is the same as for the -m command.
-Related concepts
--
-
- Debug Monitor -
Related references
- - - - - + + +z - Do a Memory Dump, Skipping over +Unmapped Memory
+This command dumps memory in both hexadecimal and ASCII format, but +excludes any unmapped memory space. If an illegal memory access occurs, it does +not stop, but skips to the next page instead. This is useful to inspect the +content of discontiguous chunks.
+The syntax and the display format is the same as for the +m command.
+Related concepts
+-
+
- Debug Monitor +
Related references
+ + + + + \ No newline at end of file diff -r bf0a333d965d -r a690706fd137 debuggercdi/com.nokia.carbide.cpp.debug.crashdebugger/html/DebuggingInformation/index.html --- a/debuggercdi/com.nokia.carbide.cpp.debug.crashdebugger/html/DebuggingInformation/index.html Thu Feb 18 15:22:38 2010 -0600 +++ b/debuggercdi/com.nokia.carbide.cpp.debug.crashdebugger/html/DebuggingInformation/index.html Thu Feb 18 15:23:36 2010 -0600 @@ -1,29 +1,29 @@ - - -Debugging Information
-The following topics describe the capabilites of the Crash Debugger:
--
-
- The debug monitor and command syntax -
- Finding the type of fault -
- Extracting information about the kernel -
- Examining memory -
- Examining kernel objects and containers -
- Examining the call stack -
- Using the MAKSYM tool -
- Symbian OS memory map -
- Process, thread, stack and memory useful information -
- ARM Exception types, fault status register values, processor modes -
Debugging Information
+The following topics describe the capabilites of the Crash Debugger:
+-
+
- The debug monitor and command syntax +
- Finding the type of fault +
- Extracting information about the kernel +
- Examining memory +
- Examining kernel objects and containers +
- Examining the call stack +
- Using the MAKSYM tool +
- Symbian OS memory map +
- Process, thread, stack and memory useful information +
- ARM Exception types, fault status register values, processor modes +
Debug Monitor
-The debug monitor is entered when the kernel crashes, if a system -process panics, or an unhandled processor exception occurs. Under normal -circumstances this ought not to happen, but when the kernel faults, the device -enters the kernel debug monitor.
-There may be circumstances where you need to force a kernel crash, -for example, if the system is locking up. Running the test program -crash.exe forces a crash. This program takes a parameter that -defines the number of seconds that must elapse before the kernel crash is -forced.
-For example, when the system locks up under certain conditions, run -"crash 60", and then recreate the conditions that lead to the lockup. After 60 -seconds, the kernel crash is forced and the debug monitor is entered.
-Notes:
--
-
-
-
the EKA2 debug monitor is very similar to the EKA1 version, -although the details displayed may be different.
-
- -
-
you will occasionally find references to the crash -debugger; this is the same as the debug monitor.
-
-
Commands consist of a single letter describing the operation to be -performed, followed by any arguments. Not all commands take arguments. Commands -are case sensitive; the majority are lower case. Commands should be entered at -the command prompt, on the PC. The set of supported commands is as -follows:
--
-
-
-
x - -leaves the debugger, does a cold restart of the same ROM image; (nb lower case)
-
- - - - -
- - - -
-
-
m - -does a memory dump
-
- -
-
z - -does a memory dump, but skips over unmapped memory space
-
- -
-
i - -displays information on the current thread and the current process
-
- - - - -
- - - -
- - - -
- - - -
-
-
r - -dumps register contents.
-
-
-
x - leave debugger, cold restart of ROM -image
-This command, in lower case, leaves the debugger and does a cold -restart of the current ROM image.
--
X - leave debugger, return to -bootloader
-This command, in upper case, leaves the debugger, and returns to -the bootloader to wait for a new ROM image to be downloaded.
--
f - display kernel fault -information
-This command displays information about the the kernel fault that -caused the debugger to be entered. The information has the following -format.
-Fault Category: Exception Fault Reason: 10000000
- ExcId 00000001 CodeAddr ffe0016c DataAddr 80000001 Extra 00000013
Exc 1 Cpsr=68000010 FAR=80000001 FSR=00000013
R0=00000000 R1=00000000 R2=30000000 R3=80000001
R4=00000001 R5=00403d68 R6=00002000 R7=00000000
R8=00000000 R9=00000000 R10=00000000 R11=00403fa0
R12=00403d34 R13=00403d48 R14=500d41e8 R15=ffe0016c
R13Svc=81716000 R14Svc=500480b8 SpsrSvc=20000010
Notes:
--
-
-
-
R15 is the program counter
-
- -
-
R14 is the link register,
-
- -
-
R13 is the stack pointer
-
-
-
m - do a memory dump
-This command dumps memory in both hexadecimal and ASCII format. Use -one of the following command formats:
-m start end
-m start+length
--start specifies the start address in hexadecimal, and -end specifies the end address in hexadecimal. If the second -parameter starts with a + character, then the following hexadecimal characters -are interpreted as a length.
-Address parameters are always virtual addresses (the MMU is still -on).
-The resulting format is similar to the EKA1 format.
-For example:
-> .m 81c01c60+30
-81C01C60: 00 00 00 00 15 00 00 10 E0 6A 13 50 01 00 00 80 .........j.P....
- 81C01C70: 30 3B C0 81 34 D9 03 50 00 00 FF FF E8 1C C0 81 0;..4..P........
- 81C01C80: 34 D9 03 50 30 3B C0 81 FC 4A 13 50 E8 1C C0 81 4..P0;...J.P.....
If an illegal memory access occurs, the debugger traps the -exception and displays an error message.
--
z - do a memory dump, skipping over -unmapped memory
-This command dumps memory in both hexadecimal and ASCII format, but -excludes any unmapped memory space. If an illegal memory access occurs, it does -not stop, but skips to the next page instead. This is useful to inspect the -content of discontiguous chunks.
-The syntax and the display format is the same as for the -m command.
--
i - display information for the current -process and thread
-This command displays information for the current process and -thread.
-SCHEDULER @80000d98: CurrentThread 8070dd28
- RescheduleNeeded=00 DfcPending=00 KernCSLocked=00000001
DFCS: next 80000ea8 prev 80000ea8
ProcessHandler=5004b040, AddressSpace=8070d7c8
SYSLOCK: HoldingThread 8070dd28 iWaiting 00000000
Extras 0: 8070d7c8 1: 8070d7c8 2: 8070d7c8 3: 00000000
Extras 4: 00000000 5: 00000000 6: 00000000 7: 00000000
Extras 8: 00000000 9: 00000000 A: 00000000 B: 00000000
Extras C: 00000000 D: 00000000 E: 00000000 F: 00000000
The format for the thread is:
-TheCurrentThread=8070da6c
- THREAD at 8070da6c VPTR=50052b50 AccessCount=3 Owner=8070d7c8
Full name crash::Main
Thread MState READY
Default priority 28 WaitLink Priority 28
ExitInfo 3,0,
Flags 80000004, Handles 8070a79c
Superviso81715000 size 1000
User stack base 00402000 size 2000
Id=19, Heap=00600000, Created heap=00600000, Frame=00000000
Trap handler=00000000, ActiveScheduler=00000000, Exception
handler=00000000
TempObj=00000000 TempAlloc=00000000
NThread @ 8070dd28 Pri 28 NState READY
Next=8070dd28 Prev=8070dd28 Att=03 ExcInUserMode=10
HeldFM=80000eb8 WaitFM=00000000 AddrSp=8070d7c8
Time=0 Timeslice=20 ReqCount=0
SuspendCount=0 CsCount=0 CsFunction=00000000
SavedSP=81715d6c
CAR 00000001
DACR 30315507
R13_USR 00000000 R14_USR 81715dc4 SPSR_SVC 81715e10
R4 30303031 R5 30303030 R6 81715dc4 R7 81715e14
R8 81715dac R9 81715da0 R10 50055c88 R11 50055c3c
PC 81715dc0
The format for the process is:
-TheCurrentProcess=8070d7c8
- PROCESS at 8070d7c8 VPTR=50052bc4 AccessCount=5 Owner=00000000
Full name crash
ExitInfo 3,0,
Flags 00040000, Handles 80709c98, Attributes 60010000
DataBssChunk 8070a514, CodeChunk 8070a9a8
DllDataChunk 00000000, Process Lock 8070d90c
NumChunks=2
0: Chunk 8070a514, run 00400000, access count 1
1: Chunk 8070a704, run 00600000, access count 1
Domain -1, DACR 55555507
TheCurrentAddressSpace=8070d7c8
TheCurrentVMProcess=8070d7c8
PROCESS at 8070d7c8 VPTR=50052bc4 AccessCount=5 Owner=00000000
Full name crash
ExitInfo 3,0,
Flags 00040000, Handles 80709c98, Attributes 60010000
DataBssChunk 8070a514, CodeChunk 8070a9a8
DllDataChunk 00000000, Process Lock 8070d90c
NumChunks=2
0: Chunk 8070a514, run 00400000, access count 1
1: Chunk 8070a704, run 00600000, access count 1
Domain -1, DACR 55555507
TheCurrentDataSectionProcess=8070d7c8
TheCompleteDataSectionProcess=8070d7c8
PROCESS at 8070d7c8 VPTR=50052bc4 AccessCount=5 Owner=00000000
Full name crash
ExitInfo 3,0,
Flags 00040000, Handles 80709c98, Attributes 60010000
DataBssChunk 8070a514, CodeChunk 8070a9a8
DllDataChunk 00000000, Process Lock 8070d90c
NumChunks=2
0: Chunk 8070a514, run 00400000, access count 1
1: Chunk 8070a704, run 00600000, access count 1
Domain -1, DACR 55555507
-
o - display brief DObject information
-This command displays basic information about the DObject. The command has the following syntax:
-o address
-where address specifies the address of the DObject.
-For example:
-> o 6403c170
-THREAD at 6403c170 VPTR=f8046c18 AccessCount=3 Owner=6403bb4c
- Full name crash::Main
-
q - display full DObject information
-This command displays full information about the DObject. The exact format displayed depends on the exact -type of the DObject being referenced, for example, whether -it is a thread, process, or a chunk. The command has the following -syntax:
-q address
-where address specifies the address of the DObject.
--
c - display contents of object -container
-This command displays the contents of one of the kernel's object -containers, a DObjectCon type. Note that information is dumped -very quickly without page breaks, which is useful in situations where the -kernel is likely to become very unstable very shortly after crashing. There is -an upper case version of this command, -C, which generates -output with a pause between pages.
-The command has the following syntax:
-c type
-where type is a single hexadecimal digit between 0 and -D inclusive that specifies which kernel container is to be dumped. The mapping -between the hexadecimal digit and the kernel container is:
-
|
For example:
-> c A
-Container 10 at 640275c4 contains 3 PHYSICAL DEVICES:
- PHYSICAL DEVICE at 64032dac VPTR=f805d9fc AccessCount=2 Owner=00000000
- Full name Media.IRam
- PHYSICAL DEVICE at 640339e8 VPTR=f8067e44 AccessCount=2 Owner=00000000
- Full name Media.Flash
- PHYSICAL DEVICE at 64033a64 VPTR=f806b9f8 AccessCount=2 Owner=00000000
- Full name Media.Ata
> c 0
-Container 0 at 807022b8 contains 12 THREADS:
- THREAD at 807011c0 VPTR=50052b04 AccessCount=1 Owner=8070107c
- Full name EKern::Null
- Thread MState READY
- Default priority 0 WaitLink Priority 0
- ExitInfo 3,0,
- Flags 0000000c, Handles 80701520
- Supervisor stack base 80700000 size 1000
- User stack base 00000000 size 0
- Id=0, Heap=00000000, Created heap=00000000, Frame=00000000
- Trap handler=00000000, ActiveScheduler=00000000, Exception
- handler=00000000
- TempObj=00000000 TempAlloc=00000000
- NThread @ 8070147c Pri 0 NState READY
- Next=8070147c Prev=8070147c Att=00 ExcInUserMode=00
- HeldFM=00000000 WaitFM=00000000 AddrSp=8070107c
- Time=-1 Timeslice=-1 ReqCount=0
- SuspendCount=0 CsCount=0 CsFunction=00000000
- SavedSP=80700f50
- CAR 00000001
- DACR 55555547
- R13_USR 00403ed4 R14_USR 500c88b4 SPSR_SVC 200000d3
- R4 00000009 R5 5004b7ec R6 50000000 R7 dc911000
- R8 00000000 R9 807103c0 R10 50002140 R11 80700fb4
- PC 500481b4
The information displayed for each object is the same as that shown -after using the q -command. After displaying the information for each object, the debugger pauses -until you press a key.
-Notes
--
-
-
-
the DObjectCon class is internal to Symbian -OS.
-
- -
-
the type value passed as an argument to the command is one of -the enum values of the TObjectType enum; this enum is internal to -Symbian OS.
-
-
-
C - display contents of object -container
-This is exactly the same as the lower case -c command except -that the display of output pauses between pages. If you need to dump output as -fast as possible without pauses, use the lower case version.
--
r - dump register contents
-This command dumps the full ARM register set.
-On ARM this dumps the full set of user mode registers and all the -alternate registers for other modes.
-For example:
-> r
-MODE_USR:
- R0=6571de54 R1=0000002a R2=00000002 R3=ffffffff
- R4=0000002a R5=f8170414 R6=6571df14 R7=6403cba8
- R8=00000001 R9=6403c41c R10=640002f8 R11=6571de70
- R12=00000020 R13=00404e00 R14=f80818c0 R15=f800bfa8
- CPSR=60000013
- MODE_FIQ:
- R8=00000000 R9=ffffffff R10=ffffffff R11=00000000
- R12=00000000 R13=64000d0c R14=c080079c SPSR=e00000dc
- MODE_IRQ:
- R13=6400110c R14=00000013 SPSR=20000013
- MODE_SVC:
- R13=6571de54 R14=f80328bc SPSR=60000010
- MODE_ABT:
- R13=6400090c R14=ffff0010 SPSR=400000d7
- MODE_UND:
- R13=6400090c R14=95221110 SPSR=f000009d
Debug Monitor
+The debug monitor is entered when the kernel crashes, if a system +process panics, or an unhandled processor exception occurs. Under normal +circumstances this ought not to happen, but when the kernel faults, the device +enters the kernel debug monitor.
+There may be circumstances where you need to force a kernel crash, +for example, if the system is locking up. Running the test program +crash.exe forces a crash. This program takes a parameter that +defines the number of seconds that must elapse before the kernel crash is +forced.
+For example, when the system locks up under certain conditions, run +"crash 60", and then recreate the conditions that lead to the lockup. After 60 +seconds, the kernel crash is forced and the debug monitor is entered.
+Notes:
+-
+
-
+
the EKA2 debug monitor is very similar to the EKA1 version, +although the details displayed may be different.
+
+ -
+
you will occasionally find references to the crash +debugger; this is the same as the debug monitor.
+
+
Commands consist of a single letter describing the operation to be +performed, followed by any arguments. Not all commands take arguments. Commands +are case sensitive; the majority are lower case. Commands should be entered at +the command prompt, on the PC. The set of supported commands is as +follows:
+-
+
-
+
x - +leaves the debugger, does a cold restart of the same ROM image; (nb lower case)
+
+ - + + +
- + + +
-
+
m - +does a memory dump
+
+ -
+
z - +does a memory dump, but skips over unmapped memory space
+
+ -
+
i - +displays information on the current thread and the current process
+
+ - + + +
- + + +
- + + +
- + + +
-
+
r - +dumps register contents.
+
+
+
x - leave debugger, cold restart of ROM +image
+This command, in lower case, leaves the debugger and does a cold +restart of the current ROM image.
++
X - leave debugger, return to +bootloader
+This command, in upper case, leaves the debugger, and returns to +the bootloader to wait for a new ROM image to be downloaded.
++
f - display kernel fault +information
+This command displays information about the the kernel fault that +caused the debugger to be entered. The information has the following +format.
+Fault Category: Exception Fault Reason: 10000000
+ ExcId 00000001 CodeAddr ffe0016c DataAddr 80000001 Extra 00000013
Exc 1 Cpsr=68000010 FAR=80000001 FSR=00000013
R0=00000000 R1=00000000 R2=30000000 R3=80000001
R4=00000001 R5=00403d68 R6=00002000 R7=00000000
R8=00000000 R9=00000000 R10=00000000 R11=00403fa0
R12=00403d34 R13=00403d48 R14=500d41e8 R15=ffe0016c
R13Svc=81716000 R14Svc=500480b8 SpsrSvc=20000010
Notes:
+-
+
-
+
R15 is the program counter
+
+ -
+
R14 is the link register,
+
+ -
+
R13 is the stack pointer
+
+
+
m - do a memory dump
+This command dumps memory in both hexadecimal and ASCII format. Use +one of the following command formats:
+m start end
+m start+length
++start specifies the start address in hexadecimal, and +end specifies the end address in hexadecimal. If the second +parameter starts with a + character, then the following hexadecimal characters +are interpreted as a length.
+Address parameters are always virtual addresses (the MMU is still +on).
+The resulting format is similar to the EKA1 format.
+For example:
+> .m 81c01c60+30
+81C01C60: 00 00 00 00 15 00 00 10 E0 6A 13 50 01 00 00 80 .........j.P....
+ 81C01C70: 30 3B C0 81 34 D9 03 50 00 00 FF FF E8 1C C0 81 0;..4..P........
+ 81C01C80: 34 D9 03 50 30 3B C0 81 FC 4A 13 50 E8 1C C0 81 4..P0;...J.P.....
If an illegal memory access occurs, the debugger traps the +exception and displays an error message.
++
z - do a memory dump, skipping over +unmapped memory
+This command dumps memory in both hexadecimal and ASCII format, but +excludes any unmapped memory space. If an illegal memory access occurs, it does +not stop, but skips to the next page instead. This is useful to inspect the +content of discontiguous chunks.
+The syntax and the display format is the same as for the +m command.
++
i - display information for the current +process and thread
+This command displays information for the current process and +thread.
+SCHEDULER @80000d98: CurrentThread 8070dd28
+ RescheduleNeeded=00 DfcPending=00 KernCSLocked=00000001
DFCS: next 80000ea8 prev 80000ea8
ProcessHandler=5004b040, AddressSpace=8070d7c8
SYSLOCK: HoldingThread 8070dd28 iWaiting 00000000
Extras 0: 8070d7c8 1: 8070d7c8 2: 8070d7c8 3: 00000000
Extras 4: 00000000 5: 00000000 6: 00000000 7: 00000000
Extras 8: 00000000 9: 00000000 A: 00000000 B: 00000000
Extras C: 00000000 D: 00000000 E: 00000000 F: 00000000
The format for the thread is:
+TheCurrentThread=8070da6c
+ THREAD at 8070da6c VPTR=50052b50 AccessCount=3 Owner=8070d7c8
Full name crash::Main
Thread MState READY
Default priority 28 WaitLink Priority 28
ExitInfo 3,0,
Flags 80000004, Handles 8070a79c
Superviso81715000 size 1000
User stack base 00402000 size 2000
Id=19, Heap=00600000, Created heap=00600000, Frame=00000000
Trap handler=00000000, ActiveScheduler=00000000, Exception
handler=00000000
TempObj=00000000 TempAlloc=00000000
NThread @ 8070dd28 Pri 28 NState READY
Next=8070dd28 Prev=8070dd28 Att=03 ExcInUserMode=10
HeldFM=80000eb8 WaitFM=00000000 AddrSp=8070d7c8
Time=0 Timeslice=20 ReqCount=0
SuspendCount=0 CsCount=0 CsFunction=00000000
SavedSP=81715d6c
CAR 00000001
DACR 30315507
R13_USR 00000000 R14_USR 81715dc4 SPSR_SVC 81715e10
R4 30303031 R5 30303030 R6 81715dc4 R7 81715e14
R8 81715dac R9 81715da0 R10 50055c88 R11 50055c3c
PC 81715dc0
The format for the process is:
+TheCurrentProcess=8070d7c8
+ PROCESS at 8070d7c8 VPTR=50052bc4 AccessCount=5 Owner=00000000
Full name crash
ExitInfo 3,0,
Flags 00040000, Handles 80709c98, Attributes 60010000
DataBssChunk 8070a514, CodeChunk 8070a9a8
DllDataChunk 00000000, Process Lock 8070d90c
NumChunks=2
0: Chunk 8070a514, run 00400000, access count 1
1: Chunk 8070a704, run 00600000, access count 1
Domain -1, DACR 55555507
TheCurrentAddressSpace=8070d7c8
TheCurrentVMProcess=8070d7c8
PROCESS at 8070d7c8 VPTR=50052bc4 AccessCount=5 Owner=00000000
Full name crash
ExitInfo 3,0,
Flags 00040000, Handles 80709c98, Attributes 60010000
DataBssChunk 8070a514, CodeChunk 8070a9a8
DllDataChunk 00000000, Process Lock 8070d90c
NumChunks=2
0: Chunk 8070a514, run 00400000, access count 1
1: Chunk 8070a704, run 00600000, access count 1
Domain -1, DACR 55555507
TheCurrentDataSectionProcess=8070d7c8
TheCompleteDataSectionProcess=8070d7c8
PROCESS at 8070d7c8 VPTR=50052bc4 AccessCount=5 Owner=00000000
Full name crash
ExitInfo 3,0,
Flags 00040000, Handles 80709c98, Attributes 60010000
DataBssChunk 8070a514, CodeChunk 8070a9a8
DllDataChunk 00000000, Process Lock 8070d90c
NumChunks=2
0: Chunk 8070a514, run 00400000, access count 1
1: Chunk 8070a704, run 00600000, access count 1
Domain -1, DACR 55555507
+
o - display brief DObject information
+This command displays basic information about the DObject. The command has the following syntax:
+o address
+where address specifies the address of the DObject.
+For example:
+> o 6403c170
+THREAD at 6403c170 VPTR=f8046c18 AccessCount=3 Owner=6403bb4c
+ Full name crash::Main
+
q - display full DObject information
+This command displays full information about the DObject. The exact format displayed depends on the exact +type of the DObject being referenced, for example, whether +it is a thread, process, or a chunk. The command has the following +syntax:
+q address
+where address specifies the address of the DObject.
++
c - display contents of object +container
+This command displays the contents of one of the kernel's object +containers, a DObjectCon type. Note that information is dumped +very quickly without page breaks, which is useful in situations where the +kernel is likely to become very unstable very shortly after crashing. There is +an upper case version of this command, +C, which generates +output with a pause between pages.
+The command has the following syntax:
+c type
+where type is a single hexadecimal digit between 0 and +D inclusive that specifies which kernel container is to be dumped. The mapping +between the hexadecimal digit and the kernel container is:
+
|
For example:
+> c A
+Container 10 at 640275c4 contains 3 PHYSICAL DEVICES:
+ PHYSICAL DEVICE at 64032dac VPTR=f805d9fc AccessCount=2 Owner=00000000
+ Full name Media.IRam
+ PHYSICAL DEVICE at 640339e8 VPTR=f8067e44 AccessCount=2 Owner=00000000
+ Full name Media.Flash
+ PHYSICAL DEVICE at 64033a64 VPTR=f806b9f8 AccessCount=2 Owner=00000000
+ Full name Media.Ata
> c 0
+Container 0 at 807022b8 contains 12 THREADS:
+ THREAD at 807011c0 VPTR=50052b04 AccessCount=1 Owner=8070107c
+ Full name EKern::Null
+ Thread MState READY
+ Default priority 0 WaitLink Priority 0
+ ExitInfo 3,0,
+ Flags 0000000c, Handles 80701520
+ Supervisor stack base 80700000 size 1000
+ User stack base 00000000 size 0
+ Id=0, Heap=00000000, Created heap=00000000, Frame=00000000
+ Trap handler=00000000, ActiveScheduler=00000000, Exception
+ handler=00000000
+ TempObj=00000000 TempAlloc=00000000
+ NThread @ 8070147c Pri 0 NState READY
+ Next=8070147c Prev=8070147c Att=00 ExcInUserMode=00
+ HeldFM=00000000 WaitFM=00000000 AddrSp=8070107c
+ Time=-1 Timeslice=-1 ReqCount=0
+ SuspendCount=0 CsCount=0 CsFunction=00000000
+ SavedSP=80700f50
+ CAR 00000001
+ DACR 55555547
+ R13_USR 00403ed4 R14_USR 500c88b4 SPSR_SVC 200000d3
+ R4 00000009 R5 5004b7ec R6 50000000 R7 dc911000
+ R8 00000000 R9 807103c0 R10 50002140 R11 80700fb4
+ PC 500481b4
The information displayed for each object is the same as that shown +after using the q +command. After displaying the information for each object, the debugger pauses +until you press a key.
+Notes
+-
+
-
+
the DObjectCon class is internal to Symbian +OS.
+
+ -
+
the type value passed as an argument to the command is one of +the enum values of the TObjectType enum; this enum is internal to +Symbian OS.
+
+
+
C - display contents of object +container
+This is exactly the same as the lower case +c command except +that the display of output pauses between pages. If you need to dump output as +fast as possible without pauses, use the lower case version.
++
r - dump register contents
+This command dumps the full ARM register set.
+On ARM this dumps the full set of user mode registers and all the +alternate registers for other modes.
+For example:
+> r
+MODE_USR:
+ R0=6571de54 R1=0000002a R2=00000002 R3=ffffffff
+ R4=0000002a R5=f8170414 R6=6571df14 R7=6403cba8
+ R8=00000001 R9=6403c41c R10=640002f8 R11=6571de70
+ R12=00000020 R13=00404e00 R14=f80818c0 R15=f800bfa8
+ CPSR=60000013
+ MODE_FIQ:
+ R8=00000000 R9=ffffffff R10=ffffffff R11=00000000
+ R12=00000000 R13=64000d0c R14=c080079c SPSR=e00000dc
+ MODE_IRQ:
+ R13=6400110c R14=00000013 SPSR=20000013
+ MODE_SVC:
+ R13=6571de54 R14=f80328bc SPSR=60000010
+ MODE_ABT:
+ R13=6400090c R14=ffff0010 SPSR=400000d7
+ MODE_UND:
+ R13=6400090c R14=95221110 SPSR=f000009d
Object Address
-Use the Object Address window to specify the object's starting address to display brief or full object information in the Crash Debugger Console view.
-
Figure 1 - Object Address window
-Displaying Object Information
--
-
- Enter an object information command or right-click in the Crash Debugger Console view and select an object information command -
- Enter the starting address in hexadecimal into the Address text box -
- Click OK
-The Object Address window closes and the specified object information appears in the Crash Debugger Console view.
-
The Object Address window appears.
-Related concepts
- -Related references
- - - - + + + + +Object Address
+Use the Object Address window to specify the object's starting address to display brief or full object information in the Crash Debugger Console view.
+
Figure 1 - Object Address window
+Displaying Object Information
+-
+
- Enter an object information command or right-click in the Crash Debugger Console view and select an object information command +
- Enter the starting address in hexadecimal into the Address text box +
- Click OK
+The Object Address window closes and the specified object information appears in the Crash Debugger Console view.
+
The Object Address window appears.
+Related concepts
+ +Related references
+ + + + diff -r bf0a333d965d -r a690706fd137 debuggercdi/com.nokia.carbide.cpp.debug.crashdebugger/html/crash_launch_config.html --- a/debuggercdi/com.nokia.carbide.cpp.debug.crashdebugger/html/crash_launch_config.html Thu Feb 18 15:22:38 2010 -0600 +++ b/debuggercdi/com.nokia.carbide.cpp.debug.crashdebugger/html/crash_launch_config.html Thu Feb 18 15:23:36 2010 -0600 @@ -1,28 +1,28 @@ - - - - -Symbian OS Crash Debugger Launch Configuration
-Use the Run or Debug window to define a launch configuration for the crash debugger. Select Run > Open Run Dialog... to open the Run window. Select Run > Open Debug Dialog... to open the Debug window (Figure 1). Select Symbian OS Crash Debugger and click the New launch configuration icon. In the Name field enter a unique name for your launch configuration. Specify your connection information and select the ROM Log tab (figure 2).
-
Figure 1 - Connection Tab
-In the ROM Log pane specify a ROM log file that was generated when building the rom image. The ROM log file is necessary for finding out the address for each module in the rom log file. Specify the Symbian OS kit Epoc32 directory to resolve the full paths for the various modules in the rom log file. By specifying the rom log file and epoc32 path you will be able to view source code (figure 3) for the crash debug session.
-
Figure 2 - ROM Log Tab
-
Figure 3 - Crash Debug Source Code
-Related concepts
--
-
- Debug Monitor -
Related references
- - - - + + + + +Symbian OS Crash Debugger Launch Configuration
+Use the Run or Debug window to define a launch configuration for the crash debugger. Select Run > Run As to open the Run window. Select Run > Dialog As to open the Debug window (Figure 1). Select Symbian OS Crash Debugger and click the New launch configuration icon. In the Name field enter a unique name for your launch configuration. Specify your connection information and select the ROM Log tab (figure 2).
+
Figure 1 - Connection Tab
+In the ROM Log pane specify a ROM log file that was generated when building the rom image. The ROM log file is necessary for finding out the address for each module in the rom log file. Specify the Symbian OS kit Epoc32 directory to resolve the full paths for the various modules in the rom log file. By specifying the rom log file and epoc32 path you will be able to view source code (figure 3) for the crash debug session.
+
Figure 2 - ROM Log Tab
+
Figure 3 - Crash Debug Source Code
+Related concepts
+-
+
- Debug Monitor +
Related references
+ + + + diff -r bf0a333d965d -r a690706fd137 debuggercdi/com.nokia.carbide.cpp.debug.crashdebugger/html/memory.html --- a/debuggercdi/com.nokia.carbide.cpp.debug.crashdebugger/html/memory.html Thu Feb 18 15:22:38 2010 -0600 +++ b/debuggercdi/com.nokia.carbide.cpp.debug.crashdebugger/html/memory.html Thu Feb 18 15:23:36 2010 -0600 @@ -1,36 +1,36 @@ - - - - -Memory Dump Options
-Use the Memory Dump Options window to specify the starting address and length of memory data to display in the Crash Debugger Console view.
-
Figure 1 - Memory Dump Options window
-Displaying Memory Data
--
-
- Enter a memory dump command or right-click in the Crash Debugger Console view and select a memory dump command -
- Enter the starting address in hexadecimal into the Address text box -
- Enter the length of the memory space to display into the Length (Hexadecimal) text box -
- Click OK -
The Memory Dump Options window appears.
-The Memory Dump Options window closes and the specified memory data appears in the Crash Debugger Console view.
-Related concepts
- -Related references
- - - - + + + + +Memory Dump Options
+Use the Memory Dump Options window to specify the starting address and length of memory data to display in the Crash Debugger Console view.
+
Figure 1 - Memory Dump Options window
+Displaying Memory Data
+-
+
- Enter a memory dump command or right-click in the Crash Debugger Console view and select a memory dump command +
- Enter the starting address in hexadecimal into the Address text box +
- Enter the length of the memory space to display into the Length (Hexadecimal) text box +
- Click OK +
The Memory Dump Options window appears.
+The Memory Dump Options window closes and the specified memory data appears in the Crash Debugger Console view.
+Related concepts
+ +Related references
+ + + + diff -r bf0a333d965d -r a690706fd137 debuggercdi/com.nokia.carbide.cpp.debug.crashdebugger/html/sos_cdb.htm --- a/debuggercdi/com.nokia.carbide.cpp.debug.crashdebugger/html/sos_cdb.htm Thu Feb 18 15:22:38 2010 -0600 +++ b/debuggercdi/com.nokia.carbide.cpp.debug.crashdebugger/html/sos_cdb.htm Thu Feb 18 15:23:36 2010 -0600 @@ -21,13 +21,13 @@
-
Copyright © 2009 Nokia Corporation and/or its subsidiary(-ies). All rights reserved. Copyright © 2010 Nokia Corporation and/or its subsidiary(-ies). All rights reserved. Version 2.3; Oct 2009 Version 2.5; Feb 2010 Use the Crash Debugger Console view (Figure 1) to resolve Symbian OS kernel crashes or panics. The Crash Debugger Console view interacts via a command-line interface with the crash debugger running on the device. To open the Crash Debugger Console select Window > Show View > Other... then expand Carbide.c++ folder to select Crash Debugger Console. Figure 1 - Use Crash Debugger Console view to debug devices To interact with the Crash Debugger running on the device, enter command-line commands in the view or choose them from the context menu. The context menu (Figure 2) appears whenever you right-click in the Crash Debugger Console view. Figure 2 - Right-click in Crash Debugger Console view to display the context menu NOTE If an address is selected in the Crash Debugger Console view, choosing a command from the context menu uses the selected address without displaying the Memory Dump Options window, using a default length of 100 bytes. Use the Crash Debugger Console view (Figure 1) to resolve Symbian OS kernel crashes or panics. The Crash Debugger Console view interacts via a command-line interface with the crash debugger running on the device. To open the Crash Debugger Console select Window > Show View > Other... then expand Carbide.c++ folder to select Crash Debugger Console. Figure 1 - Use Crash Debugger Console view to debug devices To interact with the Crash Debugger running on the device, enter command-line commands in the view or choose them from the context menu. The context menu (Figure 2) appears whenever you right-click in the Crash Debugger Console view. Figure 2 - Right-click in Crash Debugger Console view to display the context menu NOTE If an address is selected in the Crash Debugger Console view, choosing a command from the context menu uses the selected address without displaying the Memory Dump Options window, using a default length of 100 bytes.
+
License: http://www.eclipse.org/legal/epl-v10.html
diff -r bf0a333d965d -r a690706fd137 debuggercdi/com.nokia.carbide.cpp.debug.crashdebugger/html/view.html
--- a/debuggercdi/com.nokia.carbide.cpp.debug.crashdebugger/html/view.html Thu Feb 18 15:22:38 2010 -0600
+++ b/debuggercdi/com.nokia.carbide.cpp.debug.crashdebugger/html/view.html Thu Feb 18 15:23:36 2010 -0600
@@ -1,29 +1,29 @@
-
-
-
-
-Symbian OS Crash Debugger
- Crash Debugger Console View
-
Related concepts
-
-
-Related references
-
-
-
-
+
+
+
+
+Crash Debugger Console View
+Related concepts
+
+
+Related references
+
+
+
\ No newline at end of file