linux中斷棧

⑴ linux中top命令下顯示出的PR\NI\RES\SHR\S\%MEM TIME+都代表什麼

n %MEM 進程使用的物理內存百分比：

q RES 進程使用的、未被換出的物理內存大專小，單位kb。t SHR 共享內存大小，單位kbw S進程狀態。屬

D=不可中斷的睡眠狀態。

R=運行。

S=睡眠。

T=跟蹤/停止。

Z=僵屍進程。

可以通過下面的快捷鍵來更改顯示列。

(1)linux中斷棧擴展閱讀：

Linux伺服器：

在網路和計算機系統當中有廣泛的應用，可以提供資料庫管理和網路服務等內容，是一種性能非常高的和開源的伺服器，在我國的計算機系統的客戶端當中，有很多採用的就是Linux系統，其使用的范圍非常廣泛，用戶體驗反應較好。

但是對於一些希望計算機應用性能比較高的單位而言，windows系統需要經常進行資源整合和碎片化管理，系統在配置的時候經常需要重新啟動，這就無法避免產生停機的問題。同時，由於Linux系統的處理能力非常強悍，具備不可比擬的穩定性特徵。

因而Linux系統就不用經常進行重啟，Linux系統的變化可以在配置的過程中實現，所以Linux伺服器出現故障的概率比較小，所以很多企業組織在計算機配置的過程中經常使用Linux系統。

⑵ Linux內核中用戶空間棧和內核棧的區別

您好，很高興為您解答。

1.進程的堆棧

內核在創建進程的時候，在創建task_struct的同事，會為進程創建相應的堆棧。每個進程會有兩個棧，一個用戶棧，存在於用戶空間，一個內核棧，存在於內核空間。當進程在用戶空間運行時，cpu堆棧指針寄存器裡面的內容是用戶堆棧地址，使用用戶棧；當進程在內核空間時，cpu堆棧指針寄存器裡面的內容是內核棧空間地址，使用內核棧。

2.進程用戶棧和內核棧的切換

當進程因為中斷或者系統調用而陷入內核態之行時，進程所使用的堆棧也要從用戶棧轉到內核棧。

進程陷入內核態後，先把用戶態堆棧的地址保存在內核棧之中，然後設置堆棧指針寄存器的內容為內核棧的地址，這樣就完成了用戶棧向內核棧的轉換；當進程從內核態恢復到用戶態之行時，在內核態之行的最後將保存在內核棧裡面的用戶棧的地址恢復到堆棧指針寄存器即可。這樣就實現了內核棧和用戶棧的互轉。

那麼，我們知道從內核轉到用戶態時用戶棧的地址是在陷入內核的時候保存在內核棧裡面的，但是在陷入內核的時候，我們是如何知道內核棧的地址的呢？

關鍵在進程從用戶態轉到內核態的時候，進程的內核棧總是空的。這是因為，當進程在用戶態運行時，使用的是用戶棧，當進程陷入到內核態時，內核棧保存進程在內核態運行的相關信心，但是一旦進程返回到用戶態後，內核棧中保存的信息無效，會全部恢復，因此每次進程從用戶態陷入內核的時候得到的內核棧都是空的。所以在進程陷入內核的時候，直接把內核棧的棧頂地址給堆棧指針寄存器就可以了。

3.內核棧的實現

內核棧在kernel-2.4和kernel-2.6裡面的實現方式是不一樣的。

在kernel-2.4內核裡面，內核棧的實現是：

Uniontask_union{
Structtask_structtask;
Unsignedlongstack[INIT_STACK_SIZE/sizeof(long)];
};

其中，INIT_STACK_SIZE的大小隻能是8K。

內核為每個進程分配task_struct結構體的時候，實際上分配兩個連續的物理頁面，底部用作task_struct結構體，結構上面的用作堆棧。使用current()宏能夠訪問當前正在運行的進程描述符。

注意：這個時候task_struct結構是在內核棧裡面的，內核棧的實際能用大小大概有7K。

內核棧在kernel-2.6裡面的實現是（kernel-2.6.32）：

Unionthread_union{
Structthread_infothread_info；
Unsignedlongstack[THREAD_SIZE/sizeof(long)];
};

其中THREAD_SIZE的大小可以是4K，也可以是8K，thread_info佔52bytes。

當內核棧為8K時，Thread_info在這塊內存的起始地址，內核棧從堆棧末端向下增長。所以此時，kernel-2.6中的current宏是需要更改的。要通過thread_info結構體中的task_struct域來獲得於thread_info相關聯的task。更詳細的參考相應的current宏的實現。

structthread_info{
structtask_struct*task；
structexec_domain*exec_domain；
__u32flags；
__u32status;
__u32cpu;
…..
};

注意：此時的task_struct結構體已經不在內核棧空間裡面了。

如若滿意，請點擊右側【採納答案】，如若還有問題，請點擊【追問】

希望我的回答對您有所幫助，望採納！

~ O(∩_∩)O~

⑶ linux內核線程死鎖或死循環之後如何讓系統宕機重啟

在開發內核模塊或驅動時，如果處理失誤，導致內核線程中出現死鎖或者死循環，你會發現，除了重啟之外，你沒有任何可以做的。這時你的輸入不起任何作用，終端（不是指遠程的ssh工具）只會在那重復的輸出類似「BUG: soft lockup - CPU#0 stuck for 67s! [fclustertool:2043]」，更無奈的是你重啟之後導致系統掛起的堆棧信息也看不到，你所能做的就是一遍遍的加調試信息，一遍遍的重啟機器（這是我的經歷，現在想想很傻）。 這種情況你肯定不是第一個遇到的，所以內核肯定會提供處理這種情況的一些機制。但是如何來找到這些機制在哪個地方，或者說根據什麼信息去google呢？最有用的就是這句話「BUG: soft lockup - CPU#0 stuck for 67s! [fclustertool:2043]」，因為這句話提供你的信息量很大。首先，這條信息可以輸出，說明即使發生死鎖或者死循環，還是有代碼可以執行。第二，可以通過這個日誌信息，找到對應的處理函數，這個函數所在的模塊就是用來處理CPU被過度使用時用到的。所以通過這個事情，可以看到內核列印出的只言片語都有可能成為你解決問題的關鍵，一定要從重視這些信息，從中找出有用的東西。 我經常看的內核版本是官方的2.6.32內核，這個版本中我找到的函數是softlockup_tick()，這個函數在時鍾中斷的處理函數run_local_timers()中調用。這個函數會首先檢查watchdog線程是否被掛起，如果不是watchdog線程，會檢查當前佔有CPU的線程佔有的時間是否超過系統配置的閾值，即softlockup_thresh。如果當前佔有CPU的時間過長，則會在系統日誌中輸出我們上面看到的那條日誌。接下來才是最關鍵的，就是輸出模塊信息、寄存器信息和堆棧信息，檢查softlockup_panic的值是否為1。如果softlockup_panic為1，則調用panic()讓內核掛起，輸出OOPS信息。代碼如下所示：/** This callback runs from the timer interrupt, and checks * whether the watchdog thread has hung or not:*/void softlockup_tick(void){int this_cpu = smp_processor_id(); unsigned long touch_timestamp = per_cpu(touch_timestamp, this_cpu); unsigned long print_timestamp; struct pt_regs *regs = get_irq_regs(); unsigned long now; /* Warn about unreasonable delays: */ if (now <= (touch_timestamp + softlockup_thresh))return; per_cpu(print_timestamp, this_cpu) = touch_timestamp; spin_lock(&print_lock); printk(KERN_ERR BUG: soft lockup - CPU#%d stuck for %lus! [%s:%d]\n, this_cpu, now - touch_timestamp, current-comm, task_pid_nr(current)); print_moles(); print_irqtrace_events(current);if (regs)show_regs(regs);elsemp_stack(); spin_unlock(&print_lock); if (softlockup_panic) panic(softlockup: hung tasks);} 但是softlockup_panic的值默認竟然是0，所以在出現死鎖或者死循環的時候，會一直只輸出日誌信息，而不會宕機，這個真是好坑啊！所以你得手動修改/proc/sys/kernel/softlockup_panic的值，讓內核可以在死鎖或者死循環的時候可以宕機。如果你的機器中安裝了kmp，在重啟之後，你會得到一份內核的core文件，這時從core文件中查找問題就方便很多了，而且再也不用手動重啟機器了。如果你的內核是標准內核的話，可以通過修改/proc/sys/kernel/softlockup_thresh來修改超時的閾值，如果是CentOS內核的話，對應的文件是/proc/sys/kernel/watchdog_thresh。CentOS內核和標准內核還有一個地方不一樣，就是處理CPU佔用時間過長的函數，CentOS下是watchdog_timer_fn()函數。 這里介紹下lockup的概念。lockup分為soft lockup和hard lockup。 soft lockup是指內核中有BUG導致在內核模式下一直循環的時間超過10s（根據實現和配置有所不同），而其他進程得不到運行的機會。hard softlockup是指內核已經掛起，可以通過watchdog這樣的機制來獲取詳細信息。這兩個概念比較類似。如果你想了解更多關於lockup的信息，可以參考這篇文檔： 注意上面說的這些，都是在內核線程中有效，對用戶態的死循環沒用。如果要監視用戶態的死循環，或者內存不足等資源的情況，強烈推薦軟體層面的watchdog。具體的操作可以參考下面的文章，都寫的非常好，非常實用：

⑷ 如何看調用棧linux from

使用VS2010之類的IDE進行調試呀，在任務管理器右鍵選進程，選擇debug, 按中斷，可以查看所有線程堆棧

⑸ 誰知道如何查看Windows下正在運行的程序堆棧，Linux可以用gdb，windows下該用什麼

可以用Process Explorer，支持查看函數名調用堆棧。
不過如果要看詳細的堆棧數據內容，則需要windbg或者其他的工具。

⑹ 如何在程序異常退出前輸出當前進程的堆棧信息 Backtraces

列印堆棧是調試的常用方法，一般在系統異常時，我們可以將異常情況下的堆棧列印出來，這樣十分方便錯誤查找。實際上還有另外一個非常有用的功能：分析代碼的行為。android代碼太過龐大復雜了，完全的靜態分析經常是無從下手，因此通過列印堆棧的動態分析也十分必要。

Android列印堆棧的方法，簡單歸類一下
1. zygote的堆棧mp
實際上這個可以同時mp java線程及native線程的堆棧，對於java線程，java堆棧和native堆棧都可以得到。
使用方法很簡單，直接在adb shell或串口中輸入：
[plain] view plain
kill -3 <pid>
輸出的trace會保存在 /data/anr/traces.txt文件中。這個需要注意，如果沒有 /data/anr/這個目錄或/data/anr/traces.txt這個文件，需要手工創建一下，並設置好讀寫許可權。
如果需要在代碼中，更容易控制堆棧的輸出時機，可以用以下命令獲取zygote的core mp:
[java] view plain
Process.sendSignal(pid, Process.SIGNAL_QUIT);
原理和命令行是一樣的。
不過需要注意兩點：
adb shell可能會沒有許可權，需要root。
android 4.2中關閉了native thread的堆棧列印，詳見 dalvik/vm/Thread.cpp的mpNativeThread方法：
[cpp] view plain
dvmPrintDebugMessage(target,
"\"%s\" sysTid=%d nice=%d sched=%d/%d cgrp=%s\n",
name, tid, getpriority(PRIO_PROCESS, tid),
schedStats.policy, schedStats.priority, schedStats.group);
mpSchedStat(target, tid);
// Temporarily disabled collecting native stacks from non-Dalvik
// threads because sometimes they misbehave.
//dvmDumpNativeStack(target, tid);
Native堆棧的列印被關掉了！不過對於大多數情況，可以直接將這個注釋打開。

2. debuggerd的堆棧mp
debuggerd是android的一個daemon進程，負責在進程異常出錯時，將進程的運行時信息mp出來供分析。debuggerd生 成的coremp數據是以文本形式呈現，被保存在 /data/tombstone/ 目錄下(名字取的也很形象，tombstone是墓碑的意思)，共可保存10個文件，當超過10個時，會覆蓋重寫最早生成的文件。從4.2版本開 始，debuggerd同時也是一個實用工具：可以在不中斷進程執行的情況下列印當前進程的native堆棧。使用方法是:
[plain] view plain
debuggerd -b <pid>
這可以協助我們分析進程執行行為，但最最有用的地方是：它可以非常簡單的定位到native進程中鎖死或錯誤邏輯引起的死循環的代碼位置。

3. java代碼中列印堆棧
Java代碼列印堆棧比較簡單， 堆棧信息獲取和輸出，都可以通過Throwable類的方法實現。目前通用的做法是在java進程出現需要注意的異常時，列印堆棧，然後再決定退出或挽救。通常的方法是使用exception的printStackTrace()方法：
[java] view plain
try {
...
} catch (RemoteException e) {
e.printStackTrace();
...
}
當然也可以只列印堆棧不退出，這樣就比較方便分析代碼的動態運行情況。Java代碼中插入堆棧列印的方法如下：
[java] view plain
Log.d(TAG,Log.getStackTraceString(new Throwable()));

4. C++代碼中列印堆棧
C++也是支持異常處理的，異常處理庫中，已經包含了獲取backtrace的介面，Android也是利用這個介面來列印堆棧信息的。在Android的C++中，已經集成了一個工具類CallStack，在libutils.so中。使用方法：
[cpp] view plain
#include <utils/CallStack.h>
...
CallStack stack;
stack.update();
stack.mp();
使用方式比較簡單。目前Andoid4.2版本已經將相關信息解析的很到位，符號表查找，demangle，偏移位置校正都做好了。
[plain] view plain

5. C代碼中列印堆棧
C代碼，尤其是底層C庫，想要看到調用的堆棧信息，還是比較麻煩的。 CallStack肯定是不能用，一是因為其實C++寫的，需要重新封裝才能在C中使用，二是底層庫反調上層庫的函數，會造成鏈接器循環依賴而無法鏈接。 不過也不是沒有辦法，可以通過android工具類CallStack實現中使用的unwind調用及符號解析函數來處理。
這里需要注意的是，為解決鏈接問題，最好使用dlopen方式，查找需要用到的介面再直接調用，這樣會比較簡單。如下為相關的實現代碼，只需要在要 列印的文件中插入此部分代碼，然後調用getCallStack()即可，無需包含太多的頭文件和修改Android.mk文件：
[cpp] view plain
#define MAX_DEPTH 31
#define MAX_BACKTRACE_LINE_LENGTH 800
#define PATH "/system/lib/libcorkscrew.so"

typedef ssize_t (*unwindFn)(backtrace_frame_t*, size_t, size_t);
typedef void (*unwindSymbFn)(const backtrace_frame_t*, size_t, backtrace_symbol_t*);
typedef void (*unwindSymbFreeFn)(backtrace_symbol_t*, size_t);

static void *gHandle = NULL;

static int getCallStack(void){
ssize_t i = 0;
ssize_t result = 0;
ssize_t count;
backtrace_frame_t mStack[MAX_DEPTH];
backtrace_symbol_t symbols[MAX_DEPTH];

unwindFn unwind_backtrace = NULL;
unwindSymbFn get_backtrace_symbols = NULL;
unwindSymbFreeFn free_backtrace_symbols = NULL;

// open the so.
if(gHandle == NULL) gHandle = dlopen(PATH, RTLD_NOW);

// get the interface for unwind and symbol analyse
if(gHandle != NULL) unwind_backtrace = (unwindFn)dlsym(gHandle, "unwind_backtrace");
if(gHandle != NULL) get_backtrace_symbols = (unwindSymbFn)dlsym(gHandle, "get_backtrace_symbols");
if(gHandle != NULL) free_backtrace_symbols = (unwindSymbFreeFn)dlsym(gHandle, "free_backtrace_symbols");

if(!gHandle ||!unwind_backtrace ||!get_backtrace_symbols || !free_backtrace_symbols ){
ALOGE("Error! cannot get unwind info: handle:%p %p %p %p",
gHandle, unwind_backtrace, get_backtrace_symbols, free_backtrace_symbols );
return result;
}

count= unwind_backtrace(mStack, 1, MAX_DEPTH);
get_backtrace_symbols(mStack, count, symbols);

for (i = 0; i < count; i++) {
char line[MAX_BACKTRACE_LINE_LENGTH];

const char* mapName = symbols[i].map_name ? symbols[i].map_name : "<unknown>";
const char* symbolName =symbols[i].demangled_name ? symbols[i].demangled_name : symbols[i].symbol_name;
size_t fieldWidth = (MAX_BACKTRACE_LINE_LENGTH - 80) / 2;

if (symbolName) {
uint32_t pc_offset = symbols[i].relative_pc - symbols[i].relative_symbol_addr;
if (pc_offset) {
snprintf(line, MAX_BACKTRACE_LINE_LENGTH, "#%02d pc %08x %.*s (%.*s+%u)",
i, symbols[i].relative_pc, fieldWidth, mapName,
fieldWidth, symbolName, pc_offset);
} else {
snprintf(line, MAX_BACKTRACE_LINE_LENGTH, "#%02d pc %08x %.*s (%.*s)",
i, symbols[i].relative_pc, fieldWidth, mapName,
fieldWidth, symbolName);
}
} else {
snprintf(line, MAX_BACKTRACE_LINE_LENGTH, "#%02d pc %08x %.*s",
i, symbols[i].relative_pc, fieldWidth, mapName);
}

ALOGD("%s", line);
}

free_backtrace_symbols(symbols, count);

return result;
}
對sched_policy.c的堆棧調用分析如下,注意具體是否要列印，在哪裡列印，還可以通過pid、uid、property等來控制一下，這樣就不會被淹死在trace的汪洋大海中。
[plain] view plain
D/SchedPolicy( 1350): #00 pc 0000676c /system/lib/libcutils.so
D/SchedPolicy( 1350): #01 pc 00006b3a /system/lib/libcutils.so (set_sched_policy+49)
D/SchedPolicy( 1350): #02 pc 00010e82 /system/lib/libutils.so (androidSetThreadPriority+61)
D/SchedPolicy( 1350): #03 pc 00068104 /system/lib/libandroid_runtime.so (android_os_Process_setThreadPriority(_JNIEnv*, _jobject*, int, int)+7)
D/SchedPolicy( 1350): #04 pc 0001e510 /system/lib/libdvm.so (dvmPlatformInvoke+112)
D/SchedPolicy( 1350): #05 pc 0004d6aa /system/lib/libdvm.so (dvmCallJNIMethod(unsigned int const*, JValue*, Method const*, Thread*)+417)
D/SchedPolicy( 1350): #06 pc 00027920 /system/lib/libdvm.so
D/SchedPolicy( 1350): #07 pc 0002b7fc /system/lib/libdvm.so (dvmInterpret(Thread*, Method const*, JValue*)+184)
D/SchedPolicy( 1350): #08 pc 00060c30 /system/lib/libdvm.so (dvmCallMethodV(Thread*, Method const*, Object*, bool, JValue*, std::__va_list)+271)
D/SchedPolicy( 1350): #09 pc 0004cd34 /system/lib/libdvm.so
D/SchedPolicy( 1350): #10 pc 00049382 /system/lib/libandroid_runtime.so
D/SchedPolicy( 1350): #11 pc 00065e52 /system/lib/libandroid_runtime.so
D/SchedPolicy( 1350): #12 pc 0001435e /system/lib/libbinder.so (android::BBinder::transact(unsigned int, android::Parcel const&, android::Parcel*, unsigned int)+57)
D/SchedPolicy( 1350): #13 pc 00016f5a /system/lib/libbinder.so (android::IPCThreadState::executeCommand(int)+513)
D/SchedPolicy( 1350): #14 pc 00017380 /system/lib/libbinder.so (android::IPCThreadState::joinThreadPool(bool)+183)
D/SchedPolicy( 1350): #15 pc 0001b160 /system/lib/libbinder.so
D/SchedPolicy( 1350): #16 pc 00011264 /system/lib/libutils.so (android::Thread::_threadLoop(void*)+111)
D/SchedPolicy( 1350): #17 pc 000469bc /system/lib/libandroid_runtime.so (android::AndroidRuntime::javaThreadShell(void*)+63)
D/SchedPolicy( 1350): #18 pc 00010dca /system/lib/libutils.so
D/SchedPolicy( 1350): #19 pc 0000e3d8 /system/lib/libc.so (__thread_entry+72)
D/SchedPolicy( 1350): #20 pc 0000dac4 /system/lib/libc.so (pthread_create+160)
D/SchedPolicy( 1350): #00 pc 0000676c /system/lib/libcutils.so
D/SchedPolicy( 1350): #01 pc 00006b3a /system/lib/libcutils.so (set_sched_policy+49)
D/SchedPolicy( 1350): #02 pc 00016f26 /system/lib/libbinder.so (android::IPCThreadState::executeCommand(int)+461)
D/SchedPolicy( 1350): #03 pc 00017380 /system/lib/libbinder.so (android::IPCThreadState::joinThreadPool(bool)+183)
D/SchedPolicy( 1350): #04 pc 0001b160 /system/lib/libbinder.so
D/SchedPolicy( 1350): #05 pc 00011264 /system/lib/libutils.so (android::Thread::_threadLoop(void*)+111)
D/SchedPolicy( 1350): #06 pc 000469bc /system/lib/libandroid_runtime.so (android::AndroidRuntime::javaThreadShell(void*)+63)
D/SchedPolicy( 1350): #07 pc 00010dca /system/lib/libutils.so
D/SchedPolicy( 1350): #08 pc 0000e3d8 /system/lib/libc.so (__thread_entry+72)
D/SchedPolicy( 1350): #09 pc 0000dac4 /system/lib/libc.so (pthread_create+160)

6. 其它堆棧信息查詢

⑺ linux中斷處理程序使用的堆棧是內核的堆棧嗎，在哪裡

當然是，進程生成時，會被分配一個task_struct 結構（常說的進程式控制制塊），2.4內核中版，在task_struct 結構體上面的7KB空間就權是。加上task_struct結構本身(1KB)，進程內核棧共8KB(兩個頁面 )，不會動態擴展,所以非常有限（你會見到內核代碼用"大塊"內存都會kmalloc申請的，就是這個原因）。2.6內核的沒注意，不知一樣否。詳見：《Linux內核源代碼情景分析(上)》267頁。
為什麼會在內核的原因是CPU的保護機制，中斷處理需要更高的許可權（可能執行硬體相關的操作），故要在0級，不會在用戶區的。

⑻ 在Linux中,用戶態切換到內核態時,int指令不會保存下面哪項

用戶態切換到內核態時,int指令不會保存下面

⑼ LINUX的上下文是什麼意思

當一個進程在執行時,CPU的所有寄存器中的值、進程的狀態以及堆棧中的內容被稱回為該進程答的上下文。當內核需要切換到另一個進程時，它需要保存當前進程的所有狀態，即保存當前進程的上下文，以便在再次執行該進程時，能夠必得到切換時的狀態執行下去。在LINUX中，當前進程上下文均保存在進程的任務數據結構中。在發生中斷時,內核就在被中斷進程的上下文中，在內核態下執行中斷服務常式。但同時會保留所有需要用到的資源，以便中繼服務結束時能恢復被中斷進程的執行。