(转载自 http://blog.sina.com.cn/s/blog_6b3765230100lazj.html) ulimit -c 输出如果为0,则说明coredump没有打开 ulimit -c 输出如果为unlimited,则说明coredump已打开 通过 ulimit -c unlimited 就可以打开它, 通过 ulimit -c 0 就可以关闭它 通过上面的命令修改后,一般都只是对当前会话起作用,当你下次重新登录后,还是要重新输入上面的命令,所以很麻烦.我们可以把通过修改/e

关键词:coredump.core_pattern.coredump_filter等等. 应用程序在运行过程中由于各种异常或者bug导致退出,在满足一定条件下产生一个core文件. 通常core文件包含了程序运行时内存.寄存器状态.堆栈指针.内存管理信息以及函数调用堆栈信息. core就是程序当前工作转改存储生成的一个文件,通过工具分析这个文件,可以定位到程序异常退出的时候对应的堆栈调用等信息,找出问题点并解决. 1. 配置coredump 如果需要使用需要通过ulimit进行设置,可以通过ul

gdb调试coredump(使用篇) 看到一个非常好的介绍coredump的文章,做个记录, 参考链接: https://blog.csdn.net/sunxiaopengsun/article/details/72974548 什么是coredump Coredump叫做核心转储,它是进程运行时在突然崩溃的那一刻的一个内存快照.操作系统在程序发生异常而异常在进程内部又没有被捕获的情况下,会把进程此刻内存.寄存器状态.运行堆栈等信息转储保存在一个文件里. 该文件也是二进制文件,可以使用gdb.e

Apache Doris的BE部分是由C++编写,当出现一些内存越界,非法访问的问题时会导致BE进程的Crash.这部分的问题常常较难排查,同时也很难快速定位到对应的触发SQL,给使用者带来较大的困扰.所以下面会介绍通过Linux的CoreDump快速定位到问题SQL,并复现问题的方式. 1.查看日志 当BE进程Crash的时候,可以先查看be.out日志,确认是否存在stack trace的记录.当BE出现进程Crash的时,都会将运行时的堆栈打印到be.out文件中,一般如下图所示: 但是由

nginx在运行过程中是否稳定,是否有异常退出过?这里总结几项平时会用到的小技巧. 1. 在error.log中查看是否有signal项,如果有,看看signal是多少. 比如,这是一个异常退出的情况: $grep signal error.log 2012/12/24 16:39:56 [alert] 13661#0: worker process 13666 exited on signal 11 如果在进程退出后,有coredump文件产生,则会打出如下日志: $grep signal e

使用gdb调试Python进程 有时我们会想调试一个正在运行的Python进程,或者一个Python进程的coredump.例如现在遇到一个mod_wsgi的进程僵死了,不接受请求,想看看究竟是运行到哪行Python代码呢?这时就需要祭出gdb了.   主要是三步: 1)确保你的gdb版本>=7 2)安装python-debuginfo包(如:python-debuginfo-2.6.6-29.el6_2.2.x86_64.rpm,这个版本号一定要跟你所用的python版本一致(可以rpm -q

一.概述 有时我们会想调试一个正在运行的Python进程,或者一个Python进程的coredump.例如现在遇到一个mod_wsgi的进程僵死了,不接受请求,想看看究竟是运行到哪行Python代码呢?这时就需要祭出gdb了. 主要是三步: 1)确保你的gdb版本>=7 2)安装python-debuginfo包(如:python-debuginfo-2.6.6-29.el6_2.2.x86_64.rpm,这个版本号一定要跟你所用的python版本一致(可以rpm -qa|grep python

GDB是linux下的调试利器,在c/c++程序开发过程中必不可少的.这里总结一下多进程和多线程的调试方法和技巧. 多进程的调试: 如下示例 #include <sys/mman.h> #include <sys/stat.h> #include <fcntl.h> #include <unistd.h> #include <stdio.h> #include <stdlib.h> ; void test() { ; printf(&

最近处理一个nginx问题,故障现象是:所有的work进程,都在等锁.调用的是sem_wait 根据对应的堆栈,查看一下大家等的锁都一样,看看这把锁被谁拿了: 锁的结构是: typedef struct { #if (NGX_HAVE_ATOMIC_OPS) ngx_atomic_t *lock; #if (NGX_HAVE_POSIX_SEM) ngx_atomic_t *wait; ngx_uint_t semaphore; sem_t sem; #endif #else ngx_fd_t

什么是coredump? Coredump叫做核心转储,它是进程运行时在突然崩溃的那一刻的一个内存快照.操作系统在程序发生异常而异常在进程内部又没有被捕获的情况下,会把进程此刻内存.寄存器状态.运行堆栈等信息转储保存在一个文件里. 该文件也是二进制文件,可以使用gdb.elfdump.objdump或者windows下的windebug.solaris下的mdb进行打开分析里面的具体内容. ulimit  -c 可以设置core文件的大小,如果这个值为0.则不会产生core文件,这个值太小,则c

你好,我是雨乐! 在上篇文章中,我们分析了线上coredump产生的原因,其中用到了coredump分析工具gdb,这几天一直有读者在问,能不能写一篇关于gdb调试方面的文章,今天借助此文,分享一些工作中的调试经验,希望能够帮到大家. 写在前面 在我的工作经历中,前几年在Windows上进行开发,使用Visual Studio进行调试,简直是利器,各种断点等用鼠标点点点就能设置:大概从12年开始转Linux开发了,所以调试都是基于GDB的.本来这篇文章也想写写Windows下调试相关,奈何好多年

最近一直有人在请教老K关于Linux系统相关问题,这里我就该问题做个详解,Linux系统一般有4个主要部分:内核.shell.文件系统和应用程序. 内核.shell和文件系统一起形成了基本的操作系统结构,它们使得用户可以运行程序.管理文件并使用系统.部分层次结构如图1-1所示.

COREDUMP调试的使用 一,什么是coredump 跑程序的时候经常碰到SIGNAL 或者 call trace的问题,需要定位解决,这里说的大部分是指对应程序由于各种异常或者bug导致在运行过程中异常退出或者中止,并且在满足一定条件下(这里为什么说需要满足一定的条件呢?下面会分析)会产生一个叫做core的文件. 通常情况下,core文件会包含了程序运行时的内存,寄存器状态,堆栈指针,内存管理信息还有各种函数调用堆栈信息等,我们可以理解为是程序工作当前状态 存储生成第一个文件,许多的程序出错

1 )如何生成 coredump 文件 ? 登陆 LINUX 服务器,任意位置键入 echo "ulimit -c 1024" >> /etc/profile 退出 LINUX 重新登陆 LINUX 键入 ulimit -c 如果显示 1024 那么说明 coredump 已经被开启. 1024 限制产生的 core 文件的大小不能超过 1024kb,可以使用参数unlimited,取消该限制 ulimit -c unlimited 2 ) . core 文件的简单介绍 在

最近我们数据中心主机上的第三方管理工具升级,导致数据中心系统coredump,看起来不相关的事情,到底是怎么回事了? 首先,打开core文件看看: core.45259 is truncated: expected core file size >= 51758821376, found: 2148233216. 第一反应是有内存泄露,core文件被截断了,core文件没有其他线索 只能碰碰运气看看系统层面的日志,通过dmesg查看系统日志 00007f8e1107b7b9 sp 00007ff

一,什么是coredump 跑程序的时候经常碰到SIGNAL 或者 call trace的问题,需要定位解决,这里说的大部分是指对应程序由于各种异常或者bug导致在运行过程中异常退出或者中止,并且在满足一定条件下(这里为什么说需要满足一定的条件呢?下面会分析)会产生一个叫做core的文件. 通常情况下,core文件会包含了程序运行时的内存,寄存器状态,堆栈指针,内存管理信息还有各种函数调用堆栈信息等,我们可以理解为是程序工作当前状态 存储生成第一个文件,许多的程序出错的时候都会产生一个core文

阴沟翻船,马失前蹄,说明凡事皆有可能.自然,程序设计的再好,也会有crash的时候.开发期还还说,正式交付的系统crash自然更是难以承受的.无论何时,死一次就够了,得有方法查个水落石出. 几年前哥去广州的一家民企呆过些日子.刚到那,就碰上系统毫无线索的crash.咋办?哥想静下心来,花点时间做个工具去定位,但无奈硬件出生的领导天天赶着大家守在机房.唉,无知啊,天天守在机房,面对crash,哥想到的只有我儿子常常念的诗--来如春梦不多时,去如朝霞无觅处.嗯,crash,哥只能数数又crash了几

前面写过通过注册信号处理函数定位SEGV问题.其实Linux coredump机制也是比较好的debug手段. 进程由于某种异常或者bug导致在运行过程中异常退出或者中止,有时会产生一个叫做core的文件.在此文件中包含了程序运行时的内存,寄存器状态,堆栈指针,内存管理信息还有各种函数调用堆栈信息. core文件一般在以下几种情况下产生: 1,内存访问越界 a) 由于使用错误的下标,导致数组访问越界. b) 搜索字符串时,依靠字符串结束符来判断字符串是否结束,但是字符串没有正常的使用结束符. c

在开发运维的时候我们常常会遇到类似“Socket/File: Can’t open so many files”,“无法打开更多进程”,或是coredump过大等问题,这些都可以设置资源限制来解决.今天在教某位客户设置最大文件数方法时,搜索网上的方法时发现各家说法并不一致,便写了这篇文档. 通常对Linux某个用户设置系统资源,我们都已经知道可以用ulimit命令来查看和设置. 表 1. ulimit 参数说明 选项 [options] 含义 例子 -H 设置硬资源限制,一旦设置不能增加. ul

操作系统:Ubuntu10.04 前言:    在程序崩溃后,如何快速定位问题.    以下方法适用于开发调试阶段,不太适用成品.    本文着眼于嵌入式,PC方面更简单.    核心:gdbserver + coredump 一,安装,配置,使用 gdbserver    arm linux下安装gdb,gdbserver调试器 二,启动 coredump   linux下ulimit命令下的coredump 三,实例    1,源码 点击(此处)折叠或打开 #include <stdio.h