今天在调试时发现了一个奇怪的core：double free or corruption (fasttop)，从堆栈看是由于 _dl_fini 函数多次重复释放了某些 STL 容器导致的，此时就算在 main 函数中只保留个简单 return 0 也会出错，因此猜想肯定和某些全局变量有关。后面经过各种修改尝试，终于发现这是由于引用的 .so 动态库和主程序中定义了同名的全局 STL 容器导致的，此时的行为简直就是一个神坑，很有必要记录一下……

在 GCC -O3 优化级别下，很多局部变量是会被优化掉的，此时只能通过人工分析反汇编代码来获取所需信息，而这么做的前提是保存下来的寄存器中的值是准确的。绝大部分情况下 coredump 是由于 segment fault 或 assert 触发的，segment fault 情况下 Kernel 保存下来的 registers 信息是准确的，GDB 中直接用 info registers 就可以看到。然而若是由 assert 触发，由于 assert 会进行多层函数调用后最终执行 raise()，错误现场的寄存器信息是不准确的，这时候就需要一些其他手段来解决此问题。下面用一个具体例子来说明此问题。

perf 是 Linux 下重要的性能分析工具，perf 可以通过采样获取很多性能指标，其中最常用的是获取 CPU Cycles，即程序各部分代码运行所需的时间，进而确定性能瓶颈在哪。不过在实际使用过程中发现，简单的使用perf record -g 获取到的调用栈是有问题的，存在大量 [Unknown] 函数，从 perf report 的结果来看这些部分对应地址大部分都是非法地址，且生成的火焰图中存在很多明显与代码矛盾的调用关系。

在旧笔记本上使用Proxmox搭建了一个OpenWRT软路由，正常使用都很稳定，然而当PC使用百度网盘，迅雷等工具进行全速率下载时偶尔会出现网络中断问题，此时Proxmox宿主机的网络会全部断掉，即PVE自己的Web管理界面也无法登录。查看终端，此时会不断打印Detected Hardware Unit Hang的错误提示。

转眼间毕业已经要一年了，今天在整理电脑文件的时候翻出了当初写的硕士毕业论文，在知网上搜搜也找得到了。想想硕士期间做过的东西也太杂了，电机控制、Android 开发、嵌入式。。。最后确定了这个毕业论文的题目后只有1年不到的时间可以做了，这期间还要复习准备找工作，不过最后做出来的东西还算是自己基本满意的，这估计也是我在学术上的顶峰了……

学习Docker时一般刚开始接触的第一个docker image就是hello-world，这个image运行起来的效果也很简单直接，仅仅是在屏幕上输出一段Docker的使用说明就结束了。这个镜像虽然简单，然而仔细分析下还是涉及不少底层机制的。

正常情况下，使用sudo命令是需要输入密码的，连续输入多条sudo只用输一次密码就行，不过若干分钟后又需要输入密码了。对于自己使用的本地桌面环境来说，其实是可以配置成sudo免输入密码的，这样可以减少一些麻烦。

本来博客使用的是多说作为评论系统，前两年多说停止服务了换成了友言，用了没多久友言又要求备案不能用了……后面由于工作繁忙也就没管这个了。前段时间发现Gitment这个基于Github Issue的评论系统不错，这两天终于有空把它给加上了。

sizeof是获取数组元素个数的常用运算符，然而前几天使用时发现，对于extern类型的数组，sizeof的使用上是有些需要考虑的问题的。

好久没写博客了，翻看自己的博客，上次更新已是半年多前了，这大半年来忙于找工作，毕业设计，毕业答辩、入职……入职前两个月也是各种忙碌，现在对手头的工作也熟悉一些了，于是乎在低头做事的空暇时也需要抬起头来看看路了。