Gityuan
Gityuan

Binder Driver缺陷导致定屏问题分析

本文讲解异步binder call是如何阻塞整个系统的，通过ramdump信息以及binder通信协议来演绎并还原定屏现场。

一、背景知识点

解决此问题所涉及到的基础知识点有：Trace、CPU调度、Ramdump推导、Crash工具、GDB工具、Ftrace，
尤其深入理解binder IPC机制。

1.1 工具简介

  • Trace：分析死锁问题的最基本的技能，通过kill -3可生成相应的traces.txt文件，里面记录着当前时刻系统各线程
    所处在的调用栈。
  • CPU调度：可通过查看schedstat节点，得知该线程是否长时间处于RQ队列的等待
  • Ramdump：把系统memory中某一个时间点的数据信息保存起来的内存崩溃文件，属于ELF文件格式。
    当系统发生致命错误无法恢复的时候，主动触发抓取ramdump能异常现场保留下来，这是属于高级调试秘籍。
  • Crash工具：用于推导与分析ramdump内存信息。
  • GDB工具：由GNU开源组织发布的、UNIX/LINUX操作系统下的基于命令行的强大调试工具，比如用于分析coredump
  • Ftrace：用于分析Linux内核的运行时行为的强有力工具，比如能某方法的耗时数据、代码的执行流情况。

1.2 Binder简介

Binder IPC是最为整个Android系统跨进程通信的基石，整个系统绝大多数的跨进程都是采用Binder，如果对Binder不太了解看本文会非常吃力，在Gityuan.com博客中有大量讲解关于Binder原理的文章，见我的博客gityuan.com，这里不再赘述，简单列两张关于Binder通信架构的图。

Binder Driver缺陷导致定屏问题分析_第1张图片
ServiceManager

Binder通信采用C/S架构，主要包含Client、Server、ServiceManager以及binder驱动部分，其中ServiceManager用于管理系统中的各种服务。Client向Server通信过程图中画的是虚线，是由于它们彼此之间不是直接交互的，而是采用ioctl的方式跟Binder驱动进行交互的，从而实现IPC通信方式。

接下来再以startService为例，展示一次Binder通信过程的方法执行流:

Binder Driver缺陷导致定屏问题分析_第2张图片
binder_ipc_process

从图中，可见当一次binder call发起后便停在waitForResponse()方法，等待执行完具体工作后才能结束。
那么什么时机binder call端会退出waitForResponse()方法？见下图：

Binder Driver缺陷导致定屏问题分析_第3张图片
binder_waitForRespone

退出waitForResponse场景说明：

  • 1）当Client收到BR_DEAD_REPLY或BR_FAILED_REPLY(往往是对端进程被杀或者transaction执行失败)，则无论是同步还是异步的binder call都会结束waitForResponse()方法。
  • 2）正常通信的情况下，当收到BR_TRANSACTION_COMPLETE则结束同步binder call； 当收到BR_REPLY则结束异步binder call。

二、初步分析

有了以上背景知识的铺垫，接下来就进入正式实战分析过程。

2.1 问题描述

Android 8.0系统用几十台手机连续跑几十个小时Monkey的情况下有概率出现定屏问题。

定屏是指屏幕长时间卡住不动，也可以成为冻屏或者hang机，绝大多数情况下都是由于多个线程之间存在直接或者间接死锁而引发，而本案例实属非常罕见例子，
异步方法处于无限等待状态被blocked，从而导致的定屏。

2.2 初步分析

通过查看trace，不难发现导致定屏的原因如下：

system_server的所有binder线程以及其中重要现场都在等待AMS锁， 而AMS锁被线程Binder:12635_C所持有；
Binder:12635_C线程正在执行bindApplication()方法，调用栈如下：

Binder Driver缺陷导致定屏问题分析_第4张图片
binder_waitForRespone

终极难题：attachApplicationLocked()是属于异步binder call，之所以叫异步binder call，就是由于可异步执行而并不会阻塞线程。
但此处却能阻塞整个系统，这一点基本是毁三观的地方。

怀疑1：有同学可能会觉得是不是Binder驱动里的休眠唤醒问题，对端进程出现异常导致无法唤醒该binder线程从而阻塞系统？
回答1：这个观点咋一看，好像合情合理，还挺能唬人的。接下来，我先来科普一下，以正视听。

如果熟悉Binder原理的同学，应该知道上面说的是不可能发生的事情。oneway binder call，也就是所谓的异步调用，
Binder机制设计绝不可能傻到让异步的binder call来需要等待对端进程的唤醒。

真正的oneway binder call， 一旦是事务发送出去。
a)如果成功，则会向自己线程thread->todo队列里面放上BINDER_WORK_TRANSACTION_COMPLETE;
b)如果失败，则会向自己线程thread->todo队列里面放上BINDER_WORK_RETURN_ERROR。

紧接着，就会在binder_thread_read()过程把刚才的BINDER_WORK_XXX读取出去，然后调出此次binder call。
之所以要往自己队列放入BINDER_WORK_XXX，为了告知本次事务是否成功的投递到对端进程。但整个过程，无需对端进程的参与。

也就是说bindApplication()方法作为异步binder调用方法，只会等待自己向自己todo队列写入的BR_TRANSACTION_COMPLETE或BR_DEAD_REPLY或BR_FAILED_REPLY。

所以说，对端进程无法唤醒的说法是绝无可能的猜想。

怀疑2：CPU的优先级反转问题，当前Binder线程处于低优先级，无法分配到CPU资源而阻塞系统？
回答2：从bugreport中来分析定屏过程被阻塞线程的cpu调度情况。

先讲解之前，先来补充一点关于CPU解读技巧：

Binder Driver缺陷导致定屏问题分析_第5张图片
binder_cpu

nice值越小则优先级越高。此处nice=-2, 可见优先级还是比较高的;

schedstat括号中的3个数字依次是Running、Runable、Switch，紧接着的是utm和stm

  • Running时间：CPU运行的时间，单位ns
  • Runable时间：RQ队列的等待时间，单位ns
  • Switch次数：CPU调度切换次数
  • utm: 该线程在用户态所执行的时间，单位是jiffies，jiffies定义为sysconf(_SC_CLK_TCK)，默认等于10ms
  • stm: 该线程在内核态所执行的时间，单位是jiffies，默认等于10ms

可见，该线程Running=186667489018ns,也约等于186667ms。在CPU运行时间包括用户态(utm)和内核态(stm)。
utm + stm = (12112 + 6554) ×10 ms = 186666ms。

结论：utm + stm = schedstat第一个参数值。

有了以上基础知识，再来看bugreport，由于系统被hang住，watchdog每过一分钟就会输出依次调用栈。我们把每一次调用找的schedstat数据拿出来看一下，如下：

Binder Driver缺陷导致定屏问题分析_第6张图片
binder_cpu

可见，Runable时间基本没有变化，也就说明该线程并没有处于CPU等待队列而得不到CPU调度，同时Running时间也几乎没有动。
所以该线程长时间处于非Runable状态，从而排除CPU优先级反转问题。

再看Event Log

01-19 19:02:33.668 12635 24699 I am_proc_start: [0,6686,10058,com.xxx.calculator,activity,com.xxx.calculator/.convert.ConvertActivity]
01-19 19:02:33.840 12635 12846 I am_kill : [0,6686,com.xxx.calculator,-10000,remove task]
01-19 19:02:33.911 12635 13399 I am_proc_bound: [0,6686,com.xxx.calculator]    
01-19 19:02:33.913 12635 13399 I am_proc_died: [0,6686,com.xxx.calculator,18]

疑问：appDiedLock()方法一般是通过BinderDied死亡回调的情况下才执行，但死亡回调肯定是位于其他线程，由于该binder线程正处于繁忙状态，并没有时间处理。
为什么同一个线程正在执行attachApplication()的过程，并没有结束的情况下还能执行appDiedLock()方法？

观察多份定屏的EventLog，最后时刻都会先执行attachApplication()，然后执行appDiedLock()。此处怀疑跟杀进程有关，或者是在某种Binder嵌套调用的情况下，将这两件事情合在binder线程？这些都只是猜疑，本身又是概率问题，需要更深入地分析才能解答这些疑团。

三、ramdump分析

有效的信息太少，基本无法采用进一步分析，只能通过抓取ramdump希望能通过里面的蛛丝马迹来推出整个过程。

抓取的ramdump是只是触发定屏后的最后一刻的异常现场，这就好比犯罪现场最后的画面，我们无法得知案发的动机是什么，
更无法得知中间到底发生了哪些状态。要基于ramdump的静态画面，去推演整个作案过程，需要强大的推演能力。
先来分析这个ramdump信息，找到尽可能多的有效信息。

3.1 结构体binder_thread

从ramdump中找到当前处于blocked线程的调用栈上的方法binder_ioctl_write_read()， 该方法的的第4个参数指向binder_read结构体，
采用crash工具便可进一步找到binder_thread的结构体如下：

Binder Driver缺陷导致定屏问题分析_第7张图片
rd_binder_thread

解读：

  • waiting_thread_node为空，则说明binder线程的 thread→transaction_stack不为空 或者 thread→todo不为空；
  • todo为空，结合前面的waiting_thread_node，则说明thread→transaction_stack一定不为空；
  • return_error和reply_error的cmd等于29185， 转换为16进制等于0x7201, 代表的命令为BR_OK = _IO('r', 1), 说明该binder线程的终态并没有error，或者中间发生error并且已被消耗掉；
  • looper = 17, 说明该线程处于等待状态BINDER_LOOPER_STATE_WAITING

3.2 binder_transaction结构体

既然thread→transaction_stack不为空，根据结构体binder_thread的成员transaction_stack = 0xffffffddf1538180，
则解析出binder_transaction结构体

Binder Driver缺陷导致定屏问题分析_第8张图片
6rd_binder_transaction

解读：

  • from = 0x0, 说明发起端进程已死
  • sender_euid=10058， 这里正是event log中出现的被一键清理所杀的进程，这里隐约能感受到此次异常跟杀进程有关
  • to_thread所指向的是当前system_server的binder线程，说明这是远端进程向该进程发起的请求
  • flags = 16, 说明是同步binder call
  • code = 11，说明该调用attachApplication()，此处虽无法完成确定，但从上下文以及前面的stack，基本可以这么认为，后续会论证。

到这里，想到把binder接口下的信息也拿出来，看看跟前面基本是吻合的code=b, 也应该是attachApplication(), 如下：

thread 13399: l 11 need_return 0 tr 0 
  incoming transaction 2845163: ffffffddf1538180 from 0:0 to 12635:13399 code b  
  flags 10 pri 0:120 r1 node 466186 size 92:8 data ffffff8014202c98

3.3 特殊的2916

看一下kernel Log，被hang住的binder线程有一个Binder通信失败的信息：

binder : release 6686:6686 transaction 2845163 out, still active
binder : 12635:13399 transaction failed 29189/-22, size 3812-24 line 2916

29189=0x7205代表的是BR_DEAD_REPLY = _IO('r', 5), 则代表return_error=BR_DEAD_REPLY，发生错误行是2916，什么场景下代码会走到2916行呢，
来看Binder Driver的代码：

Binder Driver缺陷导致定屏问题分析_第9张图片
7binder_2916

根据return_error=BR_DEAD_REPLY，从2916往回看则推测代码应该是走到2908行代码；
往上推说明target_node = context→binder_context_mgr_node，这个target_node是指service_manager进程的binder_node。
那么binder_context_mgr_node为空的场景，只有触发servicemanger进程死亡，或者至少重启过；但通过查看servicemanger进程并没有死亡和重启；
本身走到2900行， tr->target.handle等于空，在这个上下文里面就难以解释了，现在这个来看更是矛盾。

到此，不得不怀疑推理存在纰漏，甚至怀疑日志输出机制。经过反复验证，才发现原来忽略了2893行的binder_get_node_refs_for_txn()，代码如下：

Binder Driver缺陷导致定屏问题分析_第10张图片
8binder_get_node_refs

一切就豁然开朗，由于对端进程被杀，那么note→proc==null, 从而有了return_error=BR_DEAD_REPLY。

3.4 binder_write_read结构体

看完被阻塞的binder线程和事务结构体，接着需要看一下数据情况，调用栈上的binder_ioctl_write_read()方法的第三个参数便指向binder_write_read结构体，
用crash工具解析后，得到如下信息：

Binder Driver缺陷导致定屏问题分析_第11张图片
9rd_binder_write_read

解读：

  • write_size=0, 看起来有些特别，本次通信过程不需要往Binder Driver写数据，常规transaction都有命令需写入Binder Driver；
  • read_size=256，本次通信过程需要读取数据；

那么什么场景下，会出现write_size等于0，而read_size不等于0呢？
需要查看用户空间跟内核空间的Binder Driver交互的核心方法talkWithDriver()，代码如下：

Binder Driver缺陷导致定屏问题分析_第12张图片
10binder_talkwithdriver

从上述代码可知：read_size不等于0，则doReceive=true, needRead=true，从而mIn等于空； 再加上write_size=0则mOut为空。
也就是说该blocked线程最后一次跟Binder驱动交互时的mIn和mOut都为空。

而目前的线程是卡在attachApplicationLocked()过程，在执行该方法的过程一定是会向mOut里面写入数据的。但从案发后的最后一次现场来看mOut里面的数据却为空，
这是违反常规的操作，第一直觉可能会怀疑是不是出现了内存踩踏之类的，但每次都这么凑巧地能只踩踏这个数据，是不太可能的事。为了进一步验证，再把mOut和mIn这两个buffer的数据拿出来。

3.5 mOut && mIn

IPCThreadState结构体在初始化的时候，分别设置mOut和mIn的size为256。Binder IPC过程便是利用mOut和mIn
分别承担向Binder驱动写数据以及从Binder驱动读数据的功能。虽然在反复使用的过程中会出现老的命令被覆盖的情况，
但还是可能有一些有用信息。

mOut和mIn是用户空间的数据，并且是IPCThreadState对象的成员变量。程序在用户空间停在IPCThreadState的waitForResponse()过程，
采用GDB打印出当前线程用户空间的this指针的所有成员，即可找到mOut和mIn

Binder Driver缺陷导致定屏问题分析_第13张图片
11gdb_mout_min

解读：
mIn缓存区，mDataSize = 16, mDataPos = 16, 说明最后的talkWithDriver产生了两个BR命令，并且已处理；mOut缓存区，mDataSize = 0, mDataPos = 0，说明BC_XXX都已被消耗

再来进一步看看这两个缓存区中的数据，从上图可知mIn和mOut的mData地址分别为0x7747500300、0x7747500400，缓存区大小都等于256字节；
mIn缓存区中存放都是BR_XXX命令(0x72)；mOut缓存区中存放都是BC_XXX命令(0x63)。 再来分别看看两个缓存区中的数据：

mIn缓存区数据：

Binder Driver缺陷导致定屏问题分析_第14张图片
12gdb_min_data

解读：BR_NOOP = 0x720c, BR_CLEAR_DEATH_NOTIFICATION_DONE = 0x7210，可知mIn数据区中最后一次talkWithDriver的过程产生了两个BR命令依次是： BR_NOOP， BR_CLEAR_DEATH_NOTIFICATION_DONE

mOut缓存区数据：

Binder Driver缺陷导致定屏问题分析_第15张图片
13gdb_mout_data.png

解读：BC_FREE_BUFFER = 0x6303, BC_DEAD_BINDER_DONE = 0x6310，可知mOut数据区最后一次talkWithDriver的过程，所消耗掉的BC命令依次是：BC_FREE_BUFFER, BC_DEAD_BINDER_DONE

分析两份ramdump里面的mOut和mIn数据区内容内容基本完全一致，缓存区中的BC和BR信息完全一致。整个过程，通过ramdump推导发现被阻塞线程的todo队列居然为空，最后一次处理过的transaction是BC_FREE_BUFFER、BC_DEAD_BINDER_DONE和BR_NOOP、BR_CLEAR_DEATH_NOTIFICATION_DONE，能解读出来对本案例有所关联线索也就只有这么多。

3.6 疑难悬案

解决系统疑难问题可能不亚于去案件侦破，而本案就好比是密室杀人案。案发后第一时间去勘察现场(抓取ramdump)，从房门和窗口都是由内部紧锁的(mIn缓存区的write_size等于0)，凶手作案后是如何逃离现场的(todo队列为空)？从被害人(blocked线程)身体留下的剑伤并不会致命(异步线程不会被阻塞)，那到底死因是什么呢？从现场种种迹象来看(ramdump推导)很有可能是这并非第一案发现场(BUG不是发现在当前binder transaction过程)，极有可能是凶手在它处作案(其他transaction)后，再移尸到当前案发现场(binder嵌套结束后回到上一级调用处)，那么真正的第一案发现场又在哪里呢？这些都匪夷所思。

Trace、Log、Ramdump推导、Crash工具、GDB工具等十八般武艺都用过一轮了，已经没有更多的信息可以挖掘了，快没有头绪了，这个问题几乎要成为无头公案。

四、真相大白

4.1 案件侦破

此案一日不破，有如鲠在噎，寝食难安。脑中反复回放案发现场的周边布置，有一个非常重大的疑点进入脑海，其中有一个物件（BC_DEAD_BINDER_DONE协议)正常应该在其他房间(binder死亡讣告相关)，可为何会出现在案发现场(bindApplication的waitForResponse过程)呢？

基于最后的现场，顺着这个线索通过逆向推理分析，去试图推演凶手的整个作案过程。但对于如此错终复杂的案情(binder通信系统每时每刻都有大量的事transaction发生着，协议之间的转换也比较复杂)，仅凭一两个协议来逆向回推案发现场是如何一步步演化几乎是不太可能的事。跟同事一起讨论，通过不断逆向与正向结合分析，每一层逆向回推，都会有N种可能性，通过不断排除其他的可能性，尽可能多地排除完全不可能的分支，保留可能的分支再继续回推，最终奇迹般地找到了第一案发现场，也找到了复现方法。

这个逆向推理过程非常复杂，首先需要深入掌握Binder原理，在整个推演过程最为烧脑与费时。为了节省篇幅，此处省略一万字。

直接拿出结论，真正的第一案发现场如下：在进程刚启动不久，执行到linkToDeath()方法前的瞬间将其杀掉则能复现定屏：

Binder Driver缺陷导致定屏问题分析_第16张图片
14binder_ams_linktodeath

4.2 案卷解读

这个问题的复杂在于，即便找到了第一个案发现场以及复现路径，要完全理解中间的每一次协议转换过程，也是比较复杂的。
通过如下命令打开binder driver的ftrace信息，用于输出每次binder通信协议与数据。

15ftrace_on

整个binder通信会不断地在用户空间与内核空间之间进行切换, Binder IPC通信过程的数据流向说明：（ BINDER_WORK_XXX简称为BW_XXX）

  • mOut：记录用户空间向Binder Driver写入的命令
    • 通过binder_thread_write()和binder_transaction()方法消费BC命令，并产生相应的BW_XXX命令，也可能不产生BW命令
    • 当thread->return_error.cmd != BR_OK，则不会执行binder_thread_write()过程
  • thread→todo: 记录等待当前binder线程需要处理的BINDER_WORK
    • 通过binder_thread_read()方法消费BW命令，并生产相应的BR_XX命令，也可能不产生BR命令
    • 一般情况，没有BC_TRANSACION或者BC_REPLY，则不读取; BW_DEAD_BINDER例外；
  • mIn: 记录Binder Driver传到用户空间的命令
    • 通过waitForResponse()和executeCommand()方法消费BR命令

另外，关于talkWithDriver, 当mIn有数据，意味着先不需要从binder driver读数据。原因：needRead=0，则read_buffer size设置为0，当doReceive=true，则write_buffer size也设置为0。从而此次不会跟driver交互。

以下是一次定屏复现过程吐出的ftrace信息：

Binder:1885_5-2351 [002] ...1 242.804499: binder_ioctl: cmd=0xc0306201 arg=0x71f6ce6928
Binder:1885_5-2351 [002] ...1 242.804503: binder_command: cmd=0x40046304 BC_INCREFS
Binder:1885_5-2351 [002] ...1 242.804515: binder_command: cmd=0x40046305 BC_ACQUIRE
Binder:1885_5-2351 [002] ...1 242.804517: binder_command: cmd=0x400c630e BC_REQUEST_DEATH_NOTIFICATION
Binder:1885_5-2351 [002] ...1 242.804524: binder_write_done: ret=0
Binder:1885_5-2351 [002] ...1 242.804526: binder_ioctl_done: ret=0
 
Binder:1885_5-2351 [003] ...1 242.854847: binder_ioctl: cmd=0xc0306201 arg=0x71f6ce4f18
Binder:1885_5-2351 [003] ...1 242.854852: binder_command: cmd=0x40406300 BC_TRANSACTION // bindApplication()，
Binder:1885_5-2351 [003] ...1 242.854900: binder_write_done: ret=0
Binder:1885_5-2351 [003] ...1 242.854902: binder_wait_for_work: proc_work=0 transaction_stack=1 thread_todo=1
//binder_thread_read（）处理BINDER_WORK_DEAD_BINDER，生成BR_DEAD_BINDER
Binder:1885_5-2351 [003] ...1 242.854905: binder_return: cmd=0x8008720f BR_DEAD_BINDER
Binder:1885_5-2351 [003] ...1 242.854906: binder_read_done: ret=0
Binder:1885_5-2351 [003] ...1 242.854908: binder_ioctl_done: ret=0
 
Binder:1885_5-2351 [003] ...1 242.854920: binder_ioctl: cmd=0xc0306201 arg=0x71f6ce4d58
//既有可能是thread->return_error.cmd ！= BR_OK
Binder:1885_5-2351 [003] ...1 242.854922: binder_write_done: ret=0
Binder:1885_5-2351 [003] ...1 242.854923: binder_ioctl_done: ret=0
 
Binder:1885_5-2351 [003] ...1 242.863203: binder_ioctl: cmd=0xc0306201 arg=0x71f6ce1c08
Binder:1885_5-2351 [003] ...1 242.863258: binder_write_done: ret=0
Binder:1885_5-2351 [003] ...1 242.863263: binder_wait_for_work: proc_work=0 transaction_stack=1 thread_todo=1
//取出BINDER_WORK_RETURN_ERROR， BR_DEAD_REPLY， 此次炸死。BR_TRANSACTION_COMPLETE仅仅是打印错误
Binder:1885_5-2351 [003] ...1 242.863272: binder_return: cmd=0x7206 BR_TRANSACTION_COMPLETE
Binder:1885_5-2351 [003] ...1 242.863276: binder_read_done: ret=0
Binder:1885_5-2351 [003] ...1 242.863279: binder_ioctl_done: ret=0
 
// sendObituary（）
Binder:1885_5-2351 [003] ...1 242.868356: binder_ioctl: cmd=0xc0306201 arg=0x71f6ce31a8
Binder:1885_5-2351 [003] ...1 242.868392: binder_command: cmd=0x400c630f BC_CLEAR_DEATH_NOTIFICATION
//雷被拿了，return_error=BR_Ok才可以写； 将death->work.type由BINDER_WORK_DEAD_BINDER改为 BINDER_WORK_DEAD_BINDER_AND_CLEAR。
Binder:1885_5-2351 [003] ...1 242.868403: binder_command: cmd=0x40406300 BC_TRANSACTION //（同步）
Binder:1885_5-2351 [003] ...1 242.868707: binder_transaction: transaction=187839 dest_node=14103 dest_proc=2198 dest_thread=0 reply=0 flags=0x11 code=0x1f
Binder:1885_5-2351 [003] ...1 242.868734: binder_transaction_alloc_buf: transaction=187839 data_size=96 offsets_size=0
Binder:1885_5-2351 [003] ...1 242.868786: binder_command: cmd=0x40406300 BC_TRANSACTION //（异步）
Binder:1885_5-2351 [003] ...1 242.868802: binder_transaction: transaction=187840 dest_node=563 dest_proc=746 dest_thread=0 reply=0 flags=0x10 code=0x8
Binder:1885_5-2351 [003] ...1 242.868807: binder_transaction_alloc_buf: transaction=187840 data_size=1952 offsets_size=112
Binder:1885_5-2351 [003] ...2 242.868822: binder_transaction_ref_to_node: transaction=187840 node=37276 src_ref=37277 src_desc=940 ==> dest_ptr=0x00000079ba160780
Binder:1885_5-2351 [003] ...2 242.868829: binder_transaction_ref_to_node: transaction=187840 node=158140 src_ref=158141 src_desc=116 ==> dest_ptr=0x00000079ba03f6c0
Binder:1885_5-2351 [003] ...2 242.868833: binder_transaction_ref_to_node: transaction=187840 node=8192 src_ref=8193 src_desc=110 ==> dest_ptr=0x00000079bc81b220
Binder:1885_5-2351 [003] ...2 242.868837: binder_transaction_ref_to_node: transaction=187840 node=18544 src_ref=18545 src_desc=416 ==> dest_ptr=0x00000079ba1dbd20
Binder:1885_5-2351 [003] ...2 242.868839: binder_transaction_ref_to_node: transaction=187840 node=8192 src_ref=8193 src_desc=110 ==> dest_ptr=0x00000079bc81b220
Binder:1885_5-2351 [003] ...2 242.868842: binder_transaction_ref_to_node: transaction=187840 node=18659 src_ref=18660 src_desc=420 ==> dest_ptr=0x00000079bd0b3720
Binder:1885_5-2351 [003] ...2 242.868844: binder_transaction_ref_to_node: transaction=187840 node=8192 src_ref=8193 src_desc=110 ==> dest_ptr=0x00000079bc81b220
Binder:1885_5-2351 [003] ...2 242.868847: binder_transaction_ref_to_node: transaction=187840 node=18719 src_ref=18720 src_desc=423 ==> dest_ptr=0x00000079bd0b4120
Binder:1885_5-2351 [003] ...2 242.868849: binder_transaction_ref_to_node: transaction=187840 node=8192 src_ref=8193 src_desc=110 ==> dest_ptr=0x00000079bc81b220
Binder:1885_5-2351 [003] ...2 242.868852: binder_transaction_ref_to_node: transaction=187840 node=18919 src_ref=18920 src_desc=431 ==> dest_ptr=0x00000079ba1ba320
Binder:1885_5-2351 [003] ...2 242.868854: binder_transaction_ref_to_node: transaction=187840 node=8192 src_ref=8193 src_desc=110 ==> dest_ptr=0x00000079bc81b220
Binder:1885_5-2351 [003] ...2 242.868857: binder_transaction_ref_to_node: transaction=187840 node=18785 src_ref=18786 src_desc=425 ==> dest_ptr=0x00000079bd0b4a20
Binder:1885_5-2351 [003] ...2 242.868863: binder_transaction_ref_to_node: transaction=187840 node=130076 src_ref=130077 src_desc=1405 ==> dest_ptr=0x00000079ba03f060
Binder:1885_5-2351 [003] ...2 242.868867: binder_transaction_ref_to_node: transaction=187840 node=159857 src_ref=159858 src_desc=154 ==> dest_ptr=0x00000079ba160c40
Binder:1885_5-2351 [000] ...1 242.869114: binder_write_done: ret=0
Binder:1885_5-2351 [000] ...1 242.869117: binder_wait_for_work: proc_work=0 transaction_stack=1 thread_todo=1
Binder:1885_5-2351 [000] ...1 242.869120: binder_return: cmd=0x7206 BR_TRANSACTION_COMPLETE
Binder:1885_5-2351 [000] ...1 242.869122: binder_return: cmd=0x7206 BR_TRANSACTION_COMPLETE
Binder:1885_5-2351 [000] ...1 242.869124: binder_read_done: ret=0
Binder:1885_5-2351 [000] ...1 242.869126: binder_ioctl_done: ret=0
 
 
Binder:1885_5-2351 [000] ...1 242.869137: binder_ioctl: cmd=0xc0306201 arg=0x71f6ce31a8
Binder:1885_5-2351 [000] ...1 242.869140: binder_wait_for_work: proc_work=0 transaction_stack=1 thread_todo=0
Binder:1885_5-2351 [000] ...1 242.869195: binder_transaction_received: transaction=187841
Binder:1885_5-2351 [000] ...1 242.869198: binder_return: cmd=0x80407203 BR_REPLY
Binder:1885_5-2351 [000] ...1 242.869202: binder_read_done: ret=0
Binder:1885_5-2351 [000] ...1 242.869203: binder_ioctl_done: ret=0
 
 
Binder:1885_5-2351 [000] ...1 242.873656: binder_ioctl: cmd=0xc0306201 arg=0x71f6ce1e98
Binder:1885_5-2351 [000] ...1 242.873664: binder_command: cmd=0x40086303 BC_FREE_BUFFER
Binder:1885_5-2351 [000] ...1 242.873668: binder_transaction_buffer_release: transaction=187841 data_size=0 offsets_size=0
Binder:1885_5-2351 [000] ...1 242.873671: binder_command: cmd=0x40406300 BC_TRANSACTION
Binder:1885_5-2351 [000] ...1 242.873784: binder_transaction: transaction=187849 dest_node=127265 dest_proc=5730 dest_thread=0 reply=0 flags=0x11 code=0x31
Binder:1885_5-2351 [000] ...1 242.873787: binder_transaction_alloc_buf: transaction=187849 data_size=76 offsets_size=0
Binder:1885_5-2351 [000] ...1 242.873814: binder_write_done: ret=0
Binder:1885_5-2351 [000] ...1 242.873816: binder_wait_for_work: proc_work=0 transaction_stack=1 thread_todo=1
Binder:1885_5-2351 [000] ...1 242.873820: binder_return: cmd=0x7206 BR_TRANSACTION_COMPLETE
Binder:1885_5-2351 [000] ...1 242.873821: binder_read_done: ret=0
Binder:1885_5-2351 [000] ...1 242.873823: binder_ioctl_done: ret=0
 
Binder:1885_5-2351 [000] ...1 242.876271: binder_ioctl: cmd=0xc0306201 arg=0x71f6ce1e98
Binder:1885_5-2351 [000] ...1 242.876302: binder_command: cmd=0x40406300 BC_TRANSACTION
Binder:1885_5-2351 [000] ...1 242.876417: binder_transaction: transaction=187850 dest_node=23725 dest_proc=3051 dest_thread=0 reply=0 flags=0x11 code=0x31
Binder:1885_5-2351 [000] ...1 242.876423: binder_transaction_alloc_buf: transaction=187850 data_size=76 offsets_size=0
Binder:1885_5-2351 [000] ...1 242.876456: binder_write_done: ret=0
Binder:1885_5-2351 [000] ...1 242.876459: binder_wait_for_work: proc_work=0 transaction_stack=1 thread_todo=1
Binder:1885_5-2351 [000] ...1 242.876461: binder_return: cmd=0x7206 BR_TRANSACTION_COMPLETE
Binder:1885_5-2351 [000] ...1 242.876463: binder_read_done: ret=0
Binder:1885_5-2351 [000] ...1 242.876464: binder_ioctl_done: ret=0
// sendObituary（）结束
 
Binder:1885_5-2351 [000] ...1 242.886935: binder_ioctl: cmd=0xc0306201 arg=0x71f6ce4f18
Binder:1885_5-2351 [000] ...1 242.886975: binder_command: cmd=0x40086310 BC_DEAD_BINDER_DONE
Binder:1885_5-2351 [000] ...1 242.886980: binder_write_done: ret=0
Binder:1885_5-2351 [000] ...1 242.886984: binder_wait_for_work: proc_work=0 transaction_stack=1 thread_todo=1
Binder:1885_5-2351 [000] ...1 242.886993: binder_return: cmd=0x80087210 BR_CLEAR_DEATH_NOTIFICATION_DONE
Binder:1885_5-2351 [000] ...1 242.886996: binder_read_done: ret=0
Binder:1885_5-2351 [000] ...1 242.886999: binder_ioctl_done: ret=0
 
 
Binder:1885_5-2351 [000] ...1 242.887012: binder_ioctl: cmd=0xc0306201 arg=0x71f6ce4f18
Binder:1885_5-2351 [000] ...1 242.887013: binder_wait_for_work: proc_work=0 transaction_stack=1 thread_todo=0
Binder:1885_5-2351 [000] ...1 260.021887: binder_read_done: ret=-512
Binder:1885_5-2351 [000] ...1 260.021893: binder_ioctl_done: ret=-512
Binder:1885_5-2351 [000] ...1 260.023938: binder_ioctl: cmd=0xc0306201 arg=0x71f6ce4f18
Binder:1885_5-2351 [000] ...1 260.023972: binder_wait_for_work: proc_work=0 transaction_stack=1 thread_todo=0

将以上信息转换为表格形式来展示案发过程：

Binder Driver缺陷导致定屏问题分析_第17张图片
18oneway_binder_call_hang

以流程图的方式来展示案发过程：

Binder Driver缺陷导致定屏问题分析_第18张图片
16seq_binder

过程解读：

  1. 该线程执行linkToDeath()，采用flush只写不读的方式，向Binder Driver的thread todo队列写入BW_DEAD_BINDER；
  2. 执行bindApplication(), 由于目标进程已死，则写入BW_RETURN_ERROR到todo队列，此时return_error.cmd = BR_DEAD_REPLY;
    内核空间，将BW_DEAD_BINDER转换为BR_DEAD_BINDER，同步将BW_DEAD_BINDER 放入proc->delivered_death;
    回到用户空间，执行sendObituary()， 此时还处于bindApplication()的waitForResponse()。
  3. 向mOut添加BC_CLEAR_DEATH_NOTIFICATION，采用flush方式，加上return_error.cmd = BR_DEAD_REPLY，此次不写不读。
  4. 执行第一个reportOneDeath()，此时return_error.cmd = BR_DEAD_REPLY则不写入，取出BW_RETURN_ERROR，同时设置return_error.cmd=BR_OK；
    回到用户空间，终结第一个reportOneDeath()，错误地消耗了bindApplication()所产生的BR_DEAD_REPLY。
  5. 执行第二个reportOneDeath()，同时消耗了第一个和第二个reportOneDeath所产生的BR_TRANSACTION_COMPLETE协议，由于第二个reportOneDeath是同步binder call, 还需继续等待BR_REPLY协议。
  6. 此时mOut和mIn都为空，进入内核binder_wait_for_work(),等待目标进程发起BC_REPLY命令，向当前线程todo队列放入BW_TRANSACTION；收到BW_TRANSACTION协议后转换为BR_REPLY，完成第二个reportOneDeath()。
  7. 执行第三个reportOneDeath()，收到BR_TRANSACTION_COMPLETE后，完成第二个reportOneDeath()。
  8. 到此彻底执行完sendObituary()，则需向mOut添加BC_DEAD_BINDER_DONE协议，收到该协议后，驱动将proc→delivered_death的BW_DEAD_BINDER_AND_CLEAR调整为BW_CLEAR_DEATH_NOTIFICATION，并放入thread->todo队列；然后生成BR_CLEAR_DEATH_NOTIFICATION_DONE，完成本次通信；
  9. 回到bindApplication()的waitForResponse，此时mOut和mIn都为空，进入内核binder_wait_for_work(), 该线程不再接收其他事务，也无法产生事务，则永远地被卡住。

总结：整个过程发生了10次 talkWithDriver()

  • 第一个异步reportOneDeath()消费掉bindApplication()所产生的BW_RETURN_ERROR；
  • 第二个同步reportOneDeath()所消耗掉 第一个异步reportOneDeath()自身残留的BR_TRANSACTION_COMPLETE；
  • bindApplication()所产生的BW_RETURN_ERROR由于被别人所消费，导致陷入无尽地等待。

4.3 总结

真正分析远比这复杂，鉴于篇幅，文章只讲解其中一个场景，不同的Binder Driver以及不同的Framework代码组合有几种不同的表现与处理流程。不过最本质的问题都是在于在嵌套的binder通信过程，BR_DEAD_REPLY错误地被其他通信所消耗从而导致的异常。我的解决方案是一旦发生错误，则当BW_RETURN_ERROR事务放入到当前线程todo队列头部，则保证自己产生的BW_RETURN_ERROR事务一定会被自己所正确地消耗，解决异步binder通信在嵌套场景下的无限阻塞的问题，优化后的处理流程图：

Binder Driver缺陷导致定屏问题分析_第19张图片
17seq_binder_ok

当然还有第二个解决方案就是尽可能避免一切binder嵌套，Google在最新的binder driver驱动里面采用将BW_DEAD_BINDER放入proc的todo队列来避免嵌套问题，这个方案本身也OK，但我认为在执行过程出现了BW_RETURN_ERROR还是应该放到队列头部，第一时间处理error，从而也能避免被错误消耗的BUG，另外后续如果binder新增其他逻辑，也有可能会导致嵌套的出现，那么仍然会有类似的问题。最近跟Google工程师来回多次沟通过这个问题，他们仍然希望保持每次只往thread todo队列尾部添加事务的逻辑，对于嵌套问题希望通过将其放入proc todo队列的方式来解决。对此，我担心后续扩展性方面会忽略或者遗忘，又引发binder嵌套问题，Google工程师表示未来添加新功能，也会杜绝出现嵌套逻辑，保持逻辑与代码的简洁。

最后，这个密室杀人案的确是在它处作案(reportOneDeath消费掉bindApplication所产生的BW_RETURN_ERROR)后，再移尸到当前案发现场(执行完BR_DEAD_BINDER后回到bindApplication的waitForRespone方法)，从而导致异步Binder调用也能被阻塞。

你可能感兴趣的:(Binder Driver缺陷导致定屏问题分析)

  • 学点心理知识，呵护孩子健康 静候花开_7090
    昨天听了华中师范大学教育管理学系副教授张玲老师的《哪里才是学生心理健康的最后庇护所，超越教育与技术的思考》的讲座。今天又重新学习了一遍，收获匪浅。张玲博士也注意到了当今社会上的孩子由于心理问题导致的自残、自杀及伤害他人等恶性事件。她向我们普及了一个重要的命题，她说心理健康的一些基本命题，我们与我们通常的一些教育命题是不同的，她还举了几个例子，让我们明白我们原来以为的健康并非心理学上的健康。比如如果
  • Cell Insight | 单细胞测序技术又一新发现，可用于HIV-1和Mtb共感染个体诊断 尐尐呅
    结核病是艾滋病合并其他疾病中导致患者死亡的主要原因。其中结核病由结核分枝杆菌（Mycobacteriumtuberculosis,Mtb）感染引起，获得性免疫缺陷综合症（艾滋病）由人免疫缺陷病毒（Humanimmunodeficiencyvirustype1,HIV-1）感染引起。国家感染性疾病临床医学研究中心/深圳市第三人民医院张国良团队携手深圳华大生命科学研究院吴靓团队，共同研究得出单细胞测序
  • 直返最高等级与直返APP：无需邀请码的返利新体验 古楼
    随着互联网的普及和电商的兴起，直返模式逐渐成为一种流行的商业模式。在这种模式下，消费者通过购买产品或服务，获得一定的返利，并可以分享给更多的人。其中，直返最高等级和直返APP是直返模式中的重要概念和工具。本文将详细介绍直返最高等级的概念、直返APP的使用以及与邀请码的关系。【高省】APP（高佣金领导者）是一个自用省钱佣金高，分享推广赚钱多的平台，百度有几百万篇报道，运行三年，稳定可靠。高省APP，
  • ARM驱动学习之5 LEDS驱动 JT灬新一 嵌入式C底层arm开发学习单片机
    ARM驱动学习之5LEDS驱动知识点：•linuxGPIO申请函数和赋值函数–gpio_request–gpio_set_value•三星平台配置GPIO函数–s3c_gpio_cfgpin•GPIO配置输出模式的宏变量–S3C_GPIO_OUTPUT注意点：DRIVER_NAME和DEVICE_NAME匹配。实现步骤：1.加入需要的头文件：//Linux平台的gpio头文件#include//三
  • 直返APP是什么?直返APP是干嘛的 氧惠帮朋友一起省
    直返是一种电商购物模式，其核心特点是用户购买商品后可以获得直接返利。具体来说，用户在直返电商平台购买商品时，不仅可以获得商品本身的优惠，还可以获得一定的现金返利或者积分奖励。返利的金额可以提现到用户的账户余额，或者用于下次购物时抵扣。氧惠APP（带货领导者）——是与以往完全不同的抖客+淘客app！2023全新模式，我的直推也会放到你下面。主打：带货高补贴，深受各位带货团队长喜爱（每天出单带货几十万
  • EIO国际确定性的交易（3/10）资管 ， 资金委托安全吗？ 古城鹏哥
    大家可能都知道资金托管，账户是自己开，钱在自己的账户上，密码是由自己掌控，别人提不走你账户的资金，每天可以看下到自己的账户，也可以看到交易流水。现金只能提到自己的银行卡中。账户由技术人员或操作人员，或者是机构团队帮你操作账户，产生盈利和收入，以获得的利润来分配盈利，技术强硬和做的时间久了过硬技术团队，会保证你的资金本金，不会让你的本金亏损的按照一定比例分配收入。所以在这个过程当中一定要看清楚技术的
  • ExpRe[25] bash外的其它shell：zsh和fish tritone ExpRebashlinuxubuntushell
    文章目录zsh基础配置实用特性插件`autojump`语法高亮自动补全fish优点缺点时效性本篇撰写时间为2021.12.15，由于计算机技术日新月异，博客中所有内容都有时效和版本限制，具体做法不一定总行得通，链接可能改动失效，各种软件的用法可能有修改。但是其中透露的思想往往是值得学习的。本篇前置：ExpRe[10]Ubuntu[2]准备神秘软件、备份恢复软件https://www.cnblogs
  • 社保应该缴15年还是25年？那种方式最划算？ 袋鼠观保保险规划师
    社保无论是缴费15年还是25年，影响最大的就是养老保险和医疗保险，缴费时间越长越有利！1.养老保险真的交满15年就够了吗？要知道，社保缴费时长，直接影响到退休后能拿多少养老金，而且交得越久，退休领得越多。我拿深圳作为例子，想拿到养老金必须满足两个条件：只要达到一定的退休年龄，养老保险累计交满15年就可以拿到养老金了。那如果多缴了20年、25年甚至30年，是不是浪费了？实际上，缴满15年只是刚好可以
  • TDengine 签约前晨汽车，解锁智能出行的无限潜力 涛思数据（TDengine） tdengine汽车大数据
    在全球汽车产业转型升级的背景下，智能网联和新能源技术正迅速成为商用车行业的重要发展方向。随着市场对环保和智能化需求的日益增强，企业必须在技术创新和数据管理上不断突破，以满足客户对高效、安全和智能出行的期待。在这一背景下，前晨汽车凭借其在新能源智能商用车领域的前瞻性布局和技术实力，成为行业中的佼佼者。前晨汽车采用整车数据采集和全车数据打通策略，能够实时将数据推送至APP端客户。然而，这导致整体写入和
  • 童年那些故事教给我们的 山川大地日月星辰
    同事的女儿二次考研失败，但是仍不气馁还想接着再学再考，得为孩子点个赞，可是同事很矛盾，以她的意见，当初女儿大学毕业就该直接考编，回到家过安稳日子，我问她还记不记得《小马过河》的故事？她说跟小马有啥关系？幼儿园就给孩子讲《小马过河》，当然孩子们除了喜欢故事里的“人物”小松鼠、老牛、小马跟老马，对小马爱劳动喜欢帮助妈妈干活也是有基本认知的，孩子们对为什么老牛说水浅、而松鼠说水深也有一定的常识，到了成人
  • 关于Mysql 中 Row size too large (＞ 8126) 错误的解决和理解 秋刀prince mysqlmysql数据库
    提示：啰嗦一嘴，数据库的任何操作和验证前，一定要记得先备份！！！不会有错；文章目录问题发现一、问题导致的可能原因1、页大小2、行格式2.1compact格式2.2Redundant格式2.3Dynamic格式2.4Compressed格式3、BLOB和TEXT列二、解决办法1、修改页大小（不推荐）2、修改行格式3、修改数据类型为BLOB和TEXT列4、其他优化方式（可以参考使用）4.1合理设置数据
  • 2.2.6 通知类控件 Toast、Menu 常思行
    本文例程下载：WillFlow_Toast、WillFlowMenu一、什么是Toast？Toast也被叫做吐司，是Android系统提供的一种非常好的提醒方式，在程序中可以使用它将一些短小的信息通知给用户，它有如下两个特点：Toast是没有焦点的Toast显示的时间有限过一定的时间就会自动消失所以一般来讲Toast的使用并不会影响我们的正常操作，并且它通常不会占用太大的屏幕空间，有着良好的用户体
  • 二婚到底是领证好还是不领证好？ 孟妃青
    伟人讲过，不以结婚为目的的谈恋爱，都是耍流氓！离婚了，再找对象，感情到了一定程度，领证结婚是水到渠成的事，再说我中华泱泱大国，有礼仪之邦的称谓，领证更是体现了尊重男女双方的行为。如果认为二婚就没必要领证了，只能说明，男女之间都暗藏心思，心不往一处走，日子过不好的。即便他们感情再深，都不是合法夫妻，只是名不正言不顺的同居关系。假如不要二人共同的孩子还好，就怕有了孩子，没领证，到时给孩子上户口都成问题
  • 2020-8-19晨间日记：看过的电影 盐大虾
    今天是周三起床：6点半就寝：11点天气：晴心情：正常纪念日：周三任务清单今日完成的任务，最重要的三件事：1.整理写过的文档2.电影《电灯泡》3.这就是街舞第三季第五期改进：早睡早起习惯养成：早睡早起，看书周目标·完成进度两篇文章学习·信息·阅读电影艺术发展史相关教材健康·饮食·锻炼吃了挺多零食，还喝了果粒橙，还是得少吃，多锻炼，不然会慢慢死掉的。人际·家人·朋友淡定交流，不放在心上。工作·思考专心
  • 5分钟说透AppStore审核原理，让你拥有上架新思路！ Q仔本人噢
    在AppStore上架是越来越难了!相信非常多公司的技术人员都为此困扰，然而外包团队水平又层次不齐，容易遇坑，实在是内忧外患。是什么原因导致审核机制频繁调整？又是什么原因使得审核变得越发严格？那么接下来听小Q分解，马上给各位带来解答!首先看一下近一年的上下架的情况：近一年上架情况近一年下架情况通过数据我们发现越是马甲包产量权重高的分类里被下架的app数量越多，苹果此举可谓是上有政策，下有对策。通过
  • 2023-06-19【感恩日记】第246篇 o泡沫o
    思想日记：坚持下去，相信自己一定可以的【感恩日记】第246篇1.我真是太幸福啦！感恩孩子早起阅读，放学到学生之家完成作业，平安度过美好的一天。感恩！感恩！感恩！❤️2.我真是太幸福啦！感恩自己早起给孩子煮早餐，完成计划的工作，晚上学习。感恩！感恩！感恩！❤️3.我真是太幸福啦！感恩为我设计效果图的老师。感恩！感恩！感恩！❤️4.我真是太幸福啦！感恩父母养育了我，有妈的孩子真幸福。感恩！感恩！感恩！
  • 【ARM Cortex-M 系列 2.3 -- Cortex-M7 Debug event 详细介绍】 主公讲 ARM #ARM系列arm开发debugevent
    请阅读【嵌入式开发学习必备专栏】文章目录Cortex-M7DebugeventDebugeventsCortex-M7Debugevent在ARMCortex-M7架构中，调试事件（DebugEvent）是由于调试原因而触发的事件。一个调试事件会导致以下几种情况之一发生：进入调试状态：如果启用了停滞调试（HaltingDebug），一个调试事件会使处理器在调试状态下停滞。通过将DHCSR.C_DE
  • 笋丁网页自动回复机器人V3.0.0免授权版源码 希希分享 软希网58soho_cn源码资源笋丁网页自动回复机器人
    笋丁网页机器人一款可设置自动回复，默认消息，调用自定义api接口的网页机器人。此程序后端语言使用Golang，内存占用最高不超过30MB，1H1G服务器流畅运行。仅支持Linux服务器部署，不支持虚拟主机，请悉知！使用自定义api功能需要有一定的建站基础。源码下载：https://download.csdn.net/download/m0_66047725/89754250更多资源下载：关注我。安
  • Spring MVC 全面指南：从入门到精通的详细解析 一杯梅子酱 技术栈学习springmvcjava
    引言：SpringMVC，作为Spring框架的一个重要模块，为构建Web应用提供了强大的功能和灵活性。无论是初学者还是有一定经验的开发者，掌握SpringMVC都将显著提升你的Web开发技能。本文旨在为初学者提供一个全面且易于理解的学习路径，通过详细的知识点分析和实际案例，帮助你快速上手SpringMVC，让学习过程既深刻又高效。一、SpringMVC简介1.1什么是SpringMVC？Spri
  • 深入浅出 -- 系统架构之负载均衡Nginx的性能优化 xiaoli8748_软件开发 系统架构系统架构负载均衡nginx
    一、Nginx性能优化到这里文章的篇幅较长了，最后再来聊一下关于Nginx的性能优化，主要就简单说说收益最高的几个优化项，在这块就不再展开叙述了，毕竟影响性能都有多方面原因导致的，比如网络、服务器硬件、操作系统、后端服务、程序自身、数据库服务等，对于性能调优比较感兴趣的可以参考之前《JVM性能调优》中的调优思想。优化一：打开长连接配置通常Nginx作为代理服务，负责分发客户端的请求，那么建议开启H
  • 人要有自知之明 孟冬廿六
    今天中午跟一学妹聊天，谈起结婚找对象的问题，小姑娘年龄不算大，二十七岁，但是整个人很清醒很现实，她如今在一国企上班，吃住都不花钱，再加上她经常出差，补助奖金这一块儿也不少，一年下来七七八八的有个小二十万，这对于一个小姑娘来说已经非常不错了，她计划这两年自己付首付买房，然后想要买辆MINI，小姑娘一米七六的个子，长得漂亮有气质，家庭条件也不错，所以对于择偶方面也有一定的要求，最好是事业单位的，父母有
  • Python 课程10-单元测试 可愛小吉 Python教學python单元测试开发语言TDDunittest
    前言在现代软件开发中，单元测试已成为一种必不可少的实践。通过测试，我们可以确保每个功能模块在开发和修改过程中按预期工作，从而减少软件缺陷，提高代码质量。而测试驱动开发（TDD）则进一步将测试作为开发的核心部分，先编写测试，再编写代码，以测试为指导开发出更稳定、更可靠的代码。Python提供了强大的unittest模块，它是Python标准库的一部分，专门用于编写和执行单元测试。与其他测试框架相比，
  • 误落尘网中，一去三十年 不会功夫的谭大侠
    图片发自App图片发自App图片发自App《财富自由之路》中开篇就讲述了财富自由的目的是为了时间自由，高中觉得每个月一千块是财富自由，大学觉得每个月两千块是财富自由，毕业时觉得每个月五千是财富自由，现在感觉每个月一万都不一定自由。思来想去，货币贬值也没有这么快，还是自己欲望太大了，欲壑难填。大学有一个梦想去西藏，当时觉得两千块就能去，现在感觉有一万都不够。膨胀了啊！曾经想过时间自由了干什么，我就半
  • RabbitMQ生产者重复机制与确认机制 java炒饭小能手 java-rabbitmqrabbitmqjava
    重复机制生产者发送消息时，出现了网络故障，导致与MQ的连接中断。为了解决这个问题，SpringAMQP提供的消息发送时的重试机制。即：当RabbitTemplate与MQ连接超时后，多次重试。需要修该发送端模块的application.yaml文件，添加下面的内容：spring:rabbitmq:connection-timeout:1s#设置MQ的连接超时时间template:retry:ena
  • 解决Obsidian写笔记中的＜img＞标签无法显示图片的问题 全能全知者 笔记
    Obsidian中写md笔记如果使用标签会显示不出图案，后来才知道因为Obsidian的问题导致只能用绝对路径定位。所以我本人写了一个py插件，将md笔记里的img标签批量替换成Obsidian能够读取的形式。安装FixObsImgDpy:pipinstallFixObsImgDpy安装完成后在需要修复的md文件的父目录下运行命令:FixObsImgDpy就会自动修复父目录以下的全部md文件 仓库
  • 如何自学软件编程？零基础自学编程入门指南 _pangzi
    前言零基础自学编程的动力是什么?在开启学习编程之路的时候必须搞清楚自己为什么要学编程?是因为工资高?还是对编程有浓厚的兴趣？还有自己有一定的编程基础想要继续提升自己？其实对于这个问题需要具体分析，如果是单纯看到程序员工资高，而自己本身并没有什么兴趣，那我不建议自学，可以选择参加培训或者不要进入编程领域不然自己学不会没有获得高薪，反而浪费了大把的时间，如果方法不对，反而会打击自信心。下面小编针对学习
  • 辰辰日记四十四 谷子
    昨天是重阳节，当然我们都没有刻意提起这个节日，似乎并不重要，生长在城市，连爬山都不是寻常事。人人都是忙碌之人，虽然人人也都难以说清自己都在忙些什么。其实这一天以又是你外婆的生日。原来妈妈想好给外婆买一双鞋子，不过，这段时间外婆生病了。病得挺严重，无法睡眠，不能行走。辰辰，你一定不能想象这是一种什么情况，人怎么会无法睡觉，躺不下床。当人颈椎有伤，且血管不通畅就会这样。你一躺下就整个人头晕目眩。那就是
  • 100天持续行动—Day01 Richard_DL
    今天开始站着学习，发现效率大幅提升。把fast.ai的Lesson1的后半部分和Lesson2看完了。由于Keras版本和视频中的不一致，运行notebook时经常出现莫名其妙的错误，导致自己只动手实践了视频中的一小部分内容。为了赶时间，我打算先把与CNN相关的视频过一遍。然后尽快开始做自己的项目。明天继续加油，争取把Lesson3和Lesson4看完。
  • 四个男人的坦言：让男人念念不忘的女人，很爱“惹麻烦” 霜粉
    或许，在许多女人看来，令男人恋恋不忘的，一定是那个令他情窦初开的女人，抑或是那个他爱而不得的人，甚至有可能是那个当初和他在一起时，对他百般温柔和眷恋的女人。其实，很多时候，令男人恋恋不忘的，都并不是这几种女人。自然，这几种女人可能带给了男人独特的感受，给他的人生旅途间带来了片刻的精彩。可是，这却未必就是他日后难以忘怀的女人。那些让男人念念不忘的女人，她不一定青春年少，也不一定美丽动人，但她一定是在
  • c++ 内存处理函数 heeheeai c++开发语言
    在C语言的头文件中，memcpy和memmove函数都用于复制内存块，但它们在处理内存重叠方面存在关键区别：内存重叠:memcpy函数不保证在源内存和目标内存区域重叠时能够正确复制数据。如果内存区域重叠，memcpy的行为是未定义的，可能会导致数据损坏或程序崩溃。memmove函数能够安全地处理源内存和目标内存区域重叠的情况。它会确保在复制过程中不会覆盖尚未复制的数据，从而保证数据的完整性。效率:
  • jvm调优总结（从基本概念 到 深度优化） oloz javajvmjdk虚拟机应用服务器
    JVM参数详解：http://www.cnblogs.com/redcreen/archive/2011/05/04/2037057.html   Java虚拟机中，数据类型可以分为两类：基本类型和引用类型。基本类型的变量保存原始值，即：他代表的值就是数值本身；而引用类型的变量保存引用值。“引用值”代表了某个对象的引用，而不是对象本身，对象本身存放在这个引用值所表示的地址的位置。
  • 【Scala十六】Scala核心十：柯里化函数 bit1129 scala
    本篇文章重点说明什么是函数柯里化，这个语法现象的背后动机是什么，有什么样的应用场景，以及与部分应用函数(Partial Applied Function)之间的联系   1. 什么是柯里化函数 A way to write functions with multiple parameter lists. For instance def f(x: Int)(y: Int) is a
  • HashMap dalan_123 java
    HashMap在java中对很多人来说都是熟的；基于hash表的map接口的非同步实现。允许使用null和null键；同时不能保证元素的顺序；也就是从来都不保证其中的元素的顺序恒久不变。 1、数据结构     在java中，最基本的数据结构无外乎：数组 和 引用（指针），所有的数据结构都可以用这两个来构造，HashMap也不例外，归根到底HashMap就是一个链表散列的数据
  • Java Swing如何实时刷新JTextArea，以显示刚才加append的内容 周凡杨 java更新swingJTextArea
    在代码中执行完textArea.append("message")后，如果你想让这个更新立刻显示在界面上而不是等swing的主线程返回后刷新，我们一般会在该语句后调用textArea.invalidate()和textArea.repaint()。 问题是这个方法并不能有任何效果，textArea的内容没有任何变化，这或许是swing的一个bug，有一个笨拙的办法可以实现
  • servlet或struts的Action处理ajax请求 g21121 servlet
    其实处理ajax的请求非常简单，直接看代码就行了： //如果用的是struts //HttpServletResponse response = ServletActionContext.getResponse(); // 设置输出为文字流 response.setContentType("text/plain"); // 设置字符集 res
  • FineReport的公式编辑框的语法简介 老A不折腾 finereport公式总结
    FINEREPORT用到公式的地方非常多，单元格（以=开头的便被解析为公式），条件显示，数据字典，报表填报属性值定义，图表标题，轴定义，页眉页脚，甚至单元格的其他属性中的鼠标悬浮提示内容都可以写公式。 简单的说下自己感觉的公式要注意的几个地方：   1.if语句语法刚接触感觉比较奇怪，if(条件式子,值1,值2)，if可以嵌套，if(条件式子1，值1，if(条件式子2，值2，值3)
  • linux mysql 数据库乱码的解决办法 墙头上一根草 linuxmysql数据库乱码
    linux 上mysql数据库区分大小写的配置 lower_case_table_names=1 1-不区分大小写 0-区分大小写   修改/etc/my.cnf 具体的修改内容如下:   [client] default-character-set=utf8   [mysqld] datadir=/var/lib/mysql socket=/va
  • 我的spring学习笔记6-ApplicationContext实例化的参数兼容思想 aijuans Spring 3
    ApplicationContext能读取多个Bean定义文件，方法是： ApplicationContext appContext = new ClassPathXmlApplicationContext（ new String[]｛“bean-config1.xml”，“bean-config2.xml”，“bean-config3.xml”，“bean-config4.xml
  • mysql 基准测试之sysbench annan211 基准测试mysql基准测试MySQL测试sysbench
    1 执行如下命令，安装sysbench-0.5： tar xzvf sysbench-0.5.tar.gz  cd sysbench-0.5  chmod +x autogen.sh  ./autogen.sh  ./configure --with-mysql --with-mysql-includes=/usr/local/mysql
  • sql的复杂查询使用案列与技巧 百合不是茶 oraclesql函数数据分页合并查询
      本片博客使用的数据库表是oracle中的scott用户表;          -------------------  自然连接查询           查询 smith 的上司(两种方法) &
  • 深入学习Thread类 bijian1013 javathread多线程java多线程
    一．             线程的名字 下面来看一下Thread类的name属性，它的类型是String。它其实就是线程的名字。在Thread类中，有String getName()和void setName(String)两个方法用来设置和获取这个属性的值。 同时，Thr
  • JSON串转换成Map以及如何转换到对应的数据类型 bijian1013 javafastjsonnet.sf.json
            在实际开发中，难免会碰到JSON串转换成Map的情况，下面来看看这方面的实例。另外，由于fastjson只支持JDK1.5及以上版本，因此在JDK1.4的项目中可以采用net.sf.json来处理。 一.fastjson实例 JsonUtil.java package com.study; impor
  • 【RPC框架HttpInvoker一】HttpInvoker：Spring自带RPC框架 bit1129 spring
    HttpInvoker是Spring原生的RPC调用框架，HttpInvoker同Burlap和Hessian一样，提供了一致的服务Exporter以及客户端的服务代理工厂Bean，这篇文章主要是复制粘贴了Hessian与Spring集成一文，【RPC框架Hessian四】Hessian与Spring集成   在 【RPC框架Hessian二】Hessian 对象序列化和反序列化一文中
  • 【Mahout二】基于Mahout CBayes算法的20newsgroup的脚本分析 bit1129 Mahout
    #!/bin/bash # # Licensed to the Apache Software Foundation (ASF) under one or more # contributor license agreements. See the NOTICE file distributed with # this work for additional information re
  • nginx三种获取用户真实ip的方法 ronin47
    随着nginx的迅速崛起，越来越多公司将apache更换成nginx. 同时也越来越多人使用nginx作为负载均衡, 并且代理前面可能还加上了CDN加速，但是随之也遇到一个问题：nginx如何获取用户的真实IP地址,如果后端是apache,请跳转到<apache获取用户真实IP地址>，如果是后端真实服务器是nginx，那么继续往下看。 实例环境： 用户IP 120.22.11.11
  • java-判断二叉树是不是平衡 bylijinnan java
    参考了 http://zhedahht.blog.163.com/blog/static/25411174201142733927831/ 但是用java来实现有一个问题。 由于Java无法像C那样“传递参数的地址，函数返回时能得到参数的值”，唯有新建一个辅助类：AuxClass import ljn.help.*; public class BalancedBTree {
  • BeanUtils.copyProperties VS PropertyUtils.copyProperties 诸葛不亮 PropertyUtilsBeanUtils
     BeanUtils.copyProperties VS  PropertyUtils.copyProperties  作为两个bean属性copy的工具类，他们被广泛使用，同时也很容易误用，给人造成困然；比如：昨天发现同事在使用BeanUtils.copyProperties copy有integer类型属性的bean时，没有考虑到会将null转换为0，而后面的业
  • [金融与信息安全]最简单的数据结构最安全 comsci 数据结构
          现在最流行的数据库的数据存储文件都具有复杂的文件头格式，用操作系统的记事本软件是无法正常浏览的，这样的情况会有什么问题呢？        从信息安全的角度来看，如果我们数据库系统仅仅把这种格式的数据文件做异地备份，如果相同版本的所有数据库管理系统都同时被攻击，那么
  • vi区段删除 Cwind linuxvi区段删除
    区段删除是编辑和分析一些冗长的配置文件或日志文件时比较常用的操作。简记下vi区段删除要点备忘。   vi概述    引文中并未将末行模式单独列为一种模式。单不单列并不重要，能区分命令模式与末行模式即可。   vi区段删除步骤： 1. 在末行模式下使用:set nu显示行号 非必须，随光标移动vi右下角也会显示行号，能够正确找到并记录删除开始行
  • 清除tomcat缓存的方法总结 dashuaifu tomcat缓存
    用tomcat容器，大家可能会发现这样的问题，修改jsp文件后，但用IE打开 依然是以前的Jsp的页面。 出现这种现象的原因主要是tomcat缓存的原因。 解决办法如下: 在jsp文件头加上 <meta http-equiv="Expires" content="0"> <meta http-equiv="kiben&qu
  • 不要盲目的在项目中使用LESS CSS dcj3sjt126com Webless
    　如果你还不知道LESS CSS是什么东西，可以看一下这篇文章，是我一朋友写给新人看的《CSS——LESS》 　　不可否认，LESS CSS是个强大的工具，它弥补了css没有变量、无法运算等一些“先天缺陷”，但它似乎给我一种错觉，就是为了功能而实现功能。 　　比如它的引用功能 ? .rounded_corners{     
  • [入门]更上一层楼 dcj3sjt126com PHPyii2
    更上一层楼 通篇阅读完整个“入门”部分，你就完成了一个完整 Yii 应用的创建。在此过程中你学到了如何实现一些常用功能，例如通过 HTML 表单从用户那获取数据，从数据库中获取数据并以分页形式显示。你还学到了如何通过 Gii 去自动生成代码。使用 Gii 生成代码把 Web 开发中多数繁杂的过程转化为仅仅填写几个表单就行。 本章将介绍一些有助于更好使用 Yii 的资源：
  • Apache HttpClient使用详解 eksliang httpclienthttp协议
    Http协议的重要性相信不用我多说了，HttpClient相比传统JDK自带的URLConnection，增加了易用性和灵活性（具体区别，日后我们再讨论），它不仅是客户端发送Http请求变得容易，而且也方便了开发人员测试接口（基于Http协议的），即提高了开发的效率，也方便提高代码的健壮性。因此熟练掌握HttpClient是很重要的必修内容，掌握HttpClient后，相信对于Http协议的了解会
  • zxing二维码扫描功能 gundumw100 androidzxing
    经常要用到二维码扫描功能 现给出示例代码 import com.google.zxing.WriterException; import com.zxing.activity.CaptureActivity; import com.zxing.encoding.EncodingHandler; import android.app.Activity; import an
  • 纯HTML+CSS带说明的黄色导航菜单 ini htmlWebhtml5csshovertree
    HoverTree带说明的CSS菜单:纯HTML+CSS结构链接带说明的黄色导航   在线体验效果：http://hovertree.com/texiao/css/1.htm代码如下,保存到HTML文件可以看到效果：   <!DOCTYPE html > <html > <head> <title>HoverTree
  • fastjson初始化对性能的影响 kane_xie fastjson序列化
    之前在项目中序列化是用thrift，性能一般，而且需要用编译器生成新的类，在序列化和反序列化的时候感觉很繁琐，因此想转到json阵营。对比了jackson，gson等框架之后，决定用fastjson，为什么呢，因为看名字感觉很快。。。   网上的说法：   fastjson 是一个性能很好的 Java 语言实现的 JSON 解析器和生成器，来自阿里巴巴的工程师开发。
  • 基于Mybatis封装的增删改查实现通用自动化sql mengqingyu DAO
    1.基于map或javaBean的增删改查可实现不写dao接口和实现类以及xml，有效的提高开发速度。 2.支持自定义注解包括主键生成、列重复验证、列名、表名等 3.支持批量插入、批量更新、批量删除 <bean id="dynamicSqlSessionTemplate" class="com.mqy.mybatis.support.Dynamic
  • js控制input输入框的方法封装(数字，中文，字母，浮点数等) qifeifei javascript js
    在项目开发的时候，经常有一些输入框，控制输入的格式，而不是等输入好了再去检查格式，格式错了就报错，体验不好。 /** 数字，中文，字母,浮点数(+/-/.) 类型输入限制，只要在input标签上加上 jInput="number,chinese,alphabet,floating" 备注：floating属性只能单独用*/     funct
  • java 计时器应用 tangqi609567707 javatimer
    mport java.util.TimerTask;   import java.util.Calendar;   public class MyTask extends TimerTask {        private static final int
  • erlang输出调用栈信息 wudixiaotie erlang
    在erlang otp的开发中，如果调用第三方的应用，会有有些错误会不打印栈信息，因为有可能第三方应用会catch然后输出自己的错误信息，所以对排查bug有很大的阻碍，这样就要求我们自己打印调用的栈信息。用这个函数：erlang:process_display (self (), backtrace).需要注意这个函数只会输出到标准错误输出。 也可以用这个函数：erlang:get_s
按字母分类： ABCDEFGHIJKLMNOPQRSTUVWXYZ其他