Android Tombstone 与Debuggerd 原理浅谈

news2024/12/28 20:45:53

一、前言

Android系统类问题主要有stabilityperformancepowersecurityAndroid集成一个守护进程tombstonedandroid平台的一个守护进程,它注册成3socket服务端,客户端封装在crash_dumpdebuggerd_client crash_dump用于跟踪定位C++ crash debuggerd_client用于在某些场景(发生ANRwatchdogshell执行debuggerd -bdump指定进程 backtrace

二、tombstone原理

1,ELF程序加载过程

在进入execve()系统调用之后,Linux内核就开始进行真正的装配工作。在内核中,execve()系统调用相应的入口是sys_execve()sys_execve()进行一些参数的检查复制之后,调用do_execve()do_execve()会首先查找被执行的文件,如果找到文件,则读取文件的前128个字节。文件的前128个字节保存着可执行文件的格式信息,特别是前四个字节(魔数)。这样可以根据不同的可执行文件信息,来调用不同的装载模块。当do_execve()读取了这128个字节的文件头部之后,然后调用search_binary_handle()去搜索和匹配合适的可执行文件装载处理。linux中所有被支持的可执行文件格式都有相应的装载处理过程。search_binary_handle()会通过判断文件头部的魔数确定文件的格式,并且调用相应的过程。ELF可执行文件的装载处理过程叫做load_elf_binary()load_elf_binary()被定义在fs/Binfmt_elf.c。它的主要步骤是:

1. 检查ELF可执行文件格式的有效性,比如魔数,程序头表中段(Segment)的数量

2. 寻找动态链接的“.interp段,设置动态连接器路径(与动态链接有关)

3. 根据ELF可执行文件的程序头表的描述,对ELF文件进行映射,比如代码、数据、只读数据。

4. 初始化ELF进程环境,比如进程启动时EDX寄存器的地址应该是DT_FINI的地址。

5. 将系统调用的返回地址修改成ELF可执行文件的入口点,这个入口点取决于程序的链接方式,对于静态链接的ELF可执行文件,这个程序入口就是ELF文件的文件头中e_entry所指的地址;对于动态链接的ELF可执行文件,程序入口点是动态连接器。

当load_elf_binary()执行完毕,返回至do_execve()再返回到sys_execve(),上面的第5步中已经把系统调用的返回地址改成了被装载的ELF程序的入口地址了。所以当sys_execve()系统调用从内核态返回到用户态时,EIP寄存器存放下一个机器指令的地址, 直接跳转到了ELF程序的入口地址了,于是新的程序开始执行,ELF可执行文件装载完成。

execve() 执行过程中,系统会清掉 fork() 复制的原程序的页目录和页表项,并释放对应页面。系统仅为新加载的程序代码重新设置进程数据结构中的信息,申请和映射了命令行参数和环境参数块所占的内存页面,以及设置了执行代码执行点。此时内核并不从执行文件所在块设备上加载程序的代码和数据。当该过程返回时即开始执行新的程序,但一开始执行肯定会引起缺页异常中断发生。因为代码和数据还未被从块设备上读入内存。此时缺页异常处理程序会根据引起异常的线性地址在主内存区为新程序申请内存页面(内存帧),并从块设备上读入引起异常的指定页面。同时还为该线性地址设置对应的页目录项和页表项。这种加载执行文件的方法称为需求加载(Load on demand)。

2,Android Linker

--dynamic-linker编译参数的ELF文件会加载为静态可执行程序,如init进程:

Android大部分可执行程序使用linker做动态连接器,编译时候加上参数 --dynamic-linker

除了init进程,recoveryadbd进程也没有配置--dynamic-linker链接器。他们在Android.mk里面声明LOCAL_FORCE_STATIC_EXECUTABLE := true或者在Android.bp声明static_executable: true。静态可执行程序不能加载libc等动态库,只能导入static_libs。以上都是针对ELF格式的程序。

当然,/system/bin/linker也是静态连接的。他自己不能配置为动态链接器。LinkerAndroid.bp里面配置static_executable: true。同时根据arch编译汇编代码 begin.S来配置程序入口。Arm64汇编指令 bl:跳转指令,但是在跳转之前,会将下一条指令保存到返回地址(链接寄存器)LR寄存器中。Brbl类似,只是后面参数需要特定的寄存器。

3,Android Linker 拦截信号

应用程序注册信号处理hanlder,当信号事件发生后,内核将信号置为pending状态,在中断返回或者系统调用返回时,查看pending的信号,内核在应用程序的栈上构建一个信号处理栈帧,然后通过中断返回或者系统调用返回到用户态,执行信号处理函数。执行信号处理函数之后,再次通过sigreturn系统调用返回到内核,在内核中再次返回到应用程序被中断打断的地方或者系统调用返回的地方接着运行。 

debuggerd_signal_handler()函数最开始使用互斥锁 pthread_mutex_lock() 来保护线程,方式同一时间多个线程处理信号而导致冲突。接着,调用 log_signal_summary() 来输出一些log 信息信息,例如fault addrsignosignamepidtid、线程名、主线程名等。

接着,调用clone() 函数创建伪线程,并在伪线程中调用 debuggerd_dispatch_pseudothread() 函数,原来的线程原地等待子线程的开始和结束。

如果应用程序没有注册对应的信号处理函数,那么信号发生后,内核按照内核默认的信号处理方式处理该信号。

debuggerd_dispatch_pseudothread() 线程中会 fork 一个子进程,并通过 execle() 系统调用去执行 crash_dump64 程序,父进程等待 crash_dump64 进程退出。

4,LINUX信号

当程序运行出现异常时候,CPU会发出指令异常信号。非可靠信号,由linker注册。Linker加载的动态可执行程序,即使被加载程序调用了注册函数函数,也不能正常收到,因为这些信号已经提前被被linker截断。

中断信号的产生有以下4个来源:1,外设(来自中断控制器); 2,IPI(处理器间中断); 3, CPU异常(比如前一条指令存在除零错误、缺页错误等); 4,中断指令。前两种中断都可以叫做硬件中断,都是异步的;后两种中断都可以叫做软件中断,都是同步的。在arm64架构加,将上述中断分类为异步异常(Physical interruptsVirtual interrupts)和同步异常(同步异常与当前指令的执行直接相关)。其实大同小异。以上是CPU层面的,对于LINUX来说,以上描述的异常或者中断,都代表一次hardirq。当然hardirq可能产生一个softirq到软中断pending列表,或者直接被处理返回。Linux的软中断是进程调度层面的,由内核线程softirqd去读取软中断pending列表,再转化为信号分发。当一个进程收到一个信号的时候,进程会被挂起,开始执行中断处理函数。Linux操作系统当中有62个信号,前31个(1-31):不可靠信号,非实时信号,信号有可能丢失,后31个(34-64):可靠信号,信号不会丢失。非可靠信号注册多次,只会处理第一次注册的,可靠信号注册多次,会处理多次。Linux处理软中断处于程序上下文。处理硬中断处于中断上下文。

5,crash dump流程

crash_dump64 进程中,再fork 一个新进程,父进程通过 fork_exit_read 去等待子进程,子进程继续执行 crash_dump 的任务。

crash_dump64 中,通过 /proc/PID/cmdline 获取进程的名字,通过 /proc/PID/fd 获取此进程打开多少文件,每个文件都有一个描述符。

crash_dump64 中循环遍历这个进程中所有的线程,对进程中的每一个线程进行 ptrace 操作,对目标线程读取器 crashinfocrashinfo 读取完毕后 detech 当前的线程。

之后,在 crash_dump64 中调用 tombstoned_connect() 通过 socket 连接到 tombstoned 进程。根据 signal si_val 的值做不同的判断,为0dump tombstone,为1dump backtrace

如果是 dump tombstone,最终 tombstone 通过 engrave_tombstone() 函数生成,engrave_tombstone() 函数的第二个参数 unwinder 是输出 backtrace 等信息的关键函数。unwinder 初始化过程中获取了当前进程的内存和 memory map,这些信息会在后面帮助 debuggerd 生成 tombstone 文件。

dump_memory_and_code()

打印寄存器附近的memory 信息。

dump_signal_info() 

函数打印引发这次 tombstone 的信号信息摘要。

dump_probable_cause()

通过分析 signal_info 打印可能的原因信息。如果没有分析出可能的原因就不会打印出任何信息。

dump_abort_message()

通过内存信息,确定 abort message

dump_registers()

打印出错时寄存器的值,thread_info 中记录了错误发生时的寄存器信息。

log_backtrace()

调用栈。

dump_memory_and_code()

打印寄存器附近的memory 信息。

 dump_all_maps()

map 信息记录了进程对应的内存映射,包括开始地址,长度,访问权限,文件描述符,offset 等信息。

6,debug dump trace 流程

Debug dump的触发场景一般是system_server发生watch dog,或者系统执行“debuggerd –b [pid]”命令产生。分别是调用进程加载组件debuggerd_client的接口:
dump_backtrace_to_file(), 
或者JNI接口:
android_os_Debug_dumpJavaBacktraceToFileTimeout(), android_os_Debug_dumpNativeBacktraceToFileTimeout()。
信号会对系统调用产生影响,触发系统调用的自动重启动。

debuggerd_trigger_dump向“tombstoned_intercept”发送InterceptRequest 请求,tombstone中的intercept_manager 处理该请求,并返回intercept的状态,如register/started/failed等。

然后向目标进程发送信号signal = (dump_type == kDebuggerdJavaBacktrace) ? SIGQUIT : DEBUGGER_SIGNAL;  --- #define DEBUGGER_SIGNAL (__SIGRTMIN + 3)。

之后等待tombstoned的信息返回。

7,Crash dump与debug dump整体流程

异常发生时, ARM 处理器会跳转到对应该异常的 固定地址 去执行异常处理程序, 这个 固定的地址 就是异常向量。对于tombstone类异常,会产生一个Software interrupt (SWI)。每个cpu会有一个内核线程softirqd轮询读取软中断,并把信号转发给对应的应用。除了SWIARM还会产生ResetUndefined instructionsPrefetch Abort (instruction fetch memory abort) Data Abort (data access memory abort)IRQ (interrupt)以及FIQ (fast interrupt)Arm64会产生:Synchronous exceptionSerrorIRQ FIQ四个类型的同步异常。不同架构中断与异常代码流程底层差异比较大。除了底层上报,还有各个应用程序可以给其他应用发送信号,由操作系统调度。

三、LOG解析

1,debugdump

一般问题不会是libc.so或者libhwbinder.so这种经过多年检验的公共库。找到与问题版本对应的符号产物。本地复现的在符号在out/ 目录里 symbols/ 目录下(或者在编译后的工程先source lunch之后再用addr2line 

addr2line -f –a -C -e

./symbols/vendor/bin/hw/android.hardware.audio@2.0-service  00001771

2,crashdump

四、示例

1,权限问题导致SIGABRT

检查main log,有如下selinux打印:

07-18 17:48:44.679  6105  6105 W Binder:6105_2: type=1400 audit(0.0:3532): avc: denied { read write } for name="hab" dev="tmpfs" ino=15391 scontext=u:r:shell:s0 tcontext=u:object_r:hab_device:s0 tclass=chr_file permissive=0
07-18 17:48:44.691  6105  6114 I Adreno-GSL_RPC: <gsl_rpc_connect:1211>: connecting using conn_id 0
07-18 17:48:44.692  6105  6114 I uhab    : habmm_socket_open: hab: open failed, error code 13 Permission denied
07-18 17:48:44.692  6105  6114 E Adreno-GSL_RPC: <gsl_hab_open:51>: Unable to habmm_socket_open err -13

后来修改:

allow shell hab_device:chr_file_rw_file_perms;

2,线程时序导致空指针异常

pid: 1082, tid: 1534, name: HwBinder:1082_1  >>> /system/vendor/bin/ipacm <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x8
Cause: null pointer dereference
    x0  0000000000000000  x1  0000000000000000  x2  6c206b636172746e  x3  0a2e646165726874
    x4  2072656e65747369  x5  000000719b41d399  x6  20746f4720202928  x7  7364662068746f62
    x8  edf87d25729f7502  x9  edf87d25729f7502  x10 0000000000004001  x11 0000000000000000
    x12 656e657473696c20  x13 000000000000009a  x14 0000000000000000  x15 000000719b98e3f8
    x16 000000719beb11e0  x17 000000719be44950  x18 0000000000000001  x19 0000000000000000
    x20 000000719b98f588  x21 0000000000000006  x22 000000719b98f588  x23 000000719b4327a8
    x24 000000719b48f000  x25 0000005fcc052680  x26 0000000000000000  x27 000000719b98f588
    x28 0000000000000000  x29 000000719b98e440
    sp  000000719b98e410  lr  0000005fcc052908  pc  0000005fcc0500c4

backtrace:
    #00 pc 00000000000330c4  /vendor/bin/ipacm (IPACM_ConntrackListener::CreateConnTrackThreads()+36)
    #01 pc 0000000000035904  /vendor/bin/ipacm (IPACM_OffloadManager::provideFd(int, unsigned int)+644)
    #02 pc 000000000000a1d8  /vendor/lib64/liboffloadhal.so (HAL::setHandles(android::hardware::hidl_handle const&, android::hardware::hidl_handle const&, std::__1::function<void (bool, android::hardware::hidl_string const&)>)+420)
    #03 pc 000000000000ceec  /system/lib64/vndk-28/android.hardware.tetheroffload.config@1.0.so (android::hardware::tetheroffload::config::V1_0::BnHwOffloadConfig::_hidl_setHandles(android::hidl::base::V1_0::BnHwBase*, android::hardware::Parcel const&, android::hardware::Parcel*, std::__1::function<void (android::hardware::Parcel&)>)+316)
    #04 pc 000000000000d1a0  /system/lib64/vndk-28/android.hardware.tetheroffload.config@1.0.so (android::hardware::tetheroffload::config::V1_0::BnHwOffloadConfig::onTransact(unsigned int, android::hardware::Parcel const&, android::hardware::Parcel*, unsigned int, std::__1::function<void (android::hardware::Parcel&)>)+320)
    #05 pc 000000000001d334  /system/lib64/vndk-sp-28/libhwbinder.so (android::hardware::IPCThreadState::executeCommand(int)+640)
    #06 pc 000000000001430c  /system/lib64/vndk-sp-28/libhwbinder.so (android::hardware::IPCThreadState::getAndExecuteCommand()+196)
    #07 pc 0000000000014588  /system/lib64/vndk-sp-28/libhwbinder.so (android::hardware::IPCThreadState::joinThreadPool(bool)+268)
    #08 pc 000000000001c1ac  /system/lib64/vndk-sp-28/libhwbinder.so (android::hardware::PoolThread::threadLoop()+24)
    #09 pc 000000000000fa08  /system/lib64/vndk-sp-28/libutils.so (android::Thread::_threadLoop(void*)+280)
    #10 pc 00000000000819b4  /system/lib64/libc.so (__pthread_start(void*)+36)
    #11 pc 0000000000023478  /system/lib64/libc.so (__start_thread+68)

具体代码就不多贴了,直接贴修改,就懂了。 

3,libart 出现BUS_ADRALN

pid: 2147, tid: 2147, name: m.app.animation  >>> com.app.animation <<<
signal 7 (SIGBUS), code 1 (BUS_ADRALN), fault addr 0x656c62
    x0  0000006f90ee8648  x1  0000000041504e4d  x2  0000007ff0cf5be8  x3  0000006f90668ed8
    x4  0000000012c12da6  x5  0000007ff0cf5c46  x6  6f00630015000000  x7  770067002e006d00
    x8  0000000000656c62  x9  0000006f90e4b700  x10 0000000000000032  x11 69006e0061002e00
    x12 6900740061006d00  x13 000000006e006f00  x14 0000000070ca1348  x15 0000000000003eba
    x16 0000006f90714140  x17 000000701265db30  x18 0000000000000000  x19 0000007ff0cf5be8
    x20 0000000041504e4d  x21 0000006f90e2b6f8  x22 0000006f90e2b6f8  x23 0000007ff0cf6088
    x24 0000007ff0cf5c14  x25 00000070168895e0  x26 000000007090b600  x27 0000000071178cb0
    x28 0000000012c12c20  x29 0000007ff0cf5bd0
    sp  0000007ff0cf5bb0  lr  0000006f90558a30  pc  0000000000656c62

backtrace:
    #00 pc 0000000000656c62  <unknown>
    #01 pc 0000000000473a2c  /system/lib64/libart.so (art::RuntimeCallbacks::DdmPublishChunk(unsigned int, art::ArrayRef<unsigned char const> const&)+56)
    #02 pc 00000000003f0f14  /system/lib64/libart.so (art::DdmServer_nativeSendChunk(_JNIEnv*, _jclass*, int, _jbyteArray*, int, int)+356)
    #03 pc 000000000007fb74  /system/framework/arm64/boot-core-libart.oat (offset 0x79000) (org.apache.harmony.dalvik.ddmc.DdmServer.nativeSendChunk+196)
    #04 pc 000000000013e9bc  /system/framework/arm64/boot-core-libart.oat (offset 0x79000) (org.apache.harmony.dalvik.ddmc.DdmServer.sendChunk+76)
    #05 pc 00000000007e92ac  /system/framework/arm64/boot-framework.oat (offset 0x3d2000) (android.ddm.DdmHandleAppName.sendAPNM+284)
    #06 pc 0000000000879a78  /system/framework/arm64/boot-framework.oat (offset 0x3d2000) (android.app.ActivityThread.handleBindApplication+952)
    #07 pc 0000000000876034  /system/framework/arm64/boot-framework.oat (offset 0x3d2000) (android.app.ActivityThread$H.handleMessage+6916)
    #08 pc 0000000000ab7724  /system/framework/arm64/boot-framework.oat (offset 0x3d2000) (android.os.Handler.dispatchMessage+180)
    #09 pc 0000000000aba820  /system/framework/arm64/boot-framework.oat (offset 0x3d2000) (android.os.Looper.loop+1264)
    #10 pc 0000000000882e28  /system/framework/arm64/boot-framework.oat (offset 0x3d2000) (android.app.ActivityThread.main+664)
    #11 pc 0000000000554c4c  /system/lib64/libart.so (art_quick_invoke_static_stub+604)
    #12 pc 00000000000cf6e8  /system/lib64/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+232)
    #13 pc 000000000045c840  /system/lib64/libart.so (art::(anonymous namespace)::InvokeWithArgArray(art::ScopedObjectAccessAlreadyRunnable const&, art::ArtMethod*, art::(anonymous namespace)::ArgArray*, art::JValue*, char const*)+104)
    #14 pc 000000000045e294  /system/lib64/libart.so (art::InvokeMethod(art::ScopedObjectAccessAlreadyRunnable const&, _jobject*, _jobject*, _jobject*, unsigned long)+1440)
    #15 pc 00000000003ee1d4  /system/lib64/libart.so (art::Method_invoke(_JNIEnv*, _jobject*, _jobject*, _jobjectArray*)+52)
    #16 pc 000000000011e6d4  /system/framework/arm64/boot-core-oj.oat (offset 0x114000) (java.lang.Class.getDeclaredMethodInternal [DEDUPED]+180)
    #17 pc 0000000000bf1bd8  /system/framework/arm64/boot-framework.oat (offset 0x3d2000) (com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run+136)
    #18 pc 0000000000bf8dc0  /system/framework/arm64/boot-framework.oat (offset 0x3d2000) (com.android.internal.os.ZygoteInit.main+3088)
    #19 pc 0000000000554c4c  /system/lib64/libart.so (art_quick_invoke_static_stub+604)
    #20 pc 00000000000cf6e8  /system/lib64/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+232)
    #21 pc 000000000045c840  /system/lib64/libart.so (art::(anonymous namespace)::InvokeWithArgArray(art::ScopedObjectAccessAlreadyRunnable const&, art::ArtMethod*, art::(anonymous namespace)::ArgArray*, art::JValue*, char const*)+104)
    #22 pc 000000000045c4a0  /system/lib64/libart.so (art::InvokeWithVarArgs(art::ScopedObjectAccessAlreadyRunnable const&, _jobject*, _jmethodID*, std::__va_list)+424)
    #23 pc 0000000000361b60  /system/lib64/libart.so (art::JNI::CallStaticVoidMethodV(_JNIEnv*, _jclass*, _jmethodID*, std::__va_list)+652)
    #24 pc 00000000000b2374  /system/lib64/libandroid_runtime.so (_JNIEnv::CallStaticVoidMethod(_jclass*, _jmethodID*, ...)+120)
    #25 pc 00000000000b4cf8  /system/lib64/libandroid_runtime.so (android::AndroidRuntime::start(char const*, android::Vector<android::String8> const&, bool)+756)
    #26 pc 000000000000219c  /system/bin/app_process64 (main+1200)
    #27 pc 00000000000acac8  /system/lib64/libc.so (__libc_init+88)

由于每次异常打印的异常地址都是 fault addr 0x656c62,且多个应用都有打印,说明该问题是libart.so强相关,而不是com.app.animation的内存问题。地址0x656c62固定,有可能两种情况,一种是代码中存在字节不对齐情况,一种是这个地址是相对于对象首地址的偏移地址,这是对象被释放后的解引用。

出现的原因是adbd守护进程会因为开机阶段多次重新配置usb模式而被多次杀掉重新启动。如果杀掉重新启动adbd的时候正好碰上zygote孵化进程,某些进程就有概率报告这个错误。

解决方法:

Android12没有该问题。Android12上面gStatethis_指针没有delete, 他们使用C++17std::optional<>模板,无newdelete

4,system_server 调用 debug dump导致audio crash

 

五、其他

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.coloradmin.cn/o/1247610.html

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈,一经查实,立即删除!

相关文章

Gen-2重磅发布“运动画笔”,可制作视频连环画啦!

著名生成式AI平台Runway在官网宣布&#xff0c;其文生视频产品Gen-2正式发布运动画笔、预设风格、更新导演模式和优化图像模型4个功能。 其中&#xff0c;运动画笔成为本次更新的最大亮点&#xff0c;用户只需要对上传的图片指定区域进行涂抹&#xff0c;就能让生成的视频按照…

使用nginx代理s3服务(私有云存储)

1、背景 公司网络安全原因&#xff0c;私有部署s3服务的机器无法被直接访问&#xff0c;所以需要加一层代理&#xff0c;通过访问代理去访问s3服务器&#xff0c;这里使用nginx进行代理。使用s3服务的方式是在代码中使用官方的java s3 sdk&#xff08;本文对于其他语言的官方s…

输入4个整数,找出其中最大的数。用函数的嵌套调用来处理

目录 1解题思路: 2运行代码&#xff1a; 3运行结果: 4总结&#xff1a; 函数 定义函数 实例 函数声明 调用函数 实例 函数参数 1解题思路: 这个问题并不复杂&#xff0c;完全可以利用一个主函数就可以得到结果。现在根据题目要求&#xff0c;用函数的嵌套调用来处理。…

redis运维(十二) 位图

一 位图 ① 概念 1、说明&#xff1a;位图还是在操作字符串2、位图玩字符串在内存中存储的二进制3、ASCII字符通过映射转化为二进制4、操作的是字符串value ② ASCII字符铺垫 1、控制ASCII字符 2、ASCII可显示字符 ③ SETBIT 细节&#xff1a; setbit 命令的返回值是之…

自求导的方法实现线性回归算法

线性回归是一种常用的回归算法&#xff0c;用于建立输入变量和连续输出变量之间的关系。传统的线性回归算法通常依赖于繁琐的数学推导和梯度计算。但是&#xff0c;随着深度学习的兴起&#xff0c;自求导的方法逐渐成为实现线性回归算法的有效途径。本文将介绍如何使用自求导的…

FreeRTOS-FreeRTOS概述

FreeRTOS FreeRTOS目录结构 移植过程 在工程中创建freertos文件夹&#xff0c;在freertos文件夹中创建src文件夹、inc文件夹、port文件夹。 freertos/src存放源码freertos/inc存放头文件freertos/port存放移植平台的相关文件 复制内存管理文件&#xff1a;复制FreeRTOS/Sourc…

时间复杂度 空间复杂度 ---java

目录 一. 算法效率 二.时间复杂度 2.1 时间复杂度的概念 2.2 大O的渐进表示法 2.3常见时间复杂度计算举例 三. 空间复杂度 一. 算法效率 算法效率分析分为两种&#xff1a;第一种是时间效率&#xff0c;第二种是空间效率 。 时间效率被称为时间复杂度&#xff0c;而空间…

post请求参数全大写后台接不到参数

post请求参数全大写后台接不到参数 开发过程中&#xff0c;我们一般都习惯用驼峰命名法&#xff0c;但是特殊情况要求请求参数全大写&#xff08;或者首字母大写&#xff09;&#xff0c;测试验证的时候发现&#xff0c;接收不到请求参数。 前端请求传递&#xff1a; 服务端接…

季报含金量强势推高股价,满帮十年持续拉高数字货运生态天花板

经济活动越发密集&#xff0c;跑在路上的货车和司机们成为最忙碌的角色。11月20日美股盘前&#xff0c;数字货运龙头满帮集团&#xff08;YMM.US&#xff0c;以下简称&#xff1a;满帮&#xff09;发布2023年第三季度财报&#xff0c;其用户规模、业绩数据、履约单量等指标全面…

亚马逊两步验证有哪些验证方法?

亚马逊通常提供多种两步验证的方式&#xff0c;包括短信&#xff08;通过手机接收验证码&#xff09;和认证器应用程序&#xff08;如Google Authenticator、Authy等&#xff09;。选择你偏好的方式。 短信验证&#xff1a; 如果选择短信验证&#xff0c;需要将你的手机号码关联…

《算法通关村——原来这就是堆》

《算法通关村——原来这就是堆》 理解最大堆&#xff1a; 最大堆就是父节点一定比子节点都要大所以就形成了&#xff0c;自然而然根节点就是最大的值了。 如果在最大堆中要插入值得话&#xff0c;那么就需要把值插入到最后&#xff0c;然后一步一步得走上去&#xff0c;也就是…

分布式算法paxos

Paxos算法是什么&#xff1f; Paxos 算法是 基于消息传递 且具有 高效容错特性 的一致性算法&#xff0c;目前公认的解决 分布式一致性问题 最有效的算法之一。 Paxos算法的工作流程&#xff1f; 角色&#xff1a; 在Paxos中有这么几个角色&#xff1a; Proposer&#xff08;提…

Centos7 离线安装 CDH7.1.7

1. 安装CDH的准备工作&#xff08;所有节点都要执行&#xff09; 1.1 准备环境 角色 IP k8s-master 192.168.181.129 k8s-node1 192.168.181.130 k8s-node2 192.168.181.131 1.2 安装JDK # https://www.oracle.com/java/technologies/downloads/#java11 wget rpm -ivh…

知虾官网:探索跨境电商数据的新平台

随着电子商务的快速发展&#xff0c;跨境电商已成为全球贸易的重要组成部分。为了帮助企业更好地了解市场、选品、分析竞争对手和科学运营&#xff0c;知虾官网应运而生。本文将为您介绍知虾官网的功能和优势&#xff0c;以及广州萌啦信息科技有限公司的背景。 一、知虾官网的功…

电源控制系统架构(PCSA)之系统分区电源域

目录 4.2 电源域 4.2.1 电源模式 4.2.2 电源域的选择 4.2.3 系统逻辑 4.2.4 Always-On域 4.2.5 处理器Clusters 4.2.6 CoreSight逻辑 4.2.7 图像处理器 4.2.8 显示处理器 4.2.9 其他功能 4.2.10 电源域层次结构要求 4.2.11 SOC域示例 4.2 电源域 电源域在这里被定…

VScode安装使用DevChat插件

前言 DevChat是一个开源平台,使开发人员能够更有效地将人工智能集成到代码生成和文档中。DevChat的目标是超越简单的代码自动完成和对代码片段的有限操作。DevChat为开发人员提供了一种非常实用和有效的方式来与大型语言模型(llms)进行交互和协作。 一、安装DevChat插件 De…

西米支付:简单介绍一下支付公司的分账功能体系

随着互联网的普及和电子商务的快速发展&#xff0c;支付已经成为人们日常生活的重要组成部分。支付公司作为第三方支付平台&#xff0c;为消费者和商家提供了便捷、安全的支付方式。而在支付领域中&#xff0c;分账功能是一个非常重要的功能&#xff0c;它可以帮助企业实现资金…

一篇总结 Linux 系统启动的几个汇编指令

学习 Linux 系统启动流程&#xff0c;必须熟悉几个汇编指令&#xff0c;总结给大家。 这里不是最全的&#xff0c;只列出一些最常用的汇编指令。 一&#xff0e;数据处理指令 1.数据传送指令 【MOV指令】 把一个寄存器的值(立即数)赋给另一个寄存器&#xff0c;或者将一个…

如何巧用拨测监控中的自定义维度?

在拨测监控的场景中&#xff0c;用户往往很关心拨测的资源对象是否正常。在当前拨测采集策略中&#xff0c;拨测采集对象本身可能无法反映出配置的拨测地址&#xff0c;用户可能还需要找到具体的拨测采集策略后才能确认拨测地址。 本期EasyOps产品使用最佳实践&#xff0c;我们…

『Confetti 喜庆散花插件の使用』

以下用 VUE3 语法 举例使用&#xff1a; npm install js-confetti<script setup lang"ts"> import JSConfetti from js-confetticonst confetti new JSConfetti()function showConfetti() {confetti.addConfetti() } </script><template><h1 …