gdb 分析出错

1 创建测试代码test.php

<?php
function test1(){
        while(true){
              sleep(1);
        }
}echo getmypid() "\r\n";
test1();
?>

2 运行文件  php test.php 获取到pid

3 运行 gdb -p pid

4 进入gdb交互

(gdb) print (char *)executor_globals.active_op_array->filename
$1 = 0x9853a34 "/home/test.php"
(gdb) print (char *)executor_globals.active_op_array->function_name
$2 = 0x9854db8 "test1"
(gdb) print executor_globals->current_execute_data->opline->lineno
$3 = 4

也可以使用.gdbinit文件。这个文件在php源码的根目录下。使用方法如下

(gdb) source /data/software/php-5.5.25/.gdbinit
(gdb) zbacktrace
[0xa453f34] sleep(1) /home/xinhailong/test/php/test.php:4
[0xa453ed0] test1() /home/xinhailong/test/php/test.php:8
(gdb) 

补充:

使用gcore 收集信息

$gcore pid(进程号)   生成core.1234 文件

$gdb core.1234  查看信息

时间: 2024-11-26 10:24:12

gdb 分析出错的相关文章

用gdb分析core文件及常见gdb命令操作示例

1.概述 在实际的软件开发项目中,程序出现问题是在所难免的.遥想本人参加工作之后首次遇到程序的情景,至今还历历在目.之前的经验告诉我,我们越是惊慌失措,问题就越是解决不了.我们要先让自己平静下来,然后再寻找解决程序问题的办法. 在Linux下做开发的朋友,想必都与core文件打过交道.当看到自己的程序运行之后出现core时,很多人都慌乱了,仿佛天快要塌下来一样.其实,我们大可不必如此,只要我们掌握了用gdb调试core文件的办法,依然可以很快定位程序问题,一举将bug消灭掉.有关Linux co

Unix 用gdb分析core dump文件

产生core文件条件 用ulimit -c 指定core文件大小来开启core文件的生成,如:ulimit -c unlimited 用gdb分析core文件的条件 可执行程序在编译时,需加入-g参数,否则gdb无法找到symbol信息,从而无法定位问题. 例如,如下两个cpp文件中,test.cpp会导致crash. // test.cpp void testCrash() { int *p = 0; *p = 3; } // main.cpp #include <stdio.h> void

Android中使用addr2line来分析出错信息

系统:Ubuntu12.04 手机系统:Android5.0 在Android的开发过程中有会有很多的bug,利用工具可以很好的帮忙我们来分析问题,特别是一些系统报错的信息中会打印出堆栈,我们可以根据这个堆栈报错信息定位是哪个文件哪行代码出的错.下面就把我使用addr2line的过程记录下来 首先是在电脑上编译出一个eng版本,烧录到手机,在测试或调试的过程中出错了,查看出错信息如下: 01-23 11:45:38.782 D/AEE/AED (10995): coredump_socket_c

Linux程序宕掉后如何通过gdb查看出错信息

我们在编写服务端程序的时候,由于多线程并且环境复杂,程序可能在不确定条件的情况下宕掉,还不好重新,这是我们如何获取程序的出错信息,一种方法通过打日志,有时候一些错误日志也不能体现出来,这时就用到我们的core dump文件了. 通常情况下coredmp包含了程序运行时的内存,寄存器状态,堆栈指针,内存管理信息等.可以理解为把程序工作的当前状态存储成一个文件.许多程序和操作系统出错时会自动生成一个core文件. 1 我们系统一般默认是吧core dump 关掉的,可以通过ulimit -c 查看如

[Debug]用gdb分析coredump文件

1,系统默认是不产生coredump文件的,需要用以下命令使系统产生coredump文件 查看core文件的限制,此时为0,即不成生core文件 ulimit -c 0 打开core文件的限制,不限制core文件的大小,使程序可以产生core文件 ulimit -c unlimited ulimit -c unlimited 2,以下是内存访问错误示例 [cpp] view plaincopy 1 #include<stdio.h> 2 int main() 3 { 4      char* 

结合程序崩溃后的core文件分析bug

结合程序崩溃后的core文件分析bug 引言 在<I/O的效率比较>中,我们在修改图1程序的BUF_SIZE为8388608时,运行程序出现崩溃,如下图1: 图1. 段错误 一般而言,导致程序段错误的原因如下: 内存访问出错,这类问题的典型代表就是数组越界. 非法内存访问,出现这类问题主要是程序试图访问内核段内存而产生的错误. 栈溢出, Linux默认给一个进程分配的栈空间大小为8M,因此你的数组开得过大的话会出现这种问题. 首先我们先看一下系统默认分配的资源: $ ulimit -acore

[Debug]GDB学习笔记(一)

GDB学习 点击打开链接 比较详细的gdb命令 gcc编译的程序要带 -g 参数,要想运行准备调试的程序,可使用run(r)命令,在它后面可以跟随发给该程序的任何参数 其它相关备忘如何在gdb下调用shell命令:答:比如要查看当前目录,只要输入 shell pwd就好了 单步调试的一些相关命令答:step <count>单步跟踪,如果有函数调用,他会进入该函数(进入函数的前提是,此函数被编译有debug信息).next <count>同样单步跟踪,如果有函数调用,他不会进入该函数

C/C++捕获段错误,打印出错的具体位置(精确到哪一行)

修订:2013-02-16 其实还可以使用 glibc 的 backtrace_symbols 函数,把栈帧各返回地址里面的数字地址翻译成符号描述的 修订:2011-06-11 背景知识: · 在linux/unix中的信号处理机制,知道signal函数与sigaction的区别 · 段错误的概念,CPU中断处理的步骤,中断向量表的分类 · 知道CPU Exception分为Fault.trap和abort,了解他们的基本区别 · 段错误和浮点错误属于Fault,产生Fault时会将出错指令的地

mmap 映射的内存访问出错

现象 把一个打开的文件描述符,通过mmap映射到一片内存区间,对这块区间进行读写,长时间运行后出现访存错误 SIGBus Error, GDB分析相应的core出现一些内存空间不可用的错误. 问题分析 参考man mmap , 在出现下列情况下,会出错: ERRORS EBADF fd is not a valid file descriptor (and MAP_ANONYMOUS was not set). EACCES A file descriptor refers to a non-r