segments的专栏

我想用valgrind检查一个长时间运行的内存泄漏过程.我怀疑我之后的内存泄漏可能会在执行几个小时之后才会发生.我可以在valgrind下运行应用程序并获得valgrind日志就好了,但这样做意味着我必须退出应用程序并重新启动它以重新启动一个新的valgrind会话,我仍然需要等待几个小时.是否可以保持valgrind和应用程序运行并在执行期间的任何时候仍然获得valgrind的(部分)数据？你可以使用 Valgrind gdbserver and GDB来做到这一点.简而言之,您可以像往常一样使用

Linux下的软件开发，因为有着众多的开源项目助力，开发难度应该降低很多才是。但是如果用的开源库太多了，偶尔也会遇到2个开源库相互冲突的问题。好比正在干活，有2个好朋友一起过来帮忙，但是活没有干完，这2个好朋友却先起冲突干起来了。人在江湖，朋友多了，似乎朋友之间的矛盾也成了自己的矛盾。-------------------------摘自某某码农开发笔记。特别是在纯C的软件开发中，如果依赖的2个第三方库，有同名的函数，变量或宏定义，那么麻烦就大了去了。有人说，难道编译不过吗？不是，还真不影响编译。但就是

可重入的函数是安全的。不可重入的函数，每次调用返回的结果，可能是不一致的，即使每次传入的参数是一样的。编程语言里的函数如此，那么linux的shell脚本是不是可重入的呢？答案是：未必。其中，有很大部分的shell脚本是不可重入的。这自然带出问题：如何防止shell脚本的重入？---------------------------------------摘自某某不会装AC的码农笔录这里讨论的脚本重入问题，是说在同一时刻，同时调用2次同一个脚本文件。很多时候，我们希望的结果可能有2种，分别是：1. 多

没有遭遇过软件的随机crash问题的研发人生是不完满的，没有解决过软件随机crash问题的研发人生是有遗憾的！-------------摘自某某装AC人士笔录！在一个大型软件里，或是服务器软件，或是嵌入式系统终端软件里，软件crash问题，比比皆是，是个软件开发者必然遭遇过。但是，软件随机crash问题，相遇很难，解决亦难。这里说的随机crash，是会发生在软件运行过程里的不同地方，具体地说，使用GDB追踪几次crash，你会发现每次crash发生得代码文件和行数都不一样。 这就说明，每次追踪得死亡现

原文链接：https://blog.youkuaiyun.com/thisinnocence/article/details/80025064对于大型Linux C/C++程序，内存越界和野指针类问题往往比较难定位。有的由于内存被非法改写造成了业务功能问题，有的则直接导致了程序crash，而且还经常不是第一现场。针对这种问题，可以采取的解决方法有：利用valgrind工具来排查，会影响程序性能； 使用Address Sanitizer工具排查； 如果是固定的内存被破坏，可以利用gdb watch来抓取第一现

前言被问及bash shell的调试方法问题，写了10多年的各种脚本，还真被问到了。以往的打印信息和输出log文件的搞法，对于一些linux后台开发使用到的复杂脚本调试，确实是不够的。有点糗！已存在的方法Shell脚本调试选项Shell本身提供一些调试方法选项：-n，读一遍脚本中的命令但不执行，用于检查脚本中的语法错误。 -v，一边执行脚本，一边将执行过的脚本命令打印到标准输出。 -x，提供跟踪执行信息，将执行的每一条命令和结果依次打印出来。使用这些选项有三种方法(注意:避免几种

QT-Creator的qDebug()输出调试信息很方便，并且可以简单的重定向保存为log文件。但是qDebug()输出的信息没有直接带上当前文件名和行号，甚至当前系统日期时间等信息。这里介绍一个方法重新格式化qDebug()输出信息，可以添加上你需要显示的额外信息，同时保存成log文件。QtMessageHandler gDefaultHandler = NULL; // get ...