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中，当前进程上下文均保存在进程的任务数据结构中。在发生中断时,内核就在被中断进程的上下文中，在内核态下执行中断服务例程。但同时会保留所有需要用到的资源，以便中继服务结束时能恢复被中断进程的执行。