1.深入理解 kernel panic 的码分流程
2.[源码级解析]解决Aegisub3.2.2 MacOS版本音量/缩放滑块无法使用的BUG
3.Windows11+Metis5.1.0 gpmetis 源码bug问题
4.一个关于webpack 自动use strict引起的有趣的业务bug以及背后原理
5.Android Adb 源码分析(一)

深入理解 kernel panic 的流程

       深入理解 kernel panic 的流程

       在项目开发中，遇到手机系统死机重启的码分情况，尤其是码分由于内核问题导致的 kernel panic，无疑会给调试带来巨大挑战。码分内核在死机前会输出关键信息，码分包括PC指针、码分雷霆OBV源码调用栈等，码分这些信息对于理解异常原因、码分定位问题至关重要。码分本文将从常见的码分主动触发 BUG() 开始，解析整个 kernel panic 的码分流程。

       BUG() 是码分 Linux 内核中用于拦截内核程序超出预期行为的机制。它有两种主要用途：一是码分软件开发过程中，遇到致命的码分代码错误时，主动调用 BUG() 使系统崩溃，码分以方便定位问题；二是为了 debug 需要捕获内存快照时，引导系统进入 kernel panic 状态。

       BUG() 的实现原理是插入一条未定义指令（0xe7ff2），触发 ARM 异常处理机制。Linux 内核源码分析可从 ke.qq.com 获取。c cmd源码

       在理解了 BUG() 的作用后，我们将深入分析从调用 BUG() 到系统重启的整个流程。

       BUG() 流程分析

       调用 BUG() 会触发 CPU 执行未定义指令，导致 ARM 发生未定义指令异常，进而进入内核异常处理流程，输出关键调试线索，最终调用 panic() 终止自身并引导系统重启。这一过程包括 Oops、die()、__die() 等关键步骤。

       die() 流程

       die() 函数负责收集异常信息并准备输出。在执行中，它将打印出标志性的 log，如 “[ cut here ]” 表示发生了致命故障。通过搜索关键字 “Internal error: Oops” 可以快速识别出是 BUG() 导致的异常。

       __die() 流程分析

       __die() 函数输出异常的详细信息，如 PC 指针、调用栈等。通过打印关键信息，vb表格源码我们可以定位到异常发生的具体代码位置，如进程 ID、CPU、异常类型等。此外，它还会生成内存快照和调用栈，辅助调试。

       panic 流程

       panic() 函数表示内核遭遇了不可恢复的错误。它收集和输出所有关键信息，然后终止内核进程，引导系统进入重启流程。

       通过理解这一流程，开发者能够更有效地定位并修复由 kernel panic 引起的异常，特别是通过主动调用 BUG() 导致的异常，其调试难度通常相对较低。

[源码级解析]解决Aegisub3.2.2 MacOS版本音量/缩放滑块无法使用的BUG

       本文解析了Aegisub3.2.2 MacOS版本中波形视图右侧音量/缩放滑块无法正常使用的BUG。该问题导致滑块只能在0%和%之间调整，严重影响使用体验。为了解决此问题，ember chart 源码我们首先通过查看Aegisub的源代码，发现其使用了wxWidgets库中的wxSlider控件。进一步分析代码发现，滑块的宽度和高度参数设置为时，滑块宽度缩小，高度不可见，从而导致滑块无法正常滑动。将宽度和高度参数设置为默认值wxDefaultSize或-1后，滑块恢复正常。通过修改Aegisub源码并重新编译，解决了此BUG。最终，我们构建并打包了修复后的软件，分享给需要的用户。

Windows+Metis5.1.0 gpmetis 源码bug问题

       运行编译后的 gpmetis.exe 命令，预期应生成分区文件，但实际操作中却未能如愿，输出文件并未出现。

       执行命令：

       .\gpmetis.exe .\4elt.graph 4

       结果并未产生文件，英文购物 源码如预期的 4elt.graph.4 等分区文件。

       深入代码追踪，困惑与不解随之而来。VS 提供的线索指向了异常的栈使用，这似乎与问题的根源相关。

       经过细致排查，发现是数组的开辟过大，这并非必要，文件名的长度不至于如此。

       对代码进行调整，修改数组的开辟大小。

       调整后，程序能够正常输出信息，并生成预期的分区文件，如 4elt.graph.part.4。

       此问题的解决为类似错误的处理提供了参考，修正方法可适用于其他情况。

       本文档旨在记录并分享这一问题的解决过程，以供相关开发者参考与借鉴。

一个关于webpack 自动use strict引起的有趣的业务bug以及背后原理

       Webpack自动use strict引起的业务bug分析

       在处理业务bug的过程中，我发现它不仅提供了锻炼技巧的机会，还揭示了一些隐藏的知识点。

       问题起因于公司管理后台，一个基于webpack多页面应用的项目，其中部分文件夹使用了webpack的特殊处理，而其他未处理的文件夹则仅简单地使用babel进行es5转换。当某个需求需要迁移至已处理的文件夹时，问题出现了。

       问题代码中，一个函数没有声明就直接被使用，导致了"params is not defined"的错误。这是因为引入了严格模式，严格模式下未声明就使用会导致编译错误。

       解决方法简单，只需为变量声明即可。然而，问题的关键在于严格模式的来源。虽然代码本身并未主动引入，但webpack的打包过程可能在无意中引入了。

       在webpack打包产物对比中，我们发现迁移后引入了use strict，这成为问题的根源。进一步的代码分析发现，use strict的出现与import的使用有关，因为webpack会将import转换为浏览器兼容的形式，并将其依赖放在头部执行。

       总结来说，问题在于在使用import时，webpack遵循ES6模块的严格模式规范，而es module本身已经是严格模式。因此，webpack会自动添加use strict以适应es module。通过追踪Webpack源码，我们找到了use strict插入的确切位置，这解决了问题的原因。

Android Adb 源码分析(一)

       面对Android项目的调试困境，我们的团队在项目临近量产阶段，将userdebug版本切换为了user版本，并对selinux权限进行了调整。然而，这一转变却带来了大量的bug，日志文件在/data/logs/目录下，因为权限问题无法正常pull出来，导致问题定位变得异常困难。面对这一挑战，我们尝试了两种解决方案。

       首先，我们尝试修改data目录的权限，使之成为system用户，以期绕过权限限制，然而数据目录下的logs文件仍保留了root权限，因此获取日志依然需要root权限，这并未解决问题。随后，我们找到了一个相对安全的解决办法——通过adb命令的后门机制，将获取root权限的命令修改为adb aaa.bbb.ccc.root。这一做法在一定程度上增加了后门的隐蔽性，避免了被窃取，同时对日常开发的影响也降至最低。

       在解决这一问题的过程中，我们对Android ADB的相关知识有了更深入的理解。ADB是Android系统中用于调试的工具，它主要由三部分构成：adb client、adb service和adb daemon。其中，adb client运行于主机端，提供了命令接口；adb service作为一个后台进程，位于主机端；adb daemon则是运行于设备端（实际机器或模拟器）的守护进程。这三个组件共同构成了ADB工具的完整框架，且它们的代码主要来源于system/core/adb目录，用户可以在此目录下找到adb及adbd的源代码。

       为了实现解决方案二，我们对adb的代码进行了修改，并通过Android SDK进行编译。具体步骤包括在Windows环境下编译生成adb.exe，以及在设备端编译adbd服务。需要注意的是，在进行编译前，需要先建立Android的编译环境。经过对ADB各部分关系及源代码结构的梳理，我们对ADB有了更深入的理解。

       在后续的开发过程中，我们将继续深入研究ADB代码，尤其是关于如何实现root权限的功能。如果大家觉得我们的分享有价值，欢迎关注我们的微信公众号“嵌入式Linux”，一起探索更多关于Android调试的技巧与知识。