1.stackwalk和crash log的区别
2.linux程序内存越界定位分析总结有哪些?
3.GDB使用详解
4.Linux 调试秘籍深入探索 C++运行时获取堆栈信息和源代码行数的终极指南

stackwalk和crash log的区别

       ã€€1.在提交新版本到AppStore时候一定要保留每个版本的.dSYM文件。无法定位crash的代码肯定是.dSYM文件和crash report对应的程序版本不一致。　　2.由用户反馈的当前版本的crash report可以在iTunesConnect下载。如果是存在设备上的，可以用Organizer导出　　3.打开.crash文件，参考Hardware Model确定故障设备是armv6还是armv7架构。　　4.利用.dSYM定位调用栈记录中未确定的offset。　　比如有如下记录:　　Last Exception Backtrace:　　0 CoreFoundation 0xa8bf __exceptionPreprocess　　1 libobjc.A.dylib 0xa1e5 objc_exception_throw　　2 CoreFoundation 0xa7b9 +[NSException raise:format:]　　3 CoreFoundation 0xa7db +[NSException raise:format:]　　4 CoreFoundation 0xb -[__NSCFDictionary setObject:forKey:]　　5 MyApp 0xe6f8b 0x + 　　6 MyApp 0xb 0x + 　　...//更多stacktrace　　使用atos命令和.dSYM确定0xe6f8b和0xb的对应代码。在命令行中输入：　　atos -o MyApp.app/MpApp -arch armv7 0xe6f8b 0xb　　得到如下结果：　　-[MyViewController foo:] (in MyApp) (MyViewController.m:)　　-[MyDelegate bar:] (in MyApp) (MyDelegate.m:)　　这样就确定了调用栈中offset对应的源代码位置。注意如果此时.dSYM文件版本不对，会得到完全无用的错误结果。之后就可以根据所有信息综合分析，确定crash的原因并修正。

linux程序内存越界定位分析总结有哪些?

       在工作中遇到一个奇特问题，编译同一份源码生成的.so库在程序中使用时出现各种异常情况，而其他同事编译出的库则无问题。初步分析发现是库源代码中一个全局数组内存地址大面积越界到其他全局数组。现象为触发特定业务条件时，程序逻辑运行异常，java基于sip源码异常log显示“g_sMaxFd”变量值被置0，正常情况下应大于0，导致业务运行异常。

       分析确定问题出现在代码中对“g_sMaxFd”变量的赋值操作，可能是内存越界引起。定位内存越界处的策略是使用Linux的mprotect()函数设置指定内存区域为只读，故意使程序引发segment fault退出并生成core dumped文件，以此定位问题点。首先，了解mprotect()函数的使用和局限性。

       采用“g_sMaxFd”数组地址与页大小整数倍的对齐策略，或在数组地址前定义一个动态数组“g_debug_place”，jquery源码临摹大小为页大小整数倍，以确保只在内存越界的地方被访问。这种方法需要调整内存分配以满足mprotect()函数参数长度要求。如果“g_sMaxFd”数组起始地址不是页大小整数倍，计算大于且最接近的页大小整数倍地址，作为mprotect()函数的起始地址。

       调整内存分配后，通过复现问题并等待程序内存越界产生段错误退出，分析核心是通过gdb工具分析core文件。确保编译可执行程序时加入-g参数以保留调试信息，并检查core dumped是否已开启。利用backtrace相关函数代替gdb分析，可能更轻量化且适用性更强。

       进一步分析发现，问题与编译顺序有关。在生成.so库时，链接.o文件的防止扒源码顺序差异导致全局变量数组地址分布不同。具体分析log文件显示两个全局数组变量“gs_s8Contenx”与“g_sMaxFd”的地址顺序差异，这是问题暴露的关键点。由于编译顺序影响了变量地址顺序，导致我编译的库中“gs_s8Contenx”地址小于“g_sMaxFd”，在代码中以超过数组元素最大值进行赋值操作时，引发大面积内存越界，从而导致g_sMaxFd变量值被修改，产生异常。

       同事编译的库同样存在gs_s8Contenx越界问题，但由于gs_s8Contenx地址大于g_sMaxFd，因此越界的是一个不常用的地址，问题未能立即显现。理解编译顺序对全局变量位置的影响是解决此类问题的关键。

GDB使用详解

       GDB，GNU的符号调试器，作为Linux下广泛使用的程序调试工具，支持多种编程语言，光度立体 源码如C、C++、Go等。其主要功能包括程序调试、启动、退出、命令执行和多线程调试。以下是GDB的详细使用指南：

       1. 启动GDB：通常通过"gdb ./filename"附加调试文件，然后使用"run"命令（简写r）来启动程序。如在redis-server中，先输入r启动，中断后用"continue"（c）命令继续。

       2. 断点设置："break"命令用于添加断点，可以通过行号、函数名或文件位置设置。例如，添加在anet.c的afn源码分析行bind函数处。

       3. 常用命令：如"info break"查看断点信息，"backtrace"查看调用堆栈，"list"显示源代码，"print"或"ptype"用于查看变量值。

       4. 多线程调试：GDB支持多线程，通过设置"scheduler-locking"和"schedule-multiple"来控制线程执行。例如，使用"set scheduler-locking on"锁定线程，防止线程切换。

       5. 结束调试：退出GDB时会提示是否关闭进程，"return"和"finish"用于退出函数，"until"命令指定执行到指定位置。

       6. 文档参考：官方文档和相关教程如"GDB常用命令"和"GDB调试教程"提供了更深入的使用指导。

       通过这些命令，你可以灵活地调试你的程序，找出并修复潜在问题。GDB的掌握对于深入理解程序运行机制和调试技巧至关重要。

Linux 调试秘籍深入探索 C++运行时获取堆栈信息和源代码行数的终极指南

       在软件开发的世界里，特别是在C++领域，运行时错误和异常是常见的挑战。这些错误和异常往往需要开发者深入探索、分析和解决。在这个过程中，获取运行时的堆栈信息和代码行数成为了一项至关重要的任务。正如《代码大全》(Code Complete) 中所说：“好的代码是自我解释的。” 但在现实世界中，当面临复杂的、多层次的代码结构时，我们需要更多的上下文信息来理解和解决问题。

       在C++中，获取运行时的堆栈信息和代码行数并不像看上去那么简单。我们常常需要依赖外部工具和库来帮助我们完成这项任务。但是，这并不意味着我们无法在代码内部实现这一功能。通过深入探索和学习，我们可以找到合适的方法和技术来实现这一目标。

       在本文中，我们将探讨如何使用backtrace, dladdr, 和 libbfd 的组合来获取运行时的堆栈信息和代码行数。我们将从底层原理出发，深入分析每个函数和库的工作原理和使用方法。我们将通过实例代码，展示如何整合这些技术来实现我们的目标。

       正如《C++编程思想》(The C++ Programming Language) 中所说：“C++的设计目标是表达直观的设计。” 我们的目标也是通过直观、清晰的代码和解释，帮助读者理解这一复杂但有趣的主题。

       在GCC的源码中，我们可以找到backtrace 和 dladdr 函数的具体实现。这些函数位于 libgcc 和 glibc 中，通过深入分析这些源码，我们可以更好地理解它们的工作原理和限制。

       通过阅读本文，读者将能够了解如何使用backtrace 函数获取当前的堆栈地址，并使用 backtrace_symbols 函数将这些地址转换为人类可读的字符串形式。这些字符串通常包含函数名、偏移量和地址。我们还将讨论如何使用 dladdr 函数解析堆栈地址，获取函数名和所在的动态链接库信息。libbfd 库将用于获取源代码的行数信息。通过详细的代码示例、图表和解释，我们将帮助读者逐步理解和掌握这些技术。

       正如《深入理解计算机系统》中所说：“堆栈跟踪是程序运行时的快照，它展示了函数调用的层次结构和执行路径。” 获取堆栈信息对于调试和优化代码至关重要。

       接下来，我们将深入探讨如何使用backtrace 函数获取堆栈信息。backtrace 是一个强大的工具，它能帮助我们在程序运行时捕获当前的堆栈跟踪信息。

       在获取堆栈信息后，我们将讨论如何解析这些信息，以获取更具体的信息，例如函数名和源代码行数。我们将深入分析 dladdr 函数的工作原理，以及如何使用它解析堆栈地址。此外，我们还将探讨 libbfd 库如何帮助我们从堆栈地址中获取源代码的文件名和行号。

       为了提供一个完整的解决方案，我们将整合所有步骤，展示如何从获取堆栈信息到解析堆栈地址，再到获取源代码行数，形成一个完整的、自动化的解决方案。

       在解决可能出现的问题方面，我们将详细探讨符号缺失、动态链接库的影响、编译器和平台差异以及复杂或模糊的堆栈信息等问题，并提供相应的解决方案。我们的目标是确保实现既准确又完整，能够在各种情况下可靠地工作。

       总结而言，通过综合应用backtrace, dladdr, 和 libbfd 等技术，我们不仅解决了运行时获取堆栈信息和源代码行数的复杂问题，还为读者展示了这些技术的实际应用和深层次原理。在这个过程中，我们不仅学习了技术，更深入探讨了技术背后的原理和思维。