IE hang 分析

本文通过使用Windbg和Procexp等工具,详细记录了定位并解决Internet Explorer浏览器挂起问题的过程,最终确认是由第三方解码器导致的问题。
IE hang住了,页面数据无法恢复(其实要恢复也是有办法的,windbg挂上去搜 Smile),郁闷!
 
如果说是Crash倒是简单,直接挂上去分析。可是现在是hang了,从来没有尝试过分析这种情况。
 
硬着头皮上吧。
 
首先看了一下task manager,3个ie进程,倒是UI上IE只有2个tab.
然后仔细一看,有个进程cpu占用率基本上在40%以上下不来。
基本确定问题进程是在这里。
 
打开procexp,查看问题进程的信息,可以清楚地看到问题出在哪个

 

问题在tid为2812的线程。

查看2812号线程的stack,如下

根据stack,大致猜测问题出在MpegSplitter.ax上。

生成ie的dump,windbg挂上去,然后敲入

lmvm mpegsplitter

 

得到如下信息

start             end                 module name
00000000`075e0000 00000000`07647000   MpegSplitter   (export symbols)       MpegSplitter.ax
    Loaded symbol image file: MpegSplitter.ax
    Image path: C:/Program Files (x86)/FreeTime/FormatFactory/FFModules/Filters/MpegSplitter.ax
    Image name: MpegSplitter.ax
    Timestamp:        Tue Sep 29 15:23:34 2009 (4AC1B5F6)
    CheckSum:         00064AB9
    ImageSize:        00067000
    File version:     1.3.1290.0
    Product version:  1.3.1290.0
    File flags:       0 (Mask 17)
    File OS:          4 Unknown Win32
    File type:        7.0 Static library
    File date:        00000000.00000000
    Translations:     0409.04b0
    CompanyName:      Gabest
    ProductName:      Mpeg Splitter
    InternalName:     Mpeg Splitter
    OriginalFilename: MpegSplitter.ax
    ProductVersion:   1, 1, 0, 0
    FileVersion:      1, 1, 0, 0
    FileDescription:  Mpeg Splitter
    LegalCopyright:   Copyright (C) 2002-2009 see AUTHORS file
    Comments:        
http://sourceforge.net/projects/mpc-hc/

看来是格式工厂(FormatFactory)注册的一个开源解码器出问题了。

打开格式工厂,确实看到它有注册这个解码器到系统。卸载这个解码器。再开出问题的页面,问题貌似消失!

 

去睡觉了。

考虑可再生能源出力不确定性的商业园区用户需求响应策略(Matlab代码实现)内容概要:本文围绕“考虑可再生能源出力不确定性的商业园区用户需求响应策略”展开,结合Matlab代码实现,研究在可再生能源(如风电、光伏)出力具有不确定性的背景下,商业园区如何制定有效的需求响应策略以优化能源调度和提升系统经济性。文中可能涉及不确定性建模(如场景生成与缩减)、优化模型构建(如随机规划、鲁棒优化)以及需求响应机制设计(如价格型、激励型),并通过Matlab仿真验证所提策略的有效性。此外,文档还列举了大量相关的电力系统、综合能源系统优化调度案例与代码资源,涵盖微电网调度、储能配置、负荷预测等多个方向,形成一个完整的科研支持体系。; 适合人群:具备一定电力系统、优化理论和Matlab编程基础的研究生、科研人员及从事能源系统规划与运行的工程技术人员。; 使用场景及目标:①学习如何建模可再生能源的不确定性并应用于需求响应优化;②掌握使用Matlab进行商业园区能源系统仿真与优化调度的方法;③复现论文结果或开展相关课题研究,提升科研效率与创新能力。; 阅读建议:建议结合文中提供的Matlab代码实例,逐步理解模型构建与求解过程,重点关注不确定性处理方法与需求响应机制的设计逻辑,同时可参考文档中列出的其他资源进行扩展学习与交叉验证。
<think>我们正在分析MTK平台上的hang_detect问题。根据提供的引用,hang_detect是MTK的一种机制,用于检测系统是否卡住(hang),并在检测到时主动重启手机。引用中出现了两种场景:一种是hang_detect线程本身出现问题(引用1),另一种是hang_detect检测到上层应用(如system_server)卡住而主动触发重启(引用2)。分析步骤:1.**理解hang_detect机制**:hang_detect是MTK在Linux内核中实现的一个线程,它定期检查关键进程(如init、surfaceflinger、system_server等)是否能够正常调度。如果某个关键进程在预定时间内没有调度(即“tick”没有更新),hang_detect会认为该系统已经挂起,并触发重启。2.**查看日志**:首先需要查看内核日志(dmesg或kmsg),搜索关键字“Hang_Detect”来获取hang_detect的行为记录。如引用1和引用2所示,日志会记录hang_detect检测的进程、倒计时的状态以及触发重启前的堆栈信息。3.**分析hang_detect触发的原因**:-如果是hang_detect线程本身出现问题(如引用1中的线程卡住),那么需要分析hang_detect线程的堆栈(如引用1中显示的PC和LR寄存器值)来定位问题。-如果是hang_detect检测到其他关键进程卡住(如引用2中的system_server),那么需要分析被检测进程的堆栈。引用2中,hang_detect在检测到system_ui卡住时,会打印“dumpsystem_uiallthreadbt”,即需要获取system_ui进程的所有线程的堆栈。4.**获取堆栈信息**:-当hang_detect检测到问题并打印堆栈时,需要在内核日志中查找对应的堆栈信息。这些信息可以帮助确定卡住的代码位置。-对于用户空间进程(如system_server),还可以通过tombstone或ANR日志来获取更详细的信息。5.**复现问题**:由于hang_detect问题通常难以复现,需要根据日志分析在什么条件下触发了hang_detect。可能需要长时间运行特定压力测试来复现。6.**代码分析**:根据日志中给出的函数地址(如引用1中的`hang_detect_thread+0x244`)或函数名,可以查看内核源码中hang_detect的实现,理解检测逻辑和可能的问题点。具体到引用1的问题:-日志显示hang_detect线程在`hang_detect_thread+0x244`处卡住,并且LR(返回地址)在`console_unlock+0x25c`,这可能是由于控制台输出锁竞争导致hang_detect线程被阻塞。具体到引用2的问题:-hang_detect检测到system_ui进程卡住,因此需要分析system_ui进程的堆栈,查看其所有线程的状态,找出卡住的线程和原因。因此,分析MTK平台hang_detect问题的基本步骤是:收集日志(特别是内核日志)->定位触发hang_detect的进程/线程->分析相关堆栈->结合代码理解原因。相关问题:1.如何获取MTK平台的内核日志?2.hang_detect机制在内核中的实现原理是什么?3.如何分析关键进程(如system_server)的卡死问题?</think>### 分析MTK平台hang_detect问题的步骤 #### 1. **定位触发时间点** - 查看内核日志中`[Hang_Detect]`标记的时间戳(如引用中的`451.448876`秒) - 确认问题发生前300秒内的系统活动(MTK默认检测窗口) - **关键命令**:`adb shell dmesg | grep "hang_detect"` #### 2. **分析线程状态** ```bash adb shell cat /proc/kmsg | grep -E "hang_detect|PC is at|LR is at" ``` - 关注线程状态字段(如`status 1`表示异常) - 检查PC/LR寄存器值(如`c06c8bbc`)定位卡死代码位置 - 识别被监控的关键进程: - `system_server` (Android核心服务) - `surfaceflinger` (显示合成服务) - `mmcqd/0` (存储I/O线程) #### 3. **获取完整调用栈** - 触发主动call bug时的线程回溯(如引用2末尾的`dump system_ui all thread bt`) - 使用MTK调试工具解析地址符号: ```bash arm-linux-androideabi-addr2line -e vmlinux c06c8bbc ``` #### 4. **检查监控配置** - 验证`/sys/kernel/hang_detect/`下的参数: ```bash adb shell cat /sys/kernel/hang_detect/* ``` - 关键参数: - `tick_threshold`:进程无响应阈值 - `monitored_pids`:被监控进程列表 - `dump_stack`:触发时是否保存堆栈 #### 5. **复现与日志收集** - 开启完整内核日志: ```bash adb shell "echo 8 > /proc/sys/kernel/printk" ``` - 使用`systrace`捕获调度延迟: ```bash python systrace.py --time=300 sched irq freq ``` - 结合`ftrace`锁定阻塞函数: ```bash echo function_graph > /sys/kernel/debug/tracing/current_tracer ``` #### 6. **常见问题模式分析** | 模式 | 日志特征 | 可能原因 | |------|----------|----------| | 内核死锁 | `PC is at mutex_lock+0x...` | 资源竞争或中断禁用 | | 进程阻塞 | `[Hang_Detect] system_server not tick` | Binder调用超时 | | 硬件异常 | `pc : [<ffffffc0>]` | 内存损坏或总线错误 | | 调度延迟 | `status 1:10` | CPU负载过高 | ### 引用分析结论 1. 引用1显示`hang_detect_thread`自身卡死在`console_unlock`函数,表明内核日志系统可能发生死锁[^1] 2. 引用2显示`system_ui`进程无响应触发主动重启,需检查UI线程的Binder调用链[^2] ###
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值