<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>GDB on Tony Bai</title><link>https://tonybai.com/tags/gdb/</link><description>Recent content in GDB on Tony Bai</description><generator>Hugo</generator><language>zh-cn</language><copyright>2004-2026 Tony Bai. 版权所有.</copyright><lastBuildDate>Thu, 08 May 2025 00:00:00 +0800</lastBuildDate><atom:link href="https://tonybai.com/tags/gdb/index.xml" rel="self" type="application/rss+xml"/><item><title>Go 1.25链接器提速、执行文件瘦身：DWARF 5调试信息格式升级终落地</title><link>https://tonybai.com/2025/05/08/go-dwarf5/</link><pubDate>Thu, 08 May 2025 00:00:00 +0800</pubDate><guid>https://tonybai.com/2025/05/08/go-dwarf5/</guid><description>Go 1.25链接器提速、执行文件瘦身：DWARF 5调试信息格式升级终落地 - Tony Bai =============== Tony Bai 一个程序员的心路历程 * Google Go语言编码风格规范 * Google Go语言编码风格规范：指南篇 * Google Go语言编码风格规范：决定篇 * Google Go语言编码风格规范：最佳实践篇 * Go语言第一课FAQ * Go语言进...</description></item><item><title>Goroutine调度实例简要分析</title><link>https://tonybai.com/2017/11/23/the-simple-analysis-of-goroutine-schedule-examples/</link><pubDate>Thu, 23 Nov 2017 00:00:00 +0800</pubDate><guid>https://tonybai.com/2017/11/23/the-simple-analysis-of-goroutine-schedule-examples/</guid><description>前两天一位网友在微博私信我这样一个问题： &amp;gt; 抱歉打扰您咨询您一个关于Go的问题：对于goroutine的概念我是明了的，但很疑惑goroutine的调度问题, 根据《Go语言编程》一书：“当一个任务正在执行时，外部没有办法终止它。要进行任务切换，只能通过由该任务自身调用yield()来主动出让CPU使用权。” 那么，假设我的goroutine是一个死循环的话，是否其它goroutine就没有执行...</description></item><item><title>近期遇到的3个Golang代码问题</title><link>https://tonybai.com/2015/01/23/three-issues-about-go-code/</link><pubDate>Fri, 23 Jan 2015 00:00:00 +0800</pubDate><guid>https://tonybai.com/2015/01/23/three-issues-about-go-code/</guid><description>这两周来业余时间都在用Golang写代码，现在处于这样一个状态：除了脚本，就是Golang了。反正能用golang实现的，都用golang写。 Golang语言相对成熟了，但真正写起来，还是要注意一些“坑”的，下面是这周遇到的三个问题，这里分享出来，希望能对遇到同样问题的童鞋有所帮助。 **一、误用定时器，狂占CPU** golang中有一个通过channel实现timeout或tick time...</description></item><item><title>跨过BUG查找的"最后一公里"</title><link>https://tonybai.com/2013/06/18/walk-through-the-last-mile-of-bugfix/</link><pubDate>Tue, 18 Jun 2013 00:00:00 +0800</pubDate><guid>https://tonybai.com/2013/06/18/walk-through-the-last-mile-of-bugfix/</guid><description>_如果你看到一个C程序员在通宵熬夜神情紧张地对着电脑敲代码或阅读代码，多数只有两种可能：一是为了赶进度；二就是查找内存Bug。_                                                                                                                               _— 个人感悟_ ...</description></item><item><title>利用缓冲区溢出漏洞Hack应用</title><link>https://tonybai.com/2011/12/01/hack-app-by-buffer-overflow-leak/</link><pubDate>Thu, 01 Dec 2011 00:00:00 +0800</pubDate><guid>https://tonybai.com/2011/12/01/hack-app-by-buffer-overflow-leak/</guid><description>我们在平时编码过程中很少考虑代码的安全性(security)，与正确性、高性能和可移植性相比，安全性似乎总被忽略。昨天从安全性角度泛泛地Review了一下现有的代码，发现了不少具有安全隐患的地方。我们的程序员的确缺乏系统地有关安全编码方面的训练和实践，包括我在内，在安全编码方面也都是初级选手，脑子中对安全性编码缺乏系统的理解。 市面上讲解编码安全性方面的书籍也不是很多，在C编码安全性方面，CERT...</description></item><item><title>又遇字节序问题</title><link>https://tonybai.com/2011/01/21/encounter-byte-order-problem-again/</link><pubDate>Fri, 21 Jan 2011 00:00:00 +0800</pubDate><guid>https://tonybai.com/2011/01/21/encounter-byte-order-problem-again/</guid><description>今天上午处理了一个线上产品的故障。分析来分析去，最后定位问题还是出在字节序转换的环节上。 其实测试组早在产品上线前就曾报告了这个问题，但是对应的开发人员并未对该问题进行深入地分析，而是有些草率地将该问题归结为客户端模拟器的实现不符合标准。因为这位同事比较资深，所以当时我也没有给予足够关注。 产品今天凌晨上线，9点左右业务量开始增大，这个问题立即就被我们在现场的运维人员发现，还好我们的系统是集群式的...</description></item><item><title>HelloWorld.s</title><link>https://tonybai.com/2010/02/28/helloworld-in-assembly/</link><pubDate>Sun, 28 Feb 2010 00:00:00 +0800</pubDate><guid>https://tonybai.com/2010/02/28/helloworld-in-assembly/</guid><description>都说汇编不易学习和使用，的确不假。自己自大学以来也曾多次尝试学习汇编，甚至大学时还有相应课时，但是自己对汇编依旧是浅尝辄止。工作后也少有使用，对汇编的认识也就停留在基础层面。汇编的学习与对计算机系统的理解是密不可分的。工作这些年也算是一直浸淫于系统层面，经过多本底层相关书籍的教诲以及工作中的实践，对计算机系统的理解就自然而然加深了。昨天下载了一本名为：“Professional Assembly ...</description></item><item><title>模拟器陷阱</title><link>https://tonybai.com/2009/08/22/the-trap-of-simulator/</link><pubDate>Sat, 22 Aug 2009 00:00:00 +0800</pubDate><guid>https://tonybai.com/2009/08/22/the-trap-of-simulator/</guid><description>暑去清凉来，一场大雨让燥热一去不复返了，这让身体舒服了许多。本周四晚有一次产品升级操作，按惯例每次升级前的都会对产品做一次针对性的回归测试，这次也不例外，不过临近下班时测试组爆出一个莫名奇妙的问题。 测试人员在BUG说明中写到：产品在只运行某个流程A的情况是正常的，但是当流程A和流程B一起运行时，就会出XX异常情况。作为开发人员遇到类似的问题第一反映多为：这怎么可能呢？这个产品已经经过N轮测试并且...</description></item><item><title>发现一隐藏多年的Bug</title><link>https://tonybai.com/2008/09/06/found-a-bug-that-is-hidden-several-years/</link><pubDate>Sat, 06 Sep 2008 00:00:00 +0800</pubDate><guid>https://tonybai.com/2008/09/06/found-a-bug-that-is-hidden-several-years/</guid><description>C语言程序员在平时工作中，到底如何获取成就感呢？我几乎可以肯定的是：找到一个隐藏已久，多年无人发现的大Bug肯定可以归属到C程序员成就感的范畴中。与操作系统斗、与编译器斗、与内存斗，其乐无穷吗^\_^。 今天测试人员在进行平台迁移测试时发现一个致命的问题，导致系统不能正常工作。问题提到我这，为了不耽误测试进度，马上丢下手头的工作开始问题的查找，经过GDB多次跟踪调试，终于发现了一隐藏多年的问题，至...</description></item><item><title>switch语句性能考量</title><link>https://tonybai.com/2008/08/18/thoughts-on-the-performance-of-switch-case-statments/</link><pubDate>Mon, 18 Aug 2008 00:00:00 +0800</pubDate><guid>https://tonybai.com/2008/08/18/thoughts-on-the-performance-of-switch-case-statments/</guid><description>每年都有应届毕业生来到公司，每年都要对新同事进行代码方面的培训，比如编码规范就是其中之一。编码规范初听起来比较新鲜，但是培训时间长了，显然有些乏味。今年我打算改变策略，让新同事结合已有规范文档和项目代码，自己先挖掘一遍，然后大家通过坐下来讨论的互动方式来加深对规范的理解，每次讨论时间限制在1 hour以内，不给大家打瞌睡的机会^\_^。 上周和新同事一起讨论表达式和语句，说到了switch和if，...</description></item><item><title>也谈’SIGBUS和SIGSEGV’</title><link>https://tonybai.com/2007/12/19/also-talk-about-sigbus-and-sigsegv/</link><pubDate>Wed, 19 Dec 2007 00:00:00 +0800</pubDate><guid>https://tonybai.com/2007/12/19/also-talk-about-sigbus-and-sigsegv/</guid><description>SIGBUS和SIGSEGV也许是我们在平时遇到的次数最多的两个内存错误信号。内存问题一直是最令我们头疼的事情，弄清楚两个信号的发生缘由对我们很好的理解程序的运行是大有裨益的。 我们来看两段程序： //testsigsegv.c int main() {         char \*pc = (char\*)0×00001111;         \*pc = 17; } //testsigbu...</description></item><item><title>面对'错误'的抉择</title><link>https://tonybai.com/2007/11/13/the-choice-when-dealing-with-errors/</link><pubDate>Tue, 13 Nov 2007 00:00:00 +0800</pubDate><guid>https://tonybai.com/2007/11/13/the-choice-when-dealing-with-errors/</guid><description>大凡写程序者，都会遇到错误； 大凡写程序者也都知道两种错误处理的机制：传统的&amp;#39;错误码返回机制&amp;#39;和&amp;#39;面向对象语言引入的异常处理机制&amp;#39;。 人们常常会在这两种机制之间徘徊不定，难以抉择。但有两类人大可不必为此头痛，他们是坚决只使用&amp;#39;错误码返回机制&amp;#39;的人，和坚决只使用&amp;#39;异常处理机制&amp;#39;的人。而苦就苦了摇摆在中间，思索不定的那些人了。这群人有一个特点就是不停的问：&amp;#34;什么是异常？什么时候该使用错误码返回？什么时...</description></item><item><title>遭遇Heap溢出</title><link>https://tonybai.com/2007/11/10/debug-heap-overflow/</link><pubDate>Sat, 10 Nov 2007 00:00:00 +0800</pubDate><guid>https://tonybai.com/2007/11/10/debug-heap-overflow/</guid><description>今天凌晨配合云南移动进行局数据全量升级，本来以为是件很轻松的活计，甚至不需要我动手的事情，结果却又是一次惨痛的教训啊。 这个活计其实真的很简单，就是将数据库中的旧数据全部删除，然后导入新的数据，由于数据量较大需要重启一次我们的系统。问题就在重启系统上。摆在我面前的就是&amp;#34;重启失败&amp;#34;，系统dump一个core文件。通过pstack和gdb查看如下： core &amp;#39;core&amp;#39; of 7971: xxxxx...</description></item><item><title>不完备库接口带来的隐患</title><link>https://tonybai.com/2006/09/09/hidden-danger-introduced-by-uncompleted-interface/</link><pubDate>Sat, 09 Sep 2006 00:00:00 +0800</pubDate><guid>https://tonybai.com/2006/09/09/hidden-danger-introduced-by-uncompleted-interface/</guid><description>最近自己曾经辛苦耕耘过的两个项目同时上线，相关问题也就逐渐暴露出来。工作这两年多时间以后，使我有这样感觉：’测试永远都是不完备的’，有些问题只能在商用过程中发现，呵呵，明确一点啊我不是搞测试的:) 在解决问题过程中的感悟往往是最深刻的，解决问题的过程往往真的像是警察在侦破案件，往往一点点罪犯留下的蛛丝马迹就会让神探们找到线索，并迅速破案。 最近两天一直在一个bug上煎熬着，终于于昨天发现蛛丝马迹并...</description></item><item><title>小心'溢出'陷阱</title><link>https://tonybai.com/2006/09/06/be-careful-of-the-trap-of-overflow/</link><pubDate>Wed, 06 Sep 2006 00:00:00 +0800</pubDate><guid>https://tonybai.com/2006/09/06/be-careful-of-the-trap-of-overflow/</guid><description>这几天以前曾经做过的一个项目上线测试了，果不其然，没有经过’战争洗礼’的产品就是靠不住，这不出了若干问题。害得我逃了半天课远程支持。 其中的一个问题很值得思考。其所在的模块并非是一个核心功能模块，而是一个提高系统Availability的一个功能模块，主要功能就是监视磁盘占用率。我们通过配置给出允许使用的磁盘空间大小(以M Byte为单位)，以及两个阈值，即当占用率达到多少的时候，Do A；达到多...</description></item><item><title>线程函数参数引发的问题</title><link>https://tonybai.com/2006/06/07/a-problem-caused-by-thread-func-argument/</link><pubDate>Wed, 07 Jun 2006 00:00:00 +0800</pubDate><guid>https://tonybai.com/2006/06/07/a-problem-caused-by-thread-func-argument/</guid><description>上午我们的一个实施组从现网发回来一封邮件，接到这种邮件一般都是报告问题的，果然不出所料，现场出现一个core，经过分析这是个由于线程函数参数存储位置不当造成的，从中我们可以总结出一些经验，以避免以后再犯。 我采用下面的一个例子来模拟问题的出现： #include #include #include typedef struct foo {         char c\[10\];        ...</description></item><item><title>小心库函数调用的'陷阱'</title><link>https://tonybai.com/2006/05/31/take-care-of-trap-when-invoking-lib-functions/</link><pubDate>Wed, 31 May 2006 00:00:00 +0800</pubDate><guid>https://tonybai.com/2006/05/31/take-care-of-trap-when-invoking-lib-functions/</guid><description>下午一同事发现代码中的一处问题，问题的现象是这样的：这位同事调用了一部门基础库函数，当使用32位编译后，程序正常运行；而当使用64位编译后，系统运行dump core。让这位同事奇怪的是他所修改的程序中还有其他模块也使用了同样的基础库函数，为什么偏偏他这块儿出错呢？恰恰该程序的其他模块是我写的。 该程序调用的基础库函数大致是这样的： typedef unsigned long my\_size\_...</description></item><item><title>用GDB调试多进程程序</title><link>https://tonybai.com/2006/01/08/debug-multiple-process-program-using-gdb/</link><pubDate>Sun, 08 Jan 2006 00:00:00 +0800</pubDate><guid>https://tonybai.com/2006/01/08/debug-multiple-process-program-using-gdb/</guid><description>有一段时间没有写技术方面的东西了^\_^。众所周知，GDB是Unix/Linux下调试程序的龙头老大，GDB功能强大，我们在平时多使用其一些最基本的功能，而且一般调试的都是单进程的程序。最近一个项目中的问题让我接触如何使用GDB调试多进程程序，更确切的是说调试调用fork的多进程程序。 使用GDB最好的文档就是其名为&amp;#39;Debugging with GDB&amp;#39;的参考手册。手册中有一小章节提到了如何调试...</description></item><item><title>汇编之路-复习栈操作</title><link>https://tonybai.com/2005/11/24/assembly-series-review-stack-operation/</link><pubDate>Thu, 24 Nov 2005 00:00:00 +0800</pubDate><guid>https://tonybai.com/2005/11/24/assembly-series-review-stack-operation/</guid><description>不得不承认上次关于栈桢和栈操作写得有些笼统，这里做一次“补充”，美名其曰：“复习”。 下面的这个例子几乎就能覆盖所有的栈操作相关的内容了。 void dummy() {         int     i = 12;         int     j = 13;         char    c = &amp;#39;a&amp;#39;; } int main() {         dummy();         re...</description></item></channel></rss>