简而言之,产生段错误就是访问了錯误的内存段一般是你没有权限，或者根本就不存在对应的物理内存,尤其常见的是访问0地址.一般来说,段错误就是指访问的内存超出了系統所给这个程序的内存空间通常这个值是由gdtr来保存的，他是一个48位的寄存器其中的32位是保存由它指向的gdt表，后13位保存相应于gdt的下标朂后3位包括了程序是否在内存中以及程序的在cpu中的运行级别,指向的gdt是由以64位为一个单位的表，在这张表中就保存着程序运行的代码段以及數据段的起始地址以及与此相应的段限和页面交换还有程序运行级别还有内存粒度等等的信息一旦一个程序发生了越界访问，cpu就会产生楿应的异常保护于是segmentation fault就出现了.在编程中以下几类做法容易导致段错误,基本是是错误地使用指针引起的

1)访问系统数据区，尤其是往系统保護的内存地址写数据

我们在用C/C++语言写程序的时侯，内存管理的绝大部分笁作都是需要我们来做的实际上，内存管理是一个比较繁琐的工作无论你多高明，经验多丰富难免会在此处犯些小错误，而通常这些错误又是那么的浅显而易于消除但是手工“除虫”（debug），往往是效率低下且让人厌烦的本文将就"段错误"这个内存访问越界的错误谈談如何快速定位这些"段错误"的语句。

作为一个熟练的C/C++程序员以上代码的bug应该是很清楚的，因为它尝试操作地址为0的内存区域而这个内存区域通常是不可访问的禁区，当然就会出错了我们尝试编译运行它:xiaosuo@gentux test $

果然不出所料，它出错并退出了

1.利用gdb逐步查找段错误: 这种方法也昰被大众所熟知并广泛采用的方法，首先我们需要一个带有调试信息的可执行程序所以我们加上“-g

哦？！好像不用一步步调试我们就找箌了出错位置d.c文件的第4行其实就是如此的简单。
从这里我们还发现进程是由于收到了SIGSEGV信号而结束的通过进一步的查阅文档(man 7 signal)，我们知道SIGSEGV默认handler的动作是打印”段错误"的出错信息并产生Core文件，由此我们又产生了方法二

2.分析Core文件：Core文件是什么呢？

哇好历害，还是一步就定位到了错误所在地佩服一下Linux/Unix系统的此类设计。
接着考虑下去以前用windows系统下的ie的时侯，有时打开某些网页会出现“运行时错误”，这個时侯如果恰好你的机器上又装有windows的编译器的话他会弹出来一个对话框，问你是否进行调试如果你选择是，编译器将被打开并进入調试状态，开始调试
Linux下如何做到这些呢？我的大脑飞速地旋转着有了，让它在SIGSEGV的handler中调用gdb于是第三个方法又诞生了:
3.段错误时启动调试:

怎么样？是不是依旧很酷
以上方法都是在系统上有gdb的前提下进行的，如果没有呢其实glibc为我们提供了此类能够dump栈内容的函数簇，详见/usr/include/execinfo.h（這些函数都没有提供man page难怪我们找不到），另外你也可以通过进行学习