内存_用户空间程序出现非法页错误

2024-06-11 17:58

本文主要是介绍内存_用户空间程序出现非法页错误,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

linux中的虚拟地址通过PGD,PTE等映射到物理地址。但当这个映射过程无法正常映射时候,就会报错,产生page fault exception。那么什么时候会无法正常呢?

  • 编程错误。程序使用了不存在的地址
  • 不是编程错误,linux的请求调页机制。即:当进程运行时,linux并不将全部的资源分配给进程,而是仅分配当前需要的这一部分,当进程需要另外的资源的时候(这时候就会产生缺页异常),linux再分配这部分。

 编程错误linux肯定不会手软的,直接弄死进程。请求调页机制,linux会申请页的。

 

当MMU对不存在的虚拟地址进行映射的时候,会产生异常,__dabt_usr: __dabt_svc。 他们都会调用do_DataAbort。

__dabt_usr:usr_entrykuser_cmpxchg_check@@ Call the processor-specific abort handler:@@  r2 - aborted context pc@  r3 - aborted context cpsr@@ The abort handler must return the aborted address in r0, and@ the fault status register in r1.                           //说明了调用do_DataAbort时候传递给他的参数。  r0,r1,@
#ifdef MULTI_DABORTldr	r4, .LCprocfnsmov	lr, pcldr	pc, [r4, #PROCESSOR_DABT_FUNC]
#elsebl	CPU_DABORT_HANDLER
#endif@@ IRQs on, then call the main handler@enable_irqmov	r2, sp                                           //参数r2adr	lr, ret_from_exceptionb	do_DataAbort                   //调用do_DataAbort
ENDPROC(__dabt_usr)


do_DataAbor根据川进来的参数调用 inf->fn ,在这里就是 do_page_fault

asmlinkage void __exception
do_DataAbort(unsigned long addr, unsigned int fsr, struct pt_regs *regs)
{const struct fsr_info *inf = fsr_info + (fsr & 15) + ((fsr & (1 << 10)) >> 6);struct siginfo info;if (!inf->fn(addr, fsr, regs))return;printk(KERN_ALERT "Unhandled fault: %s (0x%03x) at 0x%08lx\n",inf->name, fsr, addr);info.si_signo = inf->sig;info.si_errno = 0;info.si_code  = inf->code;info.si_addr  = (void __user *)addr;arm_notify_die("", regs, &info, fsr, 0);
}


 

do_page_fault函数是页异常的重要函数:

ps:因为在,__dabt_usr: __dabt_svc这两种情况下都会调用do_DataAbort函数,然后调用do_page_fault,所以调用do_page_fault可能是在内核空间,也可能是在用户空间。在内核空间可能会是 进程通过系统调用,中断等进入的,也可能进程本来是内核线程。所以在do_page_fault中要行进判断的。到底是从哪里发生的异常。

一下函数的分析大部分参考了《深入linux内核》书中的 第9章。

static int __kprobes                               //__kprobes标志应该是调试的一种东西,等以后再专门研究一下。
do_page_fault(unsigned long addr, unsigned int fsr, struct pt_regs *regs)
{struct task_struct *tsk;struct mm_struct *mm;int fault, sig, code;if (notify_page_fault(regs, fsr))       //这个函数是专门和上面的__kprobes对应的,调试的东西return 0;tsk = current;mm  = tsk->mm;                          //将出现页异常的进程的  的进程描述符 赋给tsk,内存描述符赋给mm/** If we're in an interrupt or have no user* context, we must not take the fault..*/if (in_atomic() || !mm)                //判断发生发生异常的,in_atomic判断是否是在 原子操作中:中断程序,可延迟函数,禁用内核抢占的临界区。   !mm  判断进程是否是内核线程。参照博客线程调度的文章。goto no_context;              //如果缺页是发生在这些情况下,那么就要特殊处理,因为这些程序都是没有用户空间的,要特殊处理。/** As per x86, we may deadlock here.  However, since the kernel only* validly references user space from well defined areas of the code,* we can bug out early if this is from code which shouldn't.*/if (!down_read_trylock(&mm->mmap_sem)) {if (!user_mode(regs) && !search_exception_tables(regs->ARM_pc))goto no_context;down_read(&mm->mmap_sem);}                                           //down sem,没啥说的。fault = __do_page_fault(mm, addr, fsr, tsk);          //下面分析。up_read(&mm->mmap_sem);/** Handle the "normal" case first - VM_FAULT_MAJOR / VM_FAULT_MINOR*/if (likely(!(fault & (VM_FAULT_ERROR | VM_FAULT_BADMAP | VM_FAULT_BADACCESS))))return 0;                                                          //如果返回值不是上面的值。那么就是MAJOR  MINOR,说明问题解决了,return,如果是,那么还要go on/** If we are in kernel mode at this point, we* have no context to handle this fault with.*/if (!user_mode(regs))goto no_context; //如果是内核空间出现了 页异常,并且通过__do_page_fault没有没有解决,那么到on_contextif (fault & VM_FAULT_OOM) {/** We ran out of memory, or some other thing* happened to us that made us unable to handle* the page fault gracefully.*/printk("VM: killing process %s\n", tsk->comm);do_group_exit(SIGKILL);return 0;}if (fault & VM_FAULT_SIGBUS) {/** We had some memory, but were unable to* successfully fix up this page fault.*/sig = SIGBUS;code = BUS_ADRERR;} else {/** Something tried to access memory that* isn't in our memory map..*/sig = SIGSEGV;code = fault == VM_FAULT_BADACCESS ?SEGV_ACCERR : SEGV_MAPERR;}                       //这上面的英文描述很清楚了__do_user_fault(tsk, addr, fsr, sig, code, regs);    //用户态错误,这个函数什么都不做,就是发个新号,弄死进程return 0;no_context:__do_kernel_fault(mm, addr, fsr, regs);             //内核错误,这个函数什么都不干,发送OOP:::啊啊啊 啊啊啊,这个警告曾经弄死多少好汉return 0;
}

 

 

static int
__do_page_fault(struct mm_struct *mm, unsigned long addr, unsigned int fsr,struct task_struct *tsk)
{struct vm_area_struct *vma;int fault, mask;vma = find_vma(mm, addr);    //find_vma函数是从mm结构中找到一个vm_area_struct结构,这个结构的vm_end值 > 参数addr, 但是vm_start可能大于也可能小于,但fing_vma会尽可能找到小于的。即:addr在vma这个区间中。fault = VM_FAULT_BADMAP;if (!vma)                    //如果vma为0,那么想当于所有vma的vm_end地址都 < 参数addr,这个产生异常错误的地址  肯定是无效地址了。 因为根据进程的结构,如上图,所有vm中vm_end的最大值是3G。goto out;if (vma->vm_start > addr)    //如果vm_start>addr,说明这个异常的地址是 图中  的那个 空洞中,那么则可能是在用户态的栈中出错的。则跳去 check_stackgoto check_stack;/** Ok, we have a good vm_area for this* memory access, so we can handle it.*///如果上面条件都不是,那么得到的vma结构就包含 addr这个地址。有可能是malloc后出错的。 用户态下的malloc时候,其实并不分配物理空间,只是返回一个虚拟地址,并产生一个vm_area_struct结构,当真正要用到malloc的空间的时候,才会产生异常,在这里得到真正的物理空间。 当然也有可能是其他原因,比如在read only的时候进行write了。
good_area:if (fsr & (1 << 11)) /* write? */       //fsr从第一段的汇编中得出意义,他是r1.状态。 这里看地址异常时候 是写还是其他。并复制到mask中mask = VM_WRITE;elsemask = VM_READ|VM_EXEC|VM_WRITE;fault = VM_FAULT_BADACCESS;if (!(vma->vm_flags & mask))goto out;                       //如果是写,但是vma->vm_flag写没有set 1,说明的确是权限的问题,那么就set fault的值,退出。/** If for any reason at all we couldn't handle* the fault, make sure we exit gracefully rather* than endlessly redo the fault.*/
survive:                                          //上面原因都不是,那么就给进程分配一个新的页框。成功返回VM_FAULT_MAJOR(在handle_mm_fault中得到一个页框时候出现了阻塞,进行了睡眠)/VM_FAULT_MINOR(没有睡眠)fault = handle_mm_fault(mm, vma, addr & PAGE_MASK, fsr & (1 << 11));if (unlikely(fault & VM_FAULT_ERROR)) {if (fault & VM_FAULT_OOM)          //返回OOM,没有足够的内存。 到out_of_memory中,sleep一会,retry。goto out_of_memory;else if (fault & VM_FAULT_SIGBUS)return fault;BUG();}if (fault & VM_FAULT_MAJOR)tsk->maj_flt++;elsetsk->min_flt++;return fault;out_of_memory:if (!is_global_init(tsk))goto out;/** If we are out of memory for pid1, sleep for a while and retry*/up_read(&mm->mmap_sem);yield();down_read(&mm->mmap_sem);goto survive;check_stack:if (vma->vm_flags & VM_GROWSDOWN && !expand_stack(vma, addr))          //检查堆栈,进行expand,扩展原来的栈的vma,然后goto good_area,去得到一个实际的物理地址。goto good_area;
out:return fault;
}


 

进程的用户空间结构:

图上面的堆栈空间个人感觉不对,堆是堆,栈是栈,  准确的说应该是栈吧、、。。堆会在brk()函数中设置的。

这样分析之后基本上2.4和2.5节的内容已经全包含了,下面总结扩展并补充一下下:

  • 当发生页面异常时候,会产生中断,当在用户态时候,会产生,__dabt_usr: 在内核态时__dabt_svc。但他们都会调用到do_DataAbort函数,do_DataAbort会根据中断的寄存器调用相应的处理函数。这里产生页面中断时候,会调用do_page_fault函数。
  • 在do_page_fault函数中,首先会检查中断发生时,是不是在临界区,或者中断中,或者内核线程中。 如果是的话,那么就产生个OOPs。 因为这些地方是不允许异常的。如果异常会产生阻塞,阻塞就会死锁。死锁程序员就会被弄,被弄了程序员就发过来弄linux,所以linux就先弄了程序员,发出OOPs错误。
  • 如果不在临界区中,那么调用__do_page_fault函数。这个函数会先检查 产生异常的地址,是不是进程的已有的线性空间中,即检查vm_area_struct的list中。
  • 如果在的话,检查是不是因为 权限的问题产生的异常,如果是,那么说明应用程序是有问题的,直接弄死他。 如果不是,有可能是写时复制等一些linux机制。调用handle_mm_fault函数,进行分页等。
  • 如果不在vm_area_struc的list中,如果大于所有的vm_area_struct的vm_end,那么说明是错误的地址,也是直接弄死。 如果有小于<vm_end,也小于vm_start,那么说明是在空洞中,应该是栈的问题,去申请更多的栈空间。(为什么<vm_end&&<vm_start就是在栈中,因为malloc等都是事先分配个vm_area_struct结构,当异常时,会找到相应的vm_area_struct结构的。如果找不到,那就是在栈里面了溢出了)。

下面再说handle_mm_fault函数:

  • 他会首先 检查是否已经存在了PTE等映射,如果不在alloc 所有的 PUD,PMD,PTE等,建立映射。然后调用handle_pte_fault函数。注意:由于有些在刚建立的pte,所有pte里面全是0,有些是以前是建立好的,所以里面pte里面不是0,可能有其他值。所以下面还会做判断。
  • handle_pte_fault函数会判断具体缺页的类型,具体分为3类, 会根据这三类调用不同的函数。具体调用的函数,以后再说吧。。。。。
  •                  1.这个页从来没有被访问过,也就是这个pte中全是0,pte_none这个宏返回1
  •                   2.以前访问过这个页,但这个页是非线性磁盘文件的映射,即:dirty位 置1, pte_file返回1
  •                   3. 以前访问过这个页,但内容已经被保存在磁盘上了,即:dirty位 0

 

下图是 understand linux kernel书中的一个图,中文图在中文书中的P378

 

 

 

 

 

 

一、 段错误原因分析


         1 使用非法的指针,包括使用未经初始化及已经释放的指针(指针使用之前和释放之后置为NULL)

         2 内存读/写越界。包括数组访问越界,或在使用一些写内存的函数时,长度指定不正确或者这些函数本身不能指定长度,典型的函数有strcpy(strncpy),sprintf

(snprint)等等。

         3 对于C++对象,请通过相应类的接口来去内存进行操作,禁止通过其返回的指针对内存进行写操作,典型的如string类的data()和c_str()两个接口。

         4 函数不要返回其中局部对象的引用或地址,当函数返回时,函数栈弹出,局部对象的地址将失效,改写或读这些地址都会造成未知的后果。

         5 避免在栈中定义过大的数组,否则可能导致进程的栈空间不足,此时也会出现段错误。

         6 操作系统的相关限制,如:进程可以分配的最大内存,进程可以打开的最大文件描述符个数等,这些需要通过ulimit或setrlimit或sysctl来解除相关的限制。

         7 多线程的程序,涉及到多个线程同时操作一块内存时必须进行互斥,否则内存中的内存将不可预料

         8 使用非线程安全的函数调用,例如 strerror 函数等

         9 在有信号的环境中,使用不可重入函数调用,而这些函数内部会读或写某片内存区,当信号中断时,内存写操作将被打断,而下次进入时将不避免的出错。

         10 跨进程传递某个地址

        11 某些有特殊要求的系统调用,例如epool_wait,正常情况下使用close关闭一个套接字后,epool会不再返回这个socket上的事件,但是如果你使用dup或dup2操作,将

导致epool无法进行移除操作。


二、 段错误原因查找

1) 查看函数调用栈

    在头文件"execinfo.h"中声明了三个函数用于获取当前线程的函数调用堆栈

    Function: int backtrace(void **buffer,int size)

    该函数用与获取当前线程的调用堆栈,获取的信息将会被存放在buffer中,它是一个指针列表。参数 size 用来指定buffer中可以保存多少个void* 元素。函数返回值是实际获取的指针个数,最大不超过size大小。

   在buffer中的指针实际是从堆栈中获取的返回地址,每一个堆栈框架有一个返回地址。

    注意某些编译器的优化选项对获取正确的调用堆栈有干扰,另外内联函数没有堆栈框架;删除框架指针也会使无法正确解析堆栈内容。

   Function: char ** backtrace_symbols (void *const *buffer, int size)

    backtrace_symbols将从backtrace函数获取的信息转化为一个字符串数组. 参数buffer应该是从backtrace函数获取的数组指针,size是该数组中的元素个数(backtrace的返回值)   。
   
   函数返回值是一个指向字符串数组的指针,它的大小同buffer相同.每个字符串包含了一个相对于buffer中对应元素的可打印信息.它包括函数名,函数的偏移地址,和实际的返回地址。

   现在,只有使用ELF二进制格式的程序和苦衷才能获取函数名称和偏移地址.在其他系统,只有16进制的返回地址能被获取.另外,你可能需要传递相应的标志给链接器,以能支持函数名功能(比如,在使用GNU ld的系统中,你需要传递(-rdynamic))。

   该函数的返回值是通过malloc函数申请的空间,因此调用这必须使用free函数来释放指针。

注意:如果不能为字符串获取足够的空间函数的返回值将会为NULL

Function:void backtrace_symbols_fd (void *const *buffer, int size, int fd)

backtrace_symbols_fd与backtrace_symbols 函数具有相同的功能,不同的是它不会给调用者返回字符串数组,而是将结果写入文件描述符为fd的文件中,每个函数对应一行.它不需要调用malloc函数,因此适用于有可能调用该函数会失败的情况。

下面的例子显示了这三个函数的用法

#include <execinfo.h>
#include <stdio.h>
#include <stdlib.h>

/* Obtain a backtrace and print it to stdout. */
void print_trace (void)
{
     void *array[10];
     size_t size;
     char **strings;
     size_t i;

     size = backtrace (array, 10);
     strings = backtrace_symbols (array, size);

      printf ("Obtained %zd stack frames.\n", size);

     for (i = 0; i < size; i++)
     {
          printf ("%s\n", strings);
     }
     free (strings);
}

/* A dummy function to make the backtrace more interesting. */
void  dummy_function (void)
{
       print_trace ();
}

int  main (void)
{
     dummy_function ();
      return 0;
}

备注:void *const *buffer -- buffer指向char类型的常量指针的指针(很是拗口)

2) 查看寄存器内容
要查看寄存器内容有两个解决办法:

A) 在内核里面把这些寄存器打印出来;


    段错误原因分析和查找 - ququ - linux 学习

       一:段错误时内核执行路径

根据上图,我们只需要在__do_user_fault的时候把打印信息打开就可以了,如下:

#ifdef CONFIG_DEBUG_USER

       if (user_debug & UDBG_SEGV) {

              printk(KERN_DEBUG "%s: unhandled page fault (%d) at 0x%08lx, code 0x%03x\n",

                     tsk->comm, sig, addr, fsr);

              show_pte(tsk->mm, addr);

              show_regs(regs);

       }

#endif

改成

printk(KERN_DEBUG "%s: unhandled page fault (%d) at 0x%08lx, code 0x%03x\n",

                     tsk->comm, sig, addr, fsr);

              show_pte(tsk->mm, addr);

              show_regs(regs);

就可以了;

里面会打印出 pc 寄存器的值。

B) 在上层程序里面把寄存器打印出来;


这个做法的主要思路就是先拦截SIGSEGV信号,然后在信号处理函数里面打印信息:

信号拦截代码如下:

static void  catch_sigsegv()

{

       struct sigaction action;

       memset(&action, 0, sizeof(action));

       action.sa_sigaction = sigsegv_handler;

       action.sa_flags = SA_SIGINFO;       // 注意这里,flag 是 SA_SIGINFO,这样信号处理函数就会多一些信息。

       if(sigaction(SIGSEGV, &action, NULL) < 0){

              perror("sigaction");

}

}

只需要在main函数里面加入这个函数就可以了,

main(…)

{

….

catch_sigsegv();

}

 

下面来看看这个处理函数sigsegv_handler是怎么写的,代码如下:

#include <memory.h>

#include <stdlib.h>

#include <stdio.h>

#include <unistd.h>

#include <signal.h>

#include <ucontext.h>

#include <dlfcn.h>

static void sigsegv_handler(int signum, siginfo_t* info, void*ptr)

{

        static const char *si_codes[3] = {"", "SEGV_MAPERR", "SEGV_ACCERR"};

        int i;

        ucontext_t *ucontext = (ucontext_t*)ptr;

        void *bt[100];

        char **strings;


        printf("Segmentation Fault Trace:\n");

        printf("info.si_signo = %d\n", signum);

        printf("info.si_errno = %d\n", info->si_errno);

        printf("info.si_code  = %d (%s)\n", info->si_code, si_codes[info->si_code]);

        printf("info.si_addr  = %p\n", info->si_addr);

 

        /*for arm*/

        printf("the arm_fp 0x%3x\n",ucontext->uc_mcontext.arm_fp);

        printf("the arm_ip 0x%3x\n",ucontext->uc_mcontext.arm_ip);

        printf("the arm_sp 0x%3x\n",ucontext->uc_mcontext.arm_sp);

        printf("the arm_lr 0x%3x\n",ucontext->uc_mcontext.arm_lr);

        printf("the arm_pc 0x%3x\n",ucontext->uc_mcontext.arm_pc);

        printf("the arm_cpsr 0x%3x\n",ucontext->uc_mcontext.arm_cpsr);

        printf("the falut_address 0x%3x\n",ucontext->uc_mcontext.fault_address);

 

        printf("Stack trace (non-dedicated):");

        int sz = backtrace(bt, 20);

        printf("the stack trace is %d\n",sz);

        strings = backtrace_symbols(bt, sz);

        for(i = 0; i < sz; ++i){

                printf("%s\n", strings[i]);

        }

    _exit (-1);

}

 

 

测试代码如下:

void test_segv()

{

        char *i=0;

        *i=10;

}

 

void cause_segv()

{

        printf("this is the cause_segv\n");

        test_segv();

}

int main(int argc,char **argv)

{

        catch_sigsegv();

        cause_segv();

        return 0;

}

编译方法:

gcc segment_trace.c -g –rdynamic –o segment_trace

执行:

./segment_trace

输出如下:

this is the catch_sigsegv

Segmentation Fault Trace:

info.si_signo = 11

info.si_errno = 0

info.si_code  = 1 (SEGV_MAPERR)

info.si_addr  = (nil)

the arm_fp 0xb7f8a3d4

the arm_ip 0xb7f8a3d8

the arm_sp 0xb7f8a3c0

the arm_lr 0x8998

the arm_pc 0x8974

the arm_cpsr 0x60000010

the falut_address 0x  0

Stack trace (non-dedicated):the stack trace is 5

./segment_trace(backtrace_symbols+0x1c8) [0x8844]

/lib/libc.so.6(__default_rt_sa_restorer+0) [0xb5e22230]

./segment_trace(cause_segv+0x18) [0x8998]

./segment_trace(main+0x20) [0x89c0]

/lib/libc.so.6(__libc_start_main+0x108) [0xb5e0c10c]


    C) 输出信息分析 

根据上面的输出可以看出一些端倪:

根据栈信息,可以看出是在cause_segv里面出了问题,但是最后一层栈信息是看不到的,另外需要根据pc寄存器的值来定位:

addr2line  -f -e segment_trace 0x8974

test_segv

/home/wf/test/segment_trace.c:55

可以看到说是在55行,一看:

刚好是

*i=10;

这一行,

而且可以看出,函数名是test_segv

所以基本上不需要打印栈信息,也可以定位了。

也可以使用 objdump 工具:

objdump -S -l -z  -j .text segment_trace   >1.txt

查看 0x8974 地址的代码。

这篇关于内存_用户空间程序出现非法页错误的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1051884

相关文章

NameNode内存生产配置

Hadoop2.x 系列,配置 NameNode 内存 NameNode 内存默认 2000m ,如果服务器内存 4G , NameNode 内存可以配置 3g 。在 hadoop-env.sh 文件中配置如下。 HADOOP_NAMENODE_OPTS=-Xmx3072m Hadoop3.x 系列,配置 Nam

JAVA智听未来一站式有声阅读平台听书系统小程序源码

智听未来,一站式有声阅读平台听书系统 🌟&nbsp;开篇:遇见未来,从“智听”开始 在这个快节奏的时代,你是否渴望在忙碌的间隙,找到一片属于自己的宁静角落?是否梦想着能随时随地,沉浸在知识的海洋,或是故事的奇幻世界里?今天,就让我带你一起探索“智听未来”——这一站式有声阅读平台听书系统,它正悄悄改变着我们的阅读方式,让未来触手可及! 📚&nbsp;第一站:海量资源,应有尽有 走进“智听

EMLOG程序单页友链和标签增加美化

单页友联效果图: 标签页面效果图: 源码介绍 EMLOG单页友情链接和TAG标签,友链单页文件代码main{width: 58%;是设置宽度 自己把设置成与您的网站宽度一样,如果自适应就填写100%,TAG文件不用修改 安装方法:把Links.php和tag.php上传到网站根目录即可,访问 域名/Links.php、域名/tag.php 所有模板适用,代码就不粘贴出来,已经打

跨系统环境下LabVIEW程序稳定运行

在LabVIEW开发中,不同电脑的配置和操作系统(如Win11与Win7)可能对程序的稳定运行产生影响。为了确保程序在不同平台上都能正常且稳定运行,需要从兼容性、驱动、以及性能优化等多个方面入手。本文将详细介绍如何在不同系统环境下,使LabVIEW开发的程序保持稳定运行的有效策略。 LabVIEW版本兼容性 LabVIEW各版本对不同操作系统的支持存在差异。因此,在开发程序时,尽量使用

CSP 2023 提高级第一轮 CSP-S 2023初试题 完善程序第二题解析 未完

一、题目阅读 (最大值之和)给定整数序列 a0,⋯,an−1,求该序列所有非空连续子序列的最大值之和。上述参数满足 1≤n≤105 和 1≤ai≤108。 一个序列的非空连续子序列可以用两个下标 ll 和 rr(其中0≤l≤r<n0≤l≤r<n)表示,对应的序列为 al,al+1,⋯,ar​。两个非空连续子序列不同,当且仅当下标不同。 例如,当原序列为 [1,2,1,2] 时,要计算子序列 [

【Kubernetes】K8s 的安全框架和用户认证

K8s 的安全框架和用户认证 1.Kubernetes 的安全框架1.1 认证:Authentication1.2 鉴权:Authorization1.3 准入控制:Admission Control 2.Kubernetes 的用户认证2.1 Kubernetes 的用户认证方式2.2 配置 Kubernetes 集群使用密码认证 Kubernetes 作为一个分布式的虚拟

这些心智程序你安装了吗?

原文题目:《为什么聪明人也会做蠢事(四)》 心智程序 大脑有两个特征导致人类不够理性,一个是处理信息方面的缺陷,一个是心智程序出了问题。前者可以称为“认知吝啬鬼”,前几篇文章已经讨论了。本期主要讲心智程序这个方面。 心智程序这一概念由哈佛大学认知科学家大卫•帕金斯提出,指个体可以从记忆中提取出的规则、知识、程序和策略,以辅助我们决策判断和解决问题。如果把人脑比喻成计算机,那心智程序就是人脑的

JVM内存调优原则及几种JVM内存调优方法

JVM内存调优原则及几种JVM内存调优方法 1、堆大小设置。 2、回收器选择。   1、在对JVM内存调优的时候不能只看操作系统级别Java进程所占用的内存,这个数值不能准确的反应堆内存的真实占用情况,因为GC过后这个值是不会变化的,因此内存调优的时候要更多地使用JDK提供的内存查看工具,比如JConsole和Java VisualVM。   2、对JVM内存的系统级的调优主要的目的是减少

JVM 常见异常及内存诊断

栈内存溢出 栈内存大小设置:-Xss size 默认除了window以外的所有操作系统默认情况大小为 1MB,window 的默认大小依赖于虚拟机内存。 栈帧过多导致栈内存溢出 下述示例代码,由于递归深度没有限制且没有设置出口,每次方法的调用都会产生一个栈帧导致了创建的栈帧过多,而导致内存溢出(StackOverflowError)。 示例代码: 运行结果: 栈帧过大导致栈内存

uniapp设置微信小程序的交互反馈

链接:uni.showToast(OBJECT) | uni-app官网 (dcloud.net.cn) 设置操作成功的弹窗: title是我们弹窗提示的文字 showToast是我们在加载的时候进入就会弹出的提示。 2.设置失败的提示窗口和标签 icon:'error'是设置我们失败的logo 设置的文字上限是7个文字,如果需要设置的提示文字过长就需要设置icon并给