原因
 

   根据经验，这是一个典型的栈破坏问题。一旦栈破坏了函数返回值后，堆栈完全是错乱的，得不到任何有效信息。
最开始我建议项目组的同事查看最近提交的代码，看看能否找到线索。不过由于近一个月提交的代码实在太多，大海捞针了一段时间后，
毫无头绪。
   栈覆盖一般是因为memcpy或者是循环赋值语句导致的，一般栈覆盖的层次不会太多，所以从底部往上找，应该能找到些有效的线索。
不过，由于服务器函数经常会有Package的临时变量，导致函数栈很大，从下往上找线索也很困难，很多似是而非的合法地址很容易分散精力。

解决

  按照上面的分析，从底部往上找是大海捞针，那么从顶部往下找如何呢？
这里先说明下一般函数堆栈帧的建立(未优化情况下的用户函数):
push rbp
mov rbp, rsp
从这里可以看出，本层函数的返回值是存储在 [rbp + 8]，而上层函数的rbp地址则存储在 [rbp]。
所以，从下网上找的时候，可以根据rbp逐步找到上层函数和上层函数的堆栈帧。

那么如何往下找呢，假如知道了一个上层函数的rbp，如何获取下层函数呢，
这里有个小窍门，gdb7.X的版本有一个find功能，可以在内存区域搜索数值，
从上往下找的时候，可以在堆栈查找本层 rbp的存放地址，从而确定下层函数rbp的存放地址。
举个例子:

#0  0x00007ffff77d7830 in nanosleep () from /lib/x86_64-linux-gnu/libc.so.6

#1  0x00007ffff77d76ec in sleep () from /lib/x86_64-linux-gnu/libc.so.6

#2  0x000000000040070a in test1 () at main.cpp:9

#3  0x0000000000400715 in test () at main.cpp:14

#4  0x000000000040072b in main (argc=1, argv=0x7fffffffe648) at main.cpp:19

这是一个典型的CallStack,让我们先找到0x000000000040072b的堆栈信息吧。
先 info r 查看当前的寄存器信息:

得到 rsp为0x7fffffffe358

find $rsp, +0x300, 0x000000000040072b

0x7fffffffe548

1 pattern found.

只有一个地址，那么存放rbp的地址就是0x7fffffffe540了，

继续 find $rsp, +0x300, 0x7fffffffe540

0x7fffffffe530

1 pattern found.
验证下是否正确：
x/10xg 0x7fffffffe530

0x7fffffffe530: 0x00007fffffffe540      0x0000000000400715

0x7fffffffe540: 0x00007fffffffe560      0x000000000040072b

0x7fffffffe550: 0x00007fffffffe648      0x0000000100000000

看到了吧，就是这样找到了下一级的函数。
真实环境中往往没这么简单，有时候会找到好几个地址，这个时候需要自己逐个去伪存真了。

场景管理

问题表现  

原因

动态内存还是静态内存

      很多开发者由于担心内存泄露，在项目中禁止使用动态内存(当然这实际上几乎是做不到的)，使用对象池来避免动态内存，就是预先创建预计最大数量的对象，后续申请和归还的时候，都是操作对象池，
避免动态new和delete。这样的项目还不少，我见过的就好几个。对象池的好处是显而易见的，基本上可以避免内存泄露。但是实际上，这种方式是把双刃剑，个人觉得在游戏项目中，这种方式弊大于利。
主要弊端有下面几点：
1、开发不方便，导致需要添加很多的对象池管理类，即使有模板帮忙，也是非常繁琐的。实际开发中，几乎不可能对这些小对象类都搞一个对象池管理类。

2、由于采用预先生成对象，一般会预估一个对象可能存在的最大数量，然后按照最大数量来创建，浪费内存。
  的确，你没有内存泄露，但是你启动的时候就需要好几个G的内存，这个是内存浪费，好在现在server开发基本都是64位，没有地址空间的困扰了，但是，在大部分情况下浪费好几个G的内存，
光想想都有点心疼。

3、引入了新的风险，由于采用对象池，申请新对象的时候，只是简单的pop一个空闲对象就可以了，很容易漏掉对象初始化的工作，在回收对象的时候，大部分开发者也很容易漏掉清理工作，或者初始化和
清理工作过于简单，这样容易导致新对象被历史操作影响。曾经遇到过一个新FB所有传送点都打不开的问题，就是因为历史对象回收时数据没清理导致的。

    回头来看对象池的优点，很多开发者坚持是为了解决内存碎片和内存泄露。先说内存碎片，暂且不说内存碎片真的是否有这么严重，退一步，其实内存碎片已经有很多的成熟解决方案了，自己重载smallObject还是
采用标准的tcmalloc解决，都是非常轻松的。至于内存泄露，个人觉得这个问题其实是很好查的，也是c++程序员的基本要求。

分模块针对接口编程还是一锅粥

     这个问题单独提出来，几乎所有人都会说，当然是分模块针对接口开发了。和天下所有的事情一样，知易行难。由于游戏逻辑项目影响的地方非常多，比如死亡的时候，既需要判断死亡掉落，又需要处理任务状态，
如果在战场和竞技场中，还要判断基数和得分等等，这就导致很多开发者不假思索的把所有的东西都揉在一起，你中有我，我中有你，我改你的代码你改我的。
一个最简单的例子，我在项目中开发掉落功能，当把物品添加到玩家背包后，发现客户端没有更新背包，一查，居然还需要掉落的开发者自己构造数据包同步客户端，其实作为其他模块，根本不关心背包数据同步的细节。
这个其实在现实生活中很常见，我委托背包模块添加一个物品，具体的细节是被由被委托人来负责的。将过多的细节交给其他模块处理，会导致复杂度增加，容易出现问题，对其他人来说，也是一个精力浪费，如果是一个复杂
模块，你会发现需要了解太多的细节，修改太多自己不熟悉的代码，进而导致风险。还有一种观点，认为一锅粥的开发方式有助于了解游戏的各个业务模块，对这种观点，我是不以为然的，每天陷入到繁琐的细节，真的对熟悉业务有好处吗？或许闲下来玩玩游戏更有帮助，而且，这么乱的代码，看起来也是非常累的。分模块开发，具体的办法，游戏编程精粹5上有篇文章写得很好，这里不扩展了。

真的需要禁用STL吗

  不止一次在和其他项目交流的资料里看到对方很威严的宣称在项目里禁止使用STL。说实话，我还真没觉得STL有什么不好。见过太多这类项目自己重复实现一个个蹩脚的排序算法、容器等等。
大部分人一般都会根据经验选择使用自己熟悉的技术，这个无可厚非，但是像这样明着禁止使用STL，真不知道如何能理直气壮。其实大部分不用STL的理由，基本上都是不熟悉，完全没有足够的理由禁止使用。

游戏开发无技术含量？
 
    曾经多次听到行业内的兄弟有此感慨，确实，游戏逻辑复杂度非常高，架构上大部分都是类似的。但是这并不说明游戏后台开发复杂度不高，如何将游戏开发逻辑复杂剥离开来，做到稳定高效开发，其实还是有很多
东西可以探讨的，看看那些项目，大部分都是一锅粥，需要什么功能就蛮干，加上去，这样确实毫无技术含量，都是蛮干。所以，一件事情是否有技术含量，不光是看事情本身，还要看怎么干，蛮干和苦干，那是最没有技术
含量的方式了，程序员还是要有强烈的“偷懒”意识。

猜测

PageHeap

void fun1()
{
 fun();
}

void fun2()
{
 fun1();
}

void fun3()
{
 fun2();
}

最后，我们在main函数里执行fun3,注意编译的时候带上-rdynamic 选项。

遇到的问题

问题

解决办法

下载

准备工作

解决PDF中文问题

   1、如何调试

   2、解决字体问题

   3、编码问题

 txt中文问题

目录中文问题