[Python] Native Crash Addr2line 自动解析Tombstone文件脚本

最新推荐文章于 2025-06-21 20:30:00 发布
最新推荐文章于 2025-06-21 20:30:00 发布
阅读量2k 收藏 12
点赞数 1
CC 4.0 BY-SA版权
分类专栏： tools 文章标签： tombstone解析
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/TaylorPotter/article/details/86522986
本文介绍了一款Python脚本，能够自动解析Android系统的Tombstone文件，支持32位和64位进程，适用于单个文件及批量解析。通过调用addr2line工具，脚本能将崩溃调用栈中的地址转换为可读的函数名和源代码位置，帮助开发者快速定位问题。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

[Python] Native Crash Addr2line 自动解析Tombstone文件脚本

文末附上脚本源码
2019.4.24 更新，32位，64位 进程tombstone的兼容

使用方法

1.解析单个tombstone文件：

python ./as_tomba.py tombstone_file_path symbol_root_path
在tombstone_file_path目录下生成 tombstone文件名_pid_pname.out 的解析之后文件

2.批量解析文件夹中的tombstone文件：

python ./as_tomba.py tombstone_file_dir symbol_root_path
将tombstone_file_dir目录下的含有tombstone调用栈的文件解析输出到该目录下相应的输出文件中

3.兼容logcat中的tombstone调用栈

如logcat中有如下log：

01-09 14:11:02.220 16332 16811 F libc : Fatal signal 6 (SIGABRT), code -6 (SI_TKILL) in tid 16811 (HwBinder:16332_), pid 16332 (provider@2.4-se)
01-09 14:11:02.278 17079 17079 I crash_dump64: obtaining output fd from tombstoned, type: kDebuggerdTombstone
01-09 14:11:02.278 888 888 I /system/bin/tombstoned: received crash request for pid 16811
01-09 14:11:02.280 17079 17079 I crash_dump64: performing dump of process 16332 (target tid = 16811)
01-09 14:11:02.286 17079 17079 F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
01-09 14:11:02.286 17079 17079 F DEBUG : Build fingerprint: 'xiaomi/violet/violet:9/PKQ1.181203.001/9.1.9:user/release-keys'
01-09 14:11:02.286 17079 17079 F DEBUG : Revision: '0'
01-09 14:11:02.286 17079 17079 F DEBUG : ABI: 'arm64'
01-09 14:11:02.286 17079 17079 F DEBUG : pid: 16332, tid: 16811, name: HwBinder:16332_ >>> /vendor/bin/hw/android.hardware.camera.provider@2.4-service_64 <<<
01-09 14:11:02.286 17079 17079 F DEBUG : signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
01-09 14:11:02.286 17079 17079 F DEBUG : Abort message: 'Invalid address 0x7be6e0d180 passed to free: value not allocated'
01-09 14:11:02.286 17079 17079 F DEBUG : x0 0000000000000000 x1 00000000000041ab x2 0000000000000006 x3 0000000000000008
01-09 14:11:02.286 17079 17079 F DEBUG : x4 8080808080808080 x5 8080808080808080 x6 8080808080808080 x7 0000000000000008
01-09 14:11:02.286 17079 17079 F DEBUG : x8 0000000000000083 x9 49bf711238106b52 x10 0000000000000000 x11 fffffffc7fffffdf
01-09 14:11:02.286 17079 17079 F DEBUG : x12 0000000000000001 x13 000000005c35b39e x14 000c568e6e9f9200 x15 0000d19ff0bea88d
01-09 14:11:02.286 17079 17079 F DEBUG : x16 0000007c3320f2b8 x17 0000007c3312ec50 x18 ffffffffffffff60 x19 0000000000003fcc
01-09 14:11:02.286 17079 17079 F DEBUG : x20 00000000000041ab x21 0000007be6e0d180 x22 0000000000000000 x23 0000007c3321b8d8
01-09 14:11:02.286 17079 17079 F DEBUG : x24 0000007c254a5eb8 x25 0000007c3092cda0 x26 0000007c254a5eb8 x27 0000007c254a5eb8
01-09 14:11:02.286 17079 17079 F DEBUG : x28 0000007c254a5eb8 x29 0000007c0501f300
01-09 14:11:02.286 17079 17079 F DEBUG : sp 0000007c0501f2c0 lr 0000007c331220c4 pc 0000007c331220ec
01-09 14:11:02.323 711 711 I ConfigStore: android::hardware::configstore::V1_0::ISurfaceFlingerConfigs::hasHDRDisplay retrieved: 0
01-09 14:11:02.325 17079 17079 F DEBUG : 
01-09 14:11:02.325 17079 17079 F DEBUG : backtrace:
01-09 14:11:02.325 17079 17079 F DEBUG : #00 pc 00000000000220ec /system/lib64/libc.so (abort+116)
01-09 14:11:02.325 17079 17079 F DEBUG : #01 pc 00000000000b430c /system/lib64/libc.so (ifree+1172)
01-09 14:11:02.325 17079 17079 F DEBUG : #02 pc 00000000000b4418 /system/lib64/libc.so (je_free+120)
01-09 14:11:02.325 17079 17079 F DEBUG : #03 pc 00000000000cee9c /vendor/lib64/hw/com.qti.chi.override.so (ChxUtils::AndroidMetadata::FreeMetaData(void*)+28)
01-09 14:11:02.325 17079 17079 F DEBUG : #04 pc 0000000000099788 /vendor/lib64/hw/com.qti.chi.override.so (ChiMetadataManager::AndroidMetadataHolder::~AndroidMetadataHolder()+160)
01-09 14:11:02.325 17079 17079 F DEBUG : #05 pc 00000000000de150 /vendor/lib64/hw/com.qti.chi.override.so (std::_1::vector_base<ChiMetadataManager::AndroidMetadataHolder, std::1::allocator<ChiMetadataManager::AndroidMetadataHolder>>::~_vector_base()+72)
01-09 14:11:02.325 17079 17079 F DEBUG : #06 pc 00000000000de034 /vendor/lib64/hw/com.qti.chi.override.so (std::_1::vector<ChiMetadataManager::AndroidMetadataHolder, std::_1::allocator<ChiMetadataManager::AndroidMetadataHolder>>::~vector()+20)
01-09 14:11:02.325 17079 17079 F DEBUG : #07 pc 0000000000099a14 /vendor/lib64/hw/com.qti.chi.override.so (ChiMetadataManager::~ChiMetadataManager()+84)
01-09 14:11:02.325 17079 17079 F DEBUG : #08 pc 0000000000099d9c /vendor/lib64/hw/com.qti.chi.override.so (ChiMetadataManager::Destroy()+28)
01-09 14:11:02.325 17079 17079 F DEBUG : #09 pc 00000000000ad694 /vendor/lib64/hw/com.qti.chi.override.so (Usecase::DestroyObject(int)+1476)
01-09 14:11:02.325 17079 17079 F DEBUG : #10 pc 000000000005d45c /vendor/lib64/hw/com.qti.chi.override.so (ExtensionModule::TeardownOverrideUsecase(camera3_device const*, int)+220)
01-09 14:11:02.325 17079 17079 F DEBUG : #11 pc 00000000000616f4 /vendor/lib64/hw/com.qti.chi.override.so (ExtensionModule::TeardownOverrideSession(camera3_device const*, unsigned long, void*)+164)
01-09 14:11:02.325 17079 17079 F DEBUG : #12 pc 000000000005bde8 /vendor/lib64/hw/com.qti.chi.override.so (chi_teardown_override_session(camera3_device const*, unsigned long, void*)+56)
01-09 14:11:02.326 17079 17079 F DEBUG : #13 pc 00000000000ccd28 /vendor/lib64/hw/camera.qcom.so (CamX::close(hw_device_t*)+1768)
01-09 14:11:03.363 857 1000 E storaged: getDiskStats failed with result NOT_SUPPORTED and size 0
01-09 14:11:02.324 711 711 I chatty : uid=1000(system) /system/bin/surfaceflinger identical 2 lines

将该log贴到指定文件中跑脚本：

python ./as_tombstone_analysis/as_tomba.py ./as_tombstone_analysis/log_demo/ne_log_crash.txt /home/chengang/Documents/f7b_issue/symbols/9.1.9_in/out/target/product/violet/symbols

输出文件：
在这里插入图片描述
文件解析结果：

01-09 14:11:02.325 17079 17079 F DEBUG : #00 pc 00000000000220ec /system/lib64/libc.so (abort+116)abort
bionic/libc/bionic/abort.cpp:73

01-09 14:11:02.325 17079 17079 F DEBUG : #01 pc 00000000000b430c /system/lib64/libc.so (ifree+1172)je_arena_dalloc
external/jemalloc/include/jemalloc/internal/arena.h:1453

01-09 14:11:02.325 17079 17079 F DEBUG : #02 pc 00000000000b4418 /system/lib64/libc.so (je_free+120)je_free
external/jemalloc/src/jemalloc.c:?

01-09 14:11:02.325 17079 17079 F DEBUG : #03 pc 00000000000cee9c /vendor/lib64/hw/com.qti.chi.override.so (ChxUtils::AndroidMetadata::FreeMetaData(void*)+28)ChxUtils::AndroidMetadata::FreeMetaData(void*)
vendor/qcom/proprietary/chi-cdk/vendor/chioverride/default/chxutils.cpp:755

01-09 14:11:02.325 17079 17079 F DEBUG : #04 pc 0000000000099788 /vendor/lib64/hw/com.qti.chi.override.so (ChiMetadataManager::AndroidMetadataHolder::~AndroidMetadataHolder()+160)~AndroidMetadataHolder
vendor/qcom/proprietary/chi-cdk/vendor/chioverride/default/chxmetadata.cpp:814

01-09 14:11:02.325 17079 17079 F DEBUG : #05 pc 00000000000de150 /vendor/lib64/hw/com.qti.chi.override.so (std::_1::vector_base<ChiMetadataManager::AndroidMetadataHolder, std::1::allocator<ChiMetadataManager::AndroidMetadataHolder>>::~_vector_base()+72)std::__1::allocator<ChiMetadataManager::AndroidMetadataHolder>::destroy(ChiMetadataManager::AndroidMetadataHolder*)
external/libcxx/include/memory:1860

01-09 14:11:02.325 17079 17079 F DEBUG : #06 pc 00000000000de034 /vendor/lib64/hw/com.qti.chi.override.so (std::_1::vector<ChiMetadataManager::AndroidMetadataHolder, std::_1::allocator<ChiMetadataManager::AndroidMetadataHolder>>::~vector()+20)~vector
external/libcxx/include/vector:447

01-09 14:11:02.325 17079 17079 F DEBUG : #07 pc 0000000000099a14 /vendor/lib64/hw/com.qti.chi.override.so (ChiMetadataManager::~ChiMetadataManager()+84)~ChiMetadataManager
vendor/qcom/proprietary/chi-cdk/vendor/chioverride/default/chxmetadata.cpp:965

01-09 14:11:02.325 17079 17079 F DEBUG : #08 pc 0000000000099d9c /vendor/lib64/hw/com.qti.chi.override.so (ChiMetadataManager::Destroy()+28)ChiMetadataManager::Destroy()
vendor/qcom/proprietary/chi-cdk/vendor/chioverride/default/chxmetadata.cpp:847

01-09 14:11:02.325 17079 17079 F DEBUG : #09 pc 00000000000ad694 /vendor/lib64/hw/com.qti.chi.override.so (Usecase::DestroyObject(int)+1476)Usecase::DestroyObject(int)
vendor/qcom/proprietary/chi-cdk/vendor/chioverride/default/chxusecase.cpp:172

01-09 14:11:02.325 17079 17079 F DEBUG : #10 pc 000000000005d45c /vendor/lib64/hw/com.qti.chi.override.so (ExtensionModule::TeardownOverrideUsecase(camera3_device const*, int)+220)ExtensionModule::TeardownOverrideUsecase(camera3_device const*, int)
vendor/qcom/proprietary/chi-cdk/vendor/chioverride/default/chxextensionmodule.cpp:2129

01-09 14:11:02.325 17079 17079 F DEBUG : #11 pc 00000000000616f4 /vendor/lib64/hw/com.qti.chi.override.so (ExtensionModule::TeardownOverrideSession(camera3_device const*, unsigned long, void*)+164)ExtensionModule::TeardownOverrideSession(camera3_device const*, unsigned long, void*)
vendor/qcom/proprietary/chi-cdk/vendor/chioverride/default/chxextensionmodule.cpp:2074

01-09 14:11:02.325 17079 17079 F DEBUG : #12 pc 000000000005bde8 /vendor/lib64/hw/com.qti.chi.override.so (chi_teardown_override_session(camera3_device const*, unsigned long, void*)+56)chi_teardown_override_session(camera3_device const*, unsigned long, void*)
vendor/qcom/proprietary/chi-cdk/vendor/chioverride/default/chxextensioninterface.cpp:504

01-09 14:11:02.326 17079 17079 F DEBUG : #13 pc 00000000000ccd28 /vendor/lib64/hw/camera.qcom.so (CamX::close(hw_device_t*)+1768)CamX::close(hw_device_t*)
vendor/qcom/proprietary/camx/src/core/hal/camxhaldevice.cpp:956

自动解析tombstone脚本源码：

# -*- coding: utf-8 -*-
# !/usr/bin/python
import re
import os
import os.path
import time
import gzip
import sys

'''
How to use it?
as_tomba.py tombstone_file_path symbol_file_path
out file :
./tombstone_out.txt
'''
tombstone_file_path = sys.argv[1]
symbols_dir_path = sys.argv[2]

def get_filePath_fileName_fileExt(filename):
    (filepath,tempfilename) = os.path.split(filename);
    (shotname,extension) = os.path.splitext(tempfilename);
    return filepath,shotname,extension

def get_process_pid_name(filename):
    f = open(filename)
    for line in f:
        pattern = re.compile(r"pid:\s([0-9]+?),.+>>> (.+?) <<<")
        rst = pattern.search(line)
        if rst :
            pid = rst.group(1)
            name = rst.group(2).lstrip('/').replace('/','#')
            return pid,name
    return "null","null"

def tomba_dir(ptombstone_file_dir,psymbols_dir_path):
    for file_name in os.listdir(tombstone_file_path):
        target_file = os.path.join(tombstone_file_path,file_name)
        tomba_file(target_file,symbols_dir_path)

def tomba_file(ptombstone_file_path,psymbols_dir_path):
    psymbols_dir_path = psymbols_dir_path.rstrip('/')
    (pid,pname) = get_process_pid_name(ptombstone_file_path)
    f = open(ptombstone_file_path);
    (file_p,file_s,file_e) = get_filePath_fileName_fileExt(ptombstone_file_path)
    out_file_name = file_s+"_"+pid+"_"+pname+".out"
    fp = open(file_p+'/'+out_file_name,'a+')
    fp.truncate()
    for line in f:
        line = line.lstrip()
        line = line.strip('\n')
        if  line.startswith("stack:"):
            break
        else:
            # pattern = re.compile('(#[0-9]{2})(?#调用栈帧数)\s+pc\s+([0-9a-z]{16})(?#pc地址)\s(.+?)\s')
            # 64位和32位机器的pc地址长度不同,64位为16位PC地址，32位为8位PC地址
            pattern = re.compile('(#[0-9]{2})(?#调用栈帧数)\s+pc\s+([0-9a-z]*)(?#pc地址)\s(.+?)\s')
            rst = pattern.search(line)
            if rst:
                symbol_path = psymbols_dir_path + rst.group(3).strip()
                shift_code = rst.group(2)
                print line
                print symbol_path
                print shift_code
                print '\n'
                analysis_result = tomba_so(symbol_path,shift_code)
                fp.write(line)
                fp.write(analysis_result)
                fp.write('\n')
                f.flush()

def tomba_so(symbol_so_path,shift_code):
    if(os.path.exists(symbol_so_path)):
        cmd_line = "addr2line -Cfe %s %s" %(symbol_so_path,shift_code)
        f = os.popen(cmd_line)
        result = f.read()
        return result
    else:
        return "no symbol file!!!"

if os.path.isdir(tombstone_file_path):
	print(tombstone_file_path + " is a dir")
    tomba_dir(tombstone_file_path,symbols_dir_path)
elif os.path.isfile(tombstone_file_path):
    print(tombstone_file_path + " is a file")
    tomba_file(tombstone_file_path,symbols_dir_path)
else:
    print("Wrong Tombstone File Name！")
    sys.exit()
Native崩溃堆栈还原和IL2CPP元数据映射的实现方法
欢迎来到《技术探索》，这是一个专注于游戏开发技术的博客。在这里，我们将深入探讨游戏引擎、图形渲染、人工智能、物理模拟等领域的最新技术和最佳实践。无论您是初学者还是经验丰富的开发者，我们都希望为您提供有价值的见解和实用的技巧。
04-29 845
Native崩溃堆栈还原和IL2CPP元数据映射，就像一场跨界侦探大追踪：你需要查户口、翻译外星语、分析案发现场，最终才能把问题精确定位到C#源码。只有工具齐全、档案完整、流程顺畅，才能让线上崩溃无所遁形！
通过Python解析tombstone
panxbhxh的专栏
03-06 624
方法： 下载my_parse_stack.py到android sdk目录，然后执行 ./my_parse_stack.py tombstone_xx 即可打印出调用堆栈。 想要让cpp crash的时候可以被android捕捉，保存到tombstone中，则需要native app 不对信号量做处理。 当然，如果一定要在代码中捕捉信号量，并打印对应的堆栈信息，方法如下： 1、代码 a...
stack工具用于分析tombstone文件
07-19
参考 http://blog.youkuaiyun.com/koffuxu/article/details/37959071
用addr2line分析tombstones
Venus 的博客
09-05 892
当一个动态库（native 程序）开始执行时，系统会注册一些连接到 debuggerd 的 signal handlers，当系统 crash 的时候，会保存一个 tombstone 文件到/data/tombstones目录下（Logcat中也会有相应的信息），文件的确就像墓碑一样记录了死亡了的进程的基本信息（例如进程的进程号，线程号），死亡的地址（在哪个地址上发生了 Crash），死亡时的现场是什么样的（记录了一系列的堆栈调用信息）等等。我这边只看到了JNI_OnLoad，没有看到具体的行数。
高通平台的 Camera HAL 架构解析：QCamera 与 CHI HAL 实战剖析
努力分享一些人工智能、计算机视觉、影像等相关的知识干货！
06-21 1128
高通平台是 Android 移动终端中主流的 SoC 方案之一，其 Camera HAL 架构发展历程丰富，从传统 QCamera 到模块化 CHI HAL（Camera Hardware Interface HAL）再到底层 CamX 框架，逐步实现了从 ISP 驱动到 HAL 层的能力抽象与图像链路优化。本篇文章将基于最新高通平台（如 SM8550/SM7475 等）上的真实工程经验，系统梳理 QCamera 与 CHI HAL 架构的模块划分、控制流转、调试策略与平台适配机制，帮助开发者深入理解高通成
addr2line探秘
热门推荐
心慌慌
02-26 2万+
addr2line探秘 在Linux下写C/C++程序的程序员，时常与Core Dump相见。在内存越界访问，收到不能处理的信号，除零等错误出现时，我们精心或不精心写就的程序就直接一命呜呼了，Core Dump是Linux仁慈地留下的程序的尸体，帮助程序员们解决了一个又一个问题。 有时配置不给力，Linux直接毁尸灭迹，没有了Core文件；又有时，刚好磁盘空间不足，Core文件写不下了。没有C
addr2line
木子皿--啥都不会的菜鸟
12-14 1496
文章目录1 addr2line1.1 addr2line的用途1.2 addr2line的用法 1 addr2line 1.1 addr2line的用途 addr2line可以将指定的行号转换为对应的文件名和行号，常用于分析和定位内存访问错误的问题。 1.2 addr2line的用法 addr2line用来定位0地址访问的步骤如下： C代码如下： #include <stdio.h>...
安卓手机dump问题应该怎么分析
07-09
2. **自动化分析脚本** ```python # 示例：解析tombstone中的关键信息 import re with open("tombstone_00", "r") as f: for line in f: if "backtrace:" in line: print("崩溃堆栈:") elif re.match(r'#\d...
请列出安卓手机dump崩溃模式
最新发布
07-09
| Tombstone | Native崩溃 | 详细寄存器/堆栈信息 | `ndk-stack`, `addr2line` | | ANR Traces | 应用无响应 | 线程堆栈快照 | 直接阅读或脚本分析 | | 内核转储 | 内核崩溃 | 完整/部分内存镜像 | `crash`工具 | | ...
linux：binutils工具集---addr2line（段错误Segmentation fault 基本检查和tombstone分析)
SSSS的博客
01-05 1176
1. 测试代码 #include<stdio.h> void Segmentation_fault() { int *p = NULL; /* 这里会报 Segmentation fault */ *p = 1; } int main() { /* 调用 */ Segmentation_fault(); return 0; } 2.编译：添加 -g -o 选项 ...
Android Tombstone 分析
adl30141的博客
10-20 1960
1.什么是tombstone 当一个动态库（native 程序）开始执行时，系统会注册一些连接到debuggerd 的signal handlers，当系统 crash 的时候，会保存一个 tombstone 文件到/data/tombstones目录下（Logcat中也会有相应的信息），文件的确就像墓碑一样记录了死亡了的进程的基本信息（例如进程的进程号，线程号），死亡的地址（在哪...
Android NDK tombstone分析工具
可夫小子的频道
07-19 8766
Android NDK tombstone分析工具 在Andoird Native库发生异常的时候，Linux会发生不同级别的sig，来结构相关进程的运行，同时会产生tombstone trace文件用于记录发生崩溃寄存器和堆栈的状态。 这里面的涉及的知识点很多，但该文主要是介绍一下这种情况debug的工具stack.py。 1，keypoint a,Android sig/进程间通
Android NDK崩溃行定位
u012456479的博客
02-24 2834
logcat的崩溃信息保存到文件a.txt，崩溃信息大致如下： --------- beginning of crash 2022-02-24 14:46:37.948 26127-26127/com.example.myapplicationndk A/libc: Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0 in tid 26127 (yapplicationndk), pid 26127 (yapplicat.
Android-jni(6)-常见错误异常
ddxxii的博客
12-03 1万+
NDK异常信息一般有三个要素： 信号 调用栈信息 寄存器信息 比如一下是一个空指针的错误信息： A/libc: Fatal signal 11 (SIGSEGV), code 1, fault addr 0x0 in tid 31286 (shixin.ndkdemo) I/crash_dump32: obtaining output fd from tombstoned I//system...
android so库导致的闪退及tombstone分析
工宗浩生财指南针
04-18 2161
android中有3种crash情况：未捕获的异常、ANR和闪退。未捕获的异常一般用crash文件就可以记录异常信息，而ANR无响应表现就是界面卡着无法响应用户操作，而闪退则是整个app瞬间退出，个人感觉对用户造成的体验最差。闪退一般是由于调用so库出错导致，像类似非法地址访问等。闪退发生时在logcat中将日志过滤条件选为“No Filters”就可以看到完整的闪退日志，或者叫tombstone(墓碑)文件。
Android问题解决--“signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0xxxxxxx” 又出现了
记录和分享程序人生的点点滴滴
05-12 1万+
今天，调试一个app，又出现“signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0xxxxxx”问题了。 而且只在Android10以上版本才会有，导致的现象是app崩溃，这怎么怎？ 问题log： signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0x739ae8d004 全部log如下： 05-08 10:21:31.065 D/a.module(1890..
Android Native crash触发原理及处理
专注于系统快稳省领域
01-10 2493
当程序执行以下操作，会触发native crash：1）程序自己调用 abort() 函数触发，用于表示出现严重的错误或异常情况，需要终止程序执行2）内存对齐错误或非法地址访问3）零除错误（除数为零），浮点溢出或下溢出等4）使用了非法的机器指令或指令参数不当而导致5）进程试图访问不允许访问的内存地址，例如访问已释放的内存，或者栈溢出等6）常见于协处理器栈错误或FPU错误7）进程试图执行未定义或不支持的系统调用8）程序的特定位置设置断点时会触发SIGTRAP信号。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值