崩溃转储、内存转储、核心转储、系统转储……这些全都会产生同样的产物:一个包含了当应用崩溃时,在那个特定时刻应用的内存状态的文件。
搞电子都知道,电路不是焊接出来的,是调试出来的。程序员也一定认同,程序不是写出来的,是调试出来的。那么调试工具就显得尤为重要,linux作为笔者重要的开发平台,在linux中讨论调试工具主要是为那些入门者提供一些帮助。调试工具能让我们能够监测、控制和纠正正在运行的程序。我们在运行一些程序的时候,可能被卡住或出现错误,或者运行过程或结果,没能如我们预期,此时,最迫切需要明白究竟发生了什么。为了修复程序,剖析和了解程序运行的细节, 调试工具就成为了我们的必备工具,工于善其事,必先利其器。在Linux下的用户空间调试工具主要有系统工具和专门调试工具:'print' 打印语句,这是新手最常用的,也是最不提倡使用的;查询 (/proc, /sys 等)系统的虚拟文件查看,这个方法有局限性;跟踪 (strace/ltrace)工具使用这个比较普遍,值得提倡;Valgrind (memwatch)内存排除工具,在内存排除方面比较独到,是内存排错的法宝;GDB大名鼎鼎的程序调试工具,这个是个全能的工具,没有完不成的,只有你不知道的。
Printf(“valriable x has value = %d\n”, x)
导读|遭受内存泄露往往是令开发者头疼的问题,传统分析工具 gdb、Valgrind在解决内存泄露问题上效率较低。本文特别邀请到了腾讯后台开发工程师邢孟棒以 TDSQL实际生产中mysql-proxy内存泄露问题作为分析对象,分享其基于动态追踪技术的通用内存泄露(增长)分析方法。其中将详细介绍内存分配器行为分析、缺页异常事件分析,涵盖应用程序内存分配的常见过程。阅读完本文后,开发者仅需关注少数可能导致内存泄露的代码路径,就能有效提升定位内存泄露(增长)问题的效率。 背景 某个 TDSQL 私有化环境中,
遇到了一个 glibc 导致的内存回收问题,查找原因和实验的的过程是比较有意思的,主要会涉及到下面这些:
假如由于调试需要,你希望原先代码中的malloc函数更换为你自己写好的malloc函数,该怎么办呢?如何对程序进行”偷梁换柱“?
对于大型的工程项目,依赖许多人的配合,包含大量不同的代码库与服务,有的我们能够访问程序的源代码,有的可以访问程序的可重定位文件,有的可以访问到可执行文件及其环境,假如我们想在在不同的层面改变或者添加一些逻辑,操作系统、编译器以及程序语言、代码库等都提供了 一些机制使得 开发者可以 方便的 增加或替换代码逻辑,对于逻辑调试、测试、性能分析、版本兼容等都有比较好的效果。
可见其实__malloc_hook相当于给malloc函数套了一层外壳,当这个函数指针的值不为NULL时,系统在调用malloc是就会触发这个hook,执行hook所指向的函数。合理构造该函数就可以达到自定义malloc的行为,捕获甚至控制返回值。于是我们想到通过之前的uaf和fastbin相关的知识,把堆块构造到该处便可以修改hook函数为自定义位置的函数,达到getshell的目的。
http://www.unknownroad.com/rtfm/gdbtut/gdbsegfault.html
导读|遭受内存泄露往往是令开发者头疼的问题,传统分析工具 gdb、Valgrind在解决内存泄露问题上效率较低。本文特别邀请到了 OpenCloudOS 社区 Contributor、腾讯后台开发工程师邢孟棒以 mysql-proxy 内存泄露问题作为分析对象,分享其基于 eBPF 动态追踪技术的通用内存泄露(增长)分析方法。
最近要将整个项目的代码从原先的只支持32位变成同时支持32位和64位,这个过程中遇到一个很不容易定位的挂死问题,花了不少时间才定位解决,因此分享给大家。
漏洞点: 虽然给了源码但是漏洞得看二进制文件才能看出,结合flag,这是C++运算符重载相关的漏洞 edit的时候存在栈复用,可以任意指针free 漏洞原理: 正常运算符重载的写法(这里只讨论写为成员函数)需要在成员函数末尾return *this,同时返回值需要为当前对象类型的引用类型,这个返回值会作为其他运算的右值,如a = b = c,为了保证程序正常,这个值必须要存在。 如果不主动写return *this,g++在编译的时候,会把返回值指针指向栈上一段同类型大小的空内存(填充为null),把这段空
在free chunk时,程序将会以单向链表的形式存到fastbin中(也就是fd指针链接下一个bins),当我们连续free一块chunk两次时,他的两个fd指针将会同时指向一个chunk,此时当我们再次使用malloc申请chunk时,根据fastbin中的fd指针的指引,便会获取到上一次free掉的堆块。而由于main_arena检查机制的原因,我们不能连续free掉一块chunk,但是可以是如下形式:
这几天遇到一个比较奇怪的问题,觉得有必要和大家分享一下。我们的一个服务,运行在docker上,在某个版本之后,占用的内存开始增长,直到docker分配的内存上限,但是并不会OOM。版本的更改如下:
最近我在前辈巨师的带领下,也进入到学习Rust的大军中,与其它语言一样,Rust最初的爬坡难点也在于字符串方面的处理。虽然说Rust与C一样也有指针概念,但是在字符串方面引用了胖指针,关于胖指针的内存布局,被引用最为广泛的一幅说明图如下:
给大家分享2个利用gdb的操作运行中的mysql实例的小技巧。(线上环境测试后再食用)
在启动调试以及设置断点之后,就到了我们非常关键的一步-查看变量。GDB调试最大的目的之一就是走查代码,查看运行结果是否符合预期。既然如此,我们就不得不了解一些查看各种类型变量的方法,以帮助我们进一步定位问题。
strace会追踪程序运行时的整个生命周期, 输出每一个系统调用的名字、参数、返回值和执行所消耗的时间等,是高级运维和开发人员排查问题的杀手铜。https://www.cnblogs.com/fadewalk/p/10847068.html
在上一篇文章中描述了如何使用Valgrind工具检查内存相关问题,包括内存泄露、空指针使用、野指针使用、重复释放等问题。对于大多数情况下,Valgrind的作用性体现更多在于“内存泄露”检查,因为空指针、野指针的访问,会引发程序段错误(segment fault )而终止,此时可以借助linux系统的coredump文件结合gdb工具可以快速定位到问题发生位置。此外,程序崩溃引发系统记录coredump文件的原因是众多的,野指针、空指针访问只是其中一种,如堆栈溢出、内存越界等等都会引起coredump,利用好coredump文件,可以帮助我们解决实际项目中的异常问题。
泄露出来的只是main_arena+x的地址,而main_arena的地址位于__malloc_hook+0x10的地方,所以 main_arena_offset = __malloc_hook_offset+0x10 x = leak_address - (__malloc_hook_address+0x10) libc_base_address = leak_address - (x + main_arena_offset)
一、编译阶段 nm 获取二进制文件包含的符号信息 strings 获取二进制文件包含的字符串常量 strip 去除二进制文件包含的符号 readelf 显示目标文件详细信息 objdump 尽可能反汇编出源代码 addr2line 根据地址查找代码行 二、运行阶段 gdb 强大的调试工具 ldd 显示程序需要使用的动态
在上一篇文章《自己动手写一个GDB|基础功能》中,我们介绍了怎么使用 ptrace() 系统调用来实现一个简单进程追踪程序,本文主要介绍怎么实现断点设置功能。
什么是对齐,以及为什么要对齐: 现代计算机中内存空间都是按照byte划分的,从理论上讲似乎对任何类型的变量的访问可以从任何地址开始,但实际情况是在访问特定变量的时候经常在特定的内存地址访问,这就需要各类型数据按照一定的规则在空间上排列,而不是顺序的一个接一个的排放,这就是对齐。 对齐的作用和原因: 各个硬件平台对存储空间的处理上有很大的不同。一些平台对某些特定类型的数据只能从某些特定地址开始存取。其他平台可能没有这种情况,但是最常见的是如果不按照适合其平台要求对数据存放进行对齐,会在存取效率上带来
Valgrind 工具套件提供了许多调试和分析工具,可帮助您使程序更快、更正确。 这些工具中最受欢迎的称为 Memcheck。 它可以检测 C 和 C++ 程序中常见的许多与内存相关的错误,这些错误可能导致崩溃和不可预知的行为。
在这篇文章中,我们将对F-Secure Internet Gatekeeper应用程序中的一个堆溢出漏洞进行解析,并介绍为何一个简单的错误就导致了一个可利用的未认证远程代码执行漏洞存在。
为了更好地实现对项目的管理,我们将组内一个项目迁移到MDP框架(基于Spring Boot),随后我们就发现系统会频繁报出Swap区域使用量过高的异常。笔者被叫去帮忙查看原因,发现配置了4G堆内内存,但是实际使用的物理内存竟然高达7G,确实不正常。JVM参数配置是“-XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M -XX:+AlwaysPreTouch -XX:ReservedCodeCacheSize=128m -XX:InitialCodeCacheSize=128m, -Xss512k -Xmx4g -Xms4g,-XX:+UseG1GC -XX:G1HeapRegionSize=4M”,实际使用的物理内存如下图所示:
3、hello.c是我们的源程序文件; 4、执行./hello 就可以看到程序的输出结果 查看gcc版本号: gcc -version 5、函数库:glibc
glibc是提供系统条用和调用函数的C库,如open,malloc,printf等
这个题感觉挺经典的,分配堆时存在一字节溢出。且只能在分配时写入,不能修改,不能打印堆块内容。
题目很明显的off-by-null,第一思路肯定是:构造unlink->overlap->leak->tcache_attack。
有些 BUG 是业务逻辑上的错误导致的,一般不会导致程序崩溃,例如:原本要将两个数相加,但不小心把这两个数相减,而导致结果出错。这时我们可以通过在程序中,使用 printf 这类输出函数来进行打点调试。
在项目迁移到Spring Boot之后,发生内存使用量过高的问题。本文介绍了整个排查过程以及使用到的工具,也非常适用于其他堆外内存排查。
PG使用共享内存在多进程之间进行数据共享。使用动态共享内存段dynamic shared memory segments在并行workers之间进行数据交换,这个内存在启动时分配固定大小。但是PG后端进程必须管理私有内存用于处理SQL语句。本文,介绍PG如何使用memory context,即内存上下文,来管理私有内存;以及如何检查内存使用情况。这对于编写服务器代码的人来说很有意思,但我要重点关注用户如何理解和调试SQL语句的内存消耗。
编译与链接的过程可以分解为4个步骤:分别是预处理(Prepressing )、编译(Compilation )、汇编(Assembly )和链接(Linking ),一个helloworld的编译过程如下:
众所周知, GNU/GCC 在标准的 C/C++ 基础上做了有实用性的扩展, 零长度数组(Arrays of Length Zero) 就是其中一个知名的扩展.
本文主要介绍如何基于 Angr 进行漏洞挖掘,并自动生成 Exploit。对于 Exploit 的自动生成问题,也被称为 AEG(Automatic Exploit Generation),其中包含漏洞挖掘、Crash分析、约束条件构造、约束求解、Exploit 生成等环节,下文通过符号执行实现对二进制程序的自动化漏洞挖掘及利用,并展示完整的 AEG 过程。文中所分析的漏洞程序为 Insomni`Hack 2016 题目之一。下载地址,其中包含漏洞程序源码 demobin.c、编译后的可执行程序 demobin 以及 Angr 脚本 solver.py。
上一篇《systemtap从入门到放弃(一)》我们知道了什么是systemtap,以及如何书写简单的systemtap脚本。本篇承接上文,介绍systemtap的安装和简易场景应用,通过几个小例子掌握systemtap在内核开发调试中的简单使用。
从Redis3.2开始,sds就有了5种类型,5种类型分别存放不同大小的字符串。在创建字符串时,sds会根据字符串的长度选择不同的类型。最终由sdsnewlen函数创建字符串:
这篇文章是我在公司 TechDay 上分享的内容的文字实录版,本来不想写这么一篇冗长的文章,因为有不少的同学问是否能写一篇相关的文字版,本来没有的也就有了。
因为这是我被问的最频繁的问题,哎呀我的程序 OOM 了怎么办,我的程序内存超过配额被 k8s 杀掉了怎么办,我的程序看起来内存占用很高正常吗?
最后两趴... 是的~今天给出的是这次国赛最后两部分:Mobile和Pwn。 --------------- 特别感谢BXS战队 --------------- 再过几天放出西湖论剑杯的writeup
发现配置的4G堆内内存,但是实际使用的物理内存高达7G,确实有点不正常,JVM参数配置是“-XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M -XX:+AlwaysPreTouch -XX:ReservedCodeCacheSize=128m -XX:InitialCodeCacheSize=128m, -Xss512k -Xmx4g -Xms4g,-XX:+UseG1GC -XX:G1HeapRegionSize=4M”,但是使用的虚拟内存和物理内存使用情况如下:
直接用shellcode解的方法比较容易,但是另一种攻击stdout泄露地址的方法更为巧妙
realloc原型是extern void *realloc(void *mem_address, unsigned int newsize);
在Linux上编写运行C语言程序,经常会遇到程序崩溃、卡死等异常的情况。程序崩溃时最常见的就是程序运行终止,报告Segmentation fault (core dumped)错误。而程序卡死一般来源于代码逻辑的缺陷,导致了死循环、死锁等问题。总的来看,常见的程序异常问题一般可以分为非法内存访问和资源访问冲突两大类。
java 语言有个神奇的地方,那就是你时不时会去关注下内存。(当然了,任何牛逼的同学都应该关注内存)
在之前的文章中,我们有讲到如何定位内存泄漏和GDB调试-从入门实践到原理。今天,借助本文,来分享另外一种更为棘手的线上问题解决方案-如何在没有coredump文件的情况下,定位程序崩溃原因。
领取专属 10元无门槛券
手把手带您无忧上云