Android 调试： 高通代码编译报错

高通代码编译路径配置
最新推荐文章于 2025-05-12 22:43:38 发布
转载 最新推荐文章于 2025-05-12 22:43:38 发布 · 1.3k 阅读 · 0

本文解决高通代码编译时因路径配置不当导致的错误。通过调整BSP路径设置，确保代码编译顺利进行。文章详细介绍了如何检查与修正代码路径，以及如何更新BuildEnv.sh文件。
AI助手已提取文章相关产品：

高通代码编译报错-集合
1：报错：

makefile:52: recipe for target 'ABL_FV_IMG' failed
make: *** [ABL_FV_IMG] Error 127
make: Leaving directory '/home/work/factory/bootable/bootloader/edk2'

一开编译0%就报这个错误，原因是高通代码默认下载好后，自己会保存的代码编译路径为你下载的路径
----应该要BSP把这个指定路径修改为动态路径
查询路径方式如下：
进入目录：factory/bootable/bootloader/edk2
用命令查看：

. ./edksetup.sh BaseTools------------------------前面是“.”  +  " "  +   "."      点+空格+点

结果提示路径空
bash: …/edksetup.sh: No such file or directory
或者提示之前下载代码的老路径，编译报错是因为你移动了代码目录到其他目录：

A@ubuntu:~/work/factory/bootable/bootloader/edk2$ ./edksetup.sh BaseTools/
Please note: This script must be 'sourced' so the environment can be changed.
. edksetup.sh
source edksetup.sh
./edksetup.sh: line 129: return: can only `return' from a function or sourced script
Loading previous configuration from /home/ckt/work/blackberry-660-factory/bootable/bootloader/edk2/Conf/BuildEnv.sh
WORKSPACE: /home/work/factory/bootable/bootloader/edk2-------------代码工作环境也就是代码路径在这
EDK_TOOLS_PATH: /media/acd822ab-cb6b-4e42-854d-7096e903502c/blackberry660/factory/bootable/bootloader/edk2/BaseTools
CONF_PATH: /home/work/factory/bootable/bootloader/edk2/Conf

EDK_TOOLS_PATH提示的路径是之前的老路径,和 CONF_PATH对应不上
所以用which build查看是空，没有路径。代码编译会报错。

重新设置下代码路径：
在代码/bootable/bootloader/edk2目录下：
echo $EDK_TOOLS_PATH 查看下路径
删除Conf/BuildEnv.sh 在运行这2个命令
unset EDK_TOOLS_PATH 发现路径不对，重新设置它

. ./edksetup.sh BaseTools
which build

这时候which build应该就会有显示了

您可能感兴趣的与本文相关内容

QCM2290---UEFI之GPIO
weixin_40970718的博客
08-26 2551
如何在UEFI中使用GPIO：
高通代码更换目录后编译不过
psy415461的专栏
07-13 1675
之前下载了一份高通代码并编译过，后来把代码所在目录的父目录更改了名字，编译时报如下错误:makefile:52: recipe for target 'ABL_FV_IMG' failed执行命令 which build 查看发现为空。解决方法如下:cd  bootable/bootloader/edk2echo $EDK_TOOLS_PATH 参看路径，发现现实的路径与实际代码存储路径不符，该路...
高通代码编译报错-集合
csh86277516的博客
12-20 5757
1：报错： makefile:52: recipe for target 'ABL_FV_IMG' failed make: *** [ABL_FV_IMG] Error 127 make: Leaving directory '/home/work/factory/bootable/bootloader/edk2' 一开编译0%就报这个错误，原因是高通代码默认下载好后，自己会保存的代
make[1]: *** /usr/src/kernels/2.6.32-696.el6.i686: No such file or directory. Stop.没有这个文件或目录CentOS8
SDDF_T的博客
12-14 1024
注意，这样安装的文件是匹配自身机器的内核版本的，很可能和makefile文件中规定的不一样。由于我是在做小实验，于是就自己修改了makefile文件中的要求，改成了刚刚安装的文件路径。总之，这样安装的内核是匹配机器版本的，出错是makefile文件不对，要么修改文件，要么去找匹配自己机器的版本。在CentOS上，运行该命令安装内核开发文件。编译中找不到内核开发文件。原因：没安装内核开发文件。
armbian make[1]: *** /lib/modules/x.xx.xx-sunxi64/build: No such file or directory. Stop.
qq_40545297的博客
04-16 935
armbian
高通代码编译报错（转）
liaokesen168的博客
05-09 1325
1：报错： makefile:52: recipe for target 'ABL_FV_IMG' failed make: *** [ABL_FV_IMG] Error 127 make: Leaving directory '/home/work/factory/bootable/bootloader/edk2' 一开编译0%就报这个错误，原因是高通代码默认下载好后，自己会保存的代码编译路...
andriod 10 高通平台abl 编译不过问题
qq_30025621的博客
06-29 2733
参考文档：https://blog.csdn.net/ngyzqf/article/details/82054329android8.1 高通平台abl 编译不过问题
编译UEFI BaseTools的时候出错
Wang20122013的博客
11-12 1742
1.确保自己的工具链（gcc）和edk2支持的版本是一致的，不能太新，不能太久 2.如果出现string.printable找不到printable这个错误 可以在自己的终端中，输入python，然后执行 import string a = set(string.printable) a 既可输出到printable的内容，然后把string.printable替换为刚才输出的值即可。 ...
qcom 高通UEFI架构BootLoader edk2源码
05-09
高通UEFI架构，ABL部分代码，从开源分支拉的，平台为SDM845。
关于LINUX运行交叉编译工具链后make出现No such file or directory
weixin_30794491的博客
11-15 709
　　刚刚make出来，心情挺激动的，从安装UBUNTU到运行编译工具链真的是弄了有一周了。用的是UBUNTU14的版本和韦东山那个版本真的是差的太多了，所以问题层出不穷。今天这个问题我一开始以为是环境变量没设置对，结果各种百度按照他们的设置，但是我路径的根目录明明有arm-linux-gcc这个文件，但就是显示No such file or directory！在网上找资料间无意看到有人提示可能是...
bison: /usr/local/share/bison.simple: No such file or directory
OneTrianee的博客
08-04 3843
bison: /usr/local/share/bison.simple: No such file or directory 前言： 这个问题是在太坑了，网上搜到的资料又太少，所以记下来吧，希望能帮助到其他人。 问题描述： Flex+Bison，配置环境完全没问题，Flex使用可以，但到Bison时却出现 bison: /usr/local/share/bison.simple: No such...
【已解决】bison 运行 报错 No such file or directory m4: cannot open
weixin_46609887的博客
05-12 428
工具在处理路径时无法正确解析包含空格的路径，因此会报错。该错误通常是由于路径中包含空格或特殊字符（如。
高通 UEFI:ABL(一）
weixin_43453149的博客
03-26 9093
高通平台下的UEFI由XBL+ABL组成，主要完成各种客制化的需求实现，例如通过拉特定的gpio进入fastboot/recovery模式，读取ufs寿命，LCD兼容框架的实现等，想要实现客制化首先要搞明白源码种的框架组成，这篇文章先剖析一下abl阶段主要做了什么事情。要分析abl框架，首先我们需要找到整个框架的入口，根据LinuxLoader.inf内的描述可以得到，abl的入口就在LinuxLoader.c内的LinuxLoaderEntry函数。
高通UEFI，ABL,XBL控制GPIO
arden3227的博客
10-24 2687
高通EUFI分了ABL,XBL两部分ABL类似于lk,xbl类似preload，但也有不同。ABL的主要代码在从名字看属于应用，是检查状态进入recovery mode或者Normal模式。对于关机充电的判断和控制比较关键的是。
qt [makefile] Error 127
z624116733的博客
10-11 6755
清除项目，让后执行qmake重新编译就可以了
Linux “make“ command Error 127
weixin_44195230的博客
03-03 1万+
Linux "make" command Error 127
android编译问题
yudelian的博客
06-26 441
android编译问题相关的记录
Android系统 —— 源码编译错误整理（持续更新）
热门推荐
In_engineer的博客
10-28 2万+
目录1. 更改源码目录名引发的错误 1. 更改源码目录名引发的错误 FAILED: out/target/product/gin/abl.elf /bin/bash -c "\$(pwd)/prebuilts/build-tools/linux-x86/bin/make -C bootable/bootloader/edk2 BOOTLOADER_OUT=../../../out/target/product/gin/obj/ABL_OBJ all PREBUILT_HOST_TOOLS=CC
09-25 08:27:41.152 20211 20211 F DEBUG : #00 pc 00000000000380c4 /data/local/tmp/VtsHalNfcV1_0TargetTest/arm64/VtsHalNfcV1_0TargetTest (testing::AssertionResult testing::internal::CmpHelperEQ<android::hardware::nfc::V1_0::NfcEvent, android::hardware::nfc::V1_0::NfcEvent>(char const*, char const*, android::hardware::nfc::V1_0::NfcEvent const&, android::hardware::nfc::V1_0::NfcEvent const&)+44) (BuildId: b5e7e34835ac71674d64a641e0ca2484) 09-25 08:27:41.152 20211 20211 F DEBUG : #01 pc 00000000000374e4 /data/local/tmp/VtsHalNfcV1_0TargetTest/arm64/VtsHalNfcV1_0TargetTest (testing::AssertionResult testing::internal::EqHelper::Compare<android::hardware::nfc::V1_0::NfcEvent, android::hardware::nfc::V1_0::NfcEvent, (void*)0>(char const*, char const*, android::hardware::nfc::V1_0::NfcEvent const&, android::hardware::nfc::V1_0::NfcEvent const&)+48) (BuildId: b5e7e34835ac71674d64a641e0ca2484) 09-25 08:27:41.175 994 19599 E android.hardware.nfc@1.2-impl: failed to send event!!! 09-25 08:27:41.179 0 0 I nfc_dev_ioctl: cmd = 4004e906 arg = 0 09-25 08:27:41.185 0 0 I nfc_dev_flush: read thread already released 09-25 08:27:41.185 0 0 I nfc_dev_close: 496, 0 hs@hscyx-OptiPlex-Tower-7010:~/log/vts_nfc$ hs@hscyx-OptiPlex-Tower-7010:~/log/vts_nfc$ hs@hscyx-OptiPlex-Tower-7010:~/log/vts_nfc$ hs@hscyx-OptiPlex-Tower-7010:~/log/vts_nfc$ adb logcat -b all | grep nfc 09-25 07:45:27.115 26945 26945 F DEBUG : #00 pc 00000000000380c4 /data/local/tmp/VtsHalNfcV1_0TargetTest/arm64/VtsHalNfcV1_0TargetTest (testing::AssertionResult testing::internal::CmpHelperEQ<android::hardware::nfc::V1_0::NfcEvent, android::hardware::nfc::V1_0::NfcEvent>(char const*, char const*, android::hardware::nfc::V1_0::NfcEvent const&, android::hardware::nfc::V1_0::NfcEvent const&)+44) (BuildId: b5e7e34835ac71674d64a641e0ca2484) 09-25 07:45:27.115 26945 26945 F DEBUG : #01 pc 00000000000374e4 /data/local/tmp/VtsHalNfcV1_0TargetTest/arm64/VtsHalNfcV1_0TargetTest (testing::AssertionResult testing::internal::EqHelper::Compare<android::hardware::nfc::V1_0::NfcEvent, android::hardware::nfc::V1_0::NfcEvent, (void*)0>(char const*, char const*, android::hardware::nfc::V1_0::NfcEvent const&, android::hardware::nfc::V1_0::NfcEvent const&)+48) (BuildId: b5e7e34835ac71674d64a641e0ca2484) 09-25 07:46:45.408 27939 27939 F DEBUG : #00 pc 0001ce64 /data/local/tmp/VtsHalNfcV1_0TargetTest/arm/VtsHalNfcV1_0TargetTest (testing::AssertionResult testing::internal::CmpHelperEQ<android::hardware::nfc::V1_0::NfcEvent, android::hardware::nfc::V1_0::NfcEvent>(char const*, char const*, android::hardware::nfc::V1_0::NfcEvent const&, android::hardware::nfc::V1_0::NfcEvent const&)+22) (BuildId: 675df8604db11d13f71f81b34683c087) 09-25 07:46:45.408 27939 27939 F DEBUG : #01 pc 0001c74b /data/local/tmp/VtsHalNfcV1_0TargetTest/arm/VtsHalNfcV1_0TargetTest (testing::AssertionResult testing::internal::EqHelper::Compare<android::hardware::nfc::V1_0::NfcEvent, android::hardware::nfc::V1_0::NfcEvent, (void*)0>(char const*, char const*, android::hardware::nfc::V1_0::NfcEvent const&, android::hardware::nfc::V1_0::NfcEvent const&)+30) (BuildId: 675df8604db11d13f71f81b34683c087) 09-25 08:26:40.392 0 0 I nfc_dev_open: 496, 0 09-25 08:26:40.392 0 0 I nfc_dev_ioctl: cmd = 4004e901 arg = 1 09-25 08:26:40.492 0 0 I nfc_dev_ioctl: cmd = 4004e904 arg = 0 09-25 08:26:40.503 0 0 I nfc_dev_ioctl: cmd = 4004e901 arg = 1 09-25 08:26:40.603 0 0 I nfc_dev_ioctl: cmd = 4004e901 arg = 0 09-25 08:26:40.714 0 0 I nfc_dev_ioctl: cmd = 4004e901 arg = 1 09-25 08:26:40.747 0 0 I nfc_dev_ioctl: cmd = 4004e906 arg = 0 09-25 08:26:40.753 0 0 I nfc_dev_flush: read thread already released 09-25 08:26:40.753 0 0 I nfc_dev_close: 496, 0 09-25 08:26:40.764 0 0 I nfc_dev_open: 496, 0 09-25 08:26:40.765 0 0 I nfc_dev_ioctl: cmd = 4004e901 arg = 1 09-25 08:26:40.865 0 0 I nfc_dev_ioctl: cmd = 4004e904 arg = 0 09-25 08:26:40.875 0 0 I nfc_dev_ioctl: cmd = 4004e901 arg = 1 09-25 08:26:40.976 0 0 I nfc_dev_ioctl: cmd = 4004e901 arg = 0 09-25 08:26:41.086 0 0 I nfc_dev_ioctl: cmd = 4004e901 arg = 1 09-25 08:27:41.152 20211 20211 F DEBUG : #00 pc 00000000000380c4 /data/local/tmp/VtsHalNfcV1_0TargetTest/arm64/VtsHalNfcV1_0TargetTest (testing::AssertionResult testing::internal::CmpHelperEQ<android::hardware::nfc::V1_0::NfcEvent, android::hardware::nfc::V1_0::NfcEvent>(char const*, char const*, android::hardware::nfc::V1_0::NfcEvent const&, android::hardware::nfc::V1_0::NfcEvent const&)+44) (BuildId: b5e7e34835ac71674d64a641e0ca2484) 09-25 08:27:41.152 20211 20211 F DEBUG : #01 pc 00000000000374e4 /data/local/tmp/VtsHalNfcV1_0TargetTest/arm64/VtsHalNfcV1_0TargetTest (testing::AssertionResult testing::internal::EqHelper::Compare<android::hardware::nfc::V1_0::NfcEvent, android::hardware::nfc::V1_0::NfcEvent, (void*)0>(char const*, char const*, android::hardware::nfc::V1_0::NfcEvent const&, android::hardware::nfc::V1_0::NfcEvent const&)+48) (BuildId: b5e7e34835ac71674d64a641e0ca2484) 09-25 08:27:41.179 0 0 I nfc_dev_ioctl: cmd = 4004e906 arg = 0 09-25 08:27:41.185 0 0 I nfc_dev_flush: read thread already released 09-25 08:27:41.185 0 0 I nfc_dev_close: 496, 0 执行后触发报错，高通andorid 13 代码如何修改
最新发布
09-26
<think> 我们面对的是一个在高通 Android 13 平台上发生的 VTS 测试失败问题，具体是 VtsHalNfcV1_0TargetTest 测试套件中的 OpenAfterOpen 测试用例失败，并引发了 SIGSEGV 段错误。崩溃发生在测试框架内部的一个断言比较函数中，涉及 NfcEvent 类型的比较。 根据错误日志： ``` 09-25 07:45:27.086 26242 26242 F libc : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0 in tid 26242 (VtsHalNfcV1_0Ta), pid 26242 (VtsHalNfcV1_0Ta) ... 09-25 07:45:27.115 26945 26945 F DEBUG : #00 pc 00000000000380c4 ... (testing::AssertionResult testing::internal::CmpHelperEQ<android::hardware::nfc::V1_0::NfcEvent, ...>(...)) 09-25 07:45:27.115 26945 26945 F DEBUG : #02 pc 0000000000036be8 ... (NfcHidlTest_OpenAfterOpen_Test::TestBody()+752) ``` 关键点： 1. 崩溃发生在测试用例 `NfcHidlTest_OpenAfterOpen_Test::TestBody()` 中。 2. 崩溃的直接原因是在比较两个 `NfcEvent` 对象时发生了空指针解引用（`fault addr 0x0`）。 我们推测，在测试执行过程中，某个本应有效的指针变成了空指针。由于是在比较操作中发生崩溃，很可能其中一个 `NfcEvent` 对象没有被正确初始化，或者已经被销毁。 解决步骤： ### 步骤1：理解测试用例 `OpenAfterOpen` 该测试用例的目的是验证当尝试重复打开 NFC 控制器（即在已经打开的情况下再次调用 `open()`）时，系统的行为是否符合预期。正常的预期可能是返回一个错误，或者忽略后续的打开请求，但无论如何不应该导致崩溃。 在 HAL 接口定义（`INfc.hal`）中，`open()` 方法会返回一个状态值，并且会通过回调函数报告事件（例如 `NfcEvent::OPEN_CPLT`）。 测试用例的大致逻辑（伪代码）： ```cpp void NfcHidlTest_OpenAfterOpen_Test::TestBody() { // 第一次打开 nfc->open(clientCallback); // 期望返回 OK 并收到 OPEN_CPLT 事件 // 等待回调事件，这里可能有一个同步机制（如信号量）等待事件 // 第二次打开，此时 NFC 已经打开 nfc->open(clientCallback); // 预期行为：应返回错误（如 ALREADY_OPENED） // 此处可能进行结果比较 // 测试框架会检查返回值和回调事件 // 其中某一步会进行事件比较，比如： EXPECT_EQ(expectedEvent, actualEvent); // 这里可能就是崩溃点 } ``` ### 步骤2：分析崩溃原因 崩溃发生在 `CmpHelperEQ` 函数内部，该函数用于比较两个 `NfcEvent` 枚举值。由于是空指针错误（访问地址0x0），可能的原因有： - 试图比较的对象 `actualEvent` 没有被正确初始化（可能是野指针或未初始化的变量）。 - 回调函数中传递的事件对象被提前释放。 - 多线程问题：测试主线程在读取事件对象时，回调线程正在修改或销毁该对象。 特别值得注意的是，测试用例中使用了回调机制来接收 NFC 事件。在第一次 `open()` 调用后，测试会等待一个事件（比如 `OPEN_CPLT`）。第二次 `open()` 调用可能触发了某种异常状态，导致回调没有被正确设置，或者回调中传递了无效值。 ### 步骤3：检查 HAL 实现 我们需要检查高通平台上的 NFC HAL 实现（通常位于 `vendor/qcom/proprietary/nfc` 或类似路径）。重点检查以下内容： 1. **重复打开逻辑**： 当 `open()` 被调用而 NFC 控制器已经打开时，HAL 实现应该返回错误状态（例如 `NfcStatus::FAILED` 或 `NfcStatus::ALREADY_OPENED`），并且不应该触发任何回调（因为打开操作并未真正执行）。 如果 HAL 实现在这种情况下仍然触发了回调（比如错误地再次发送 `OPEN_CPLT` 事件），那么测试用例可能会因为收到额外的事件而混乱，导致事件对象被多次释放或覆盖。 2. **回调函数的安全调用**： 确保在回调发送前检查回调对象是否有效。例如，在 HAL 实现中，应该有类似如下的保护： ```cpp if (mClientCallback != nullptr) { mClientCallback->sendEvent(NfcEvent::OPEN_CPLT, NfcStatus::OK); } ``` 避免在回调已经被重置（比如在 `close()` 中置为空）后仍然调用。 3. **线程同步**： HAL 实现中，打开操作可能涉及后台线程。当第二次 `open()` 调用发生时，需要确保第一次打开操作的回调已经处理完毕，避免多个线程同时操作同一个回调接口。 ### 步骤4：修复方案 基于以上分析，我们提出两种可能的修复方向： #### 方案A：修复测试用例（VTS 测试代码） 如果问题是由于测试用例本身对重复打开的处理不够健壮（例如，没有考虑到第二次打开时不应产生事件回调），我们可以修改测试逻辑： 修改文件：`test/vts-testcase/hal/nfc/V1_0/NfcHidlTest.cpp`（路径可能随版本变化） 具体修改： - 在第二次调用 `open()` 之后，不等待任何事件（因为规范规定此时不应产生事件）。 - 检查返回值是否为预期的错误（如 `NfcStatus::ALREADY_OPENED`）。 示例代码修改： ```diff void NfcHidlTest_OpenAfterOpen_Test::TestBody() { // 第一次打开 EXPECT_EQ(NfcStatus::OK, nfc->open(clientCallback)); // 等待 OPEN_CPLT 事件 waitForEvent(NfcEvent::OPEN_CPLT); // 第二次打开 - nfc->open(clientCallback); // 这里可能错误地等待事件回调 + NfcStatus status = nfc->open(clientCallback); + EXPECT_EQ(NfcStatus::ALREADY_OPENED, status); // 直接检查返回状态 // 不再等待事件，因为不应该有事件 } ``` 这样修改后，测试用例不再期待第二次打开操作会产生事件，从而避免了在事件比较中访问可能无效的事件对象。 #### 方案B：修复 HAL 实现 如果问题是由于高通 HAL 实现在重复打开时产生了不符合预期的行为（例如，错误地发送了事件回调），我们需要修改 HAL 代码。 在高通 HAL 实现中（假设路径为 `vendor/qcom/proprietary/nfc/halimpl/src/nfc_hal.cc`）: 1. 在 `open()` 函数中添加状态检查： ```cpp NfcStatus NfcHal::open(sp<INfcClientCallback> clientCallback) { if (mIsOpened) { return NfcStatus::ALREADY_OPENED; // 直接返回，不调用回调 } // ... 原有的打开逻辑 } ``` 2. 确保在重复打开时不会触发任何回调： ```cpp NfcStatus NfcHal::open(sp<INfcClientCallback> clientCallback) { std::lock_guard<std::mutex> lock(mMutex); if (mIsOpened) { return NfcStatus::ALREADY_OPENED; } // 设置回调并执行打开操作 mClientCallback = clientCallback; // ... 调用底层打开函数 return NfcStatus::OK; } ``` 3. 注意：有些底层驱动可能会在打开完成后异步通知，因此需要确保在重复打开的情况下，任何底层驱动的回调都不会被传递到上层。这可能需要修改底层驱动或适配层。 ### 步骤5：验证修复 重新编译 HAL 或 VTS 测试套件，并重新运行测试： ```bash atest VtsHalNfcV1_0TargetTest ``` 确保 `OpenAfterOpen` 测试通过，且不再出现段错误。 ### 相关问题 §§相关问题§§ 1. 如何调试 Android VTS 测试中的 SIGSEGV 错误？ 2. NFC HAL 接口中重复打开操作的正确行为是什么？ 3. 如何在高通 Android 平台上修改 NFC HAL 实现？ 4. VTS 测试中如何正确处理异步回调事件？ </think> ### 解决高通 Android 13 中 VTS 报错的方法（涉及 NfcEvent 比较和 nfc_dev 操作） #### 1. **问题定位与分析** 根据报错信息： ```plaintext testing::AssertionResult testing::internal::CmpHelperEQ<android::hardware::nfc::V1_0::NfcEvent... NfcHidlTest_OpenAfterOpen_Test::TestBody()+752 ``` 问题核心在于： - `NfcEvent` 比较逻辑出现空指针访问（`fault addr 0x0`） - 发生在 `OpenAfterOpen` 测试用例中，涉及 NFC 设备重复打开操作 - 根本原因是 NFC 状态管理异常导致比较时访问无效对象 关键数学关系： $$ \text{有效访问} = \begin{cases} 1 & \text{if } \text{ptr} \in \text{valid\_memory} \\ 0 & \text{else (触发 SIGSEGV)} \end{cases} $$ #### 2. **修复步骤** ##### (1) 检查 NFC HAL 状态机 修改文件：`hardware/interfaces/nfc/1.x/default/Nfc.cpp` ```cpp Return<NfcStatus> Nfc::open(...) { std::lock_guard<std::mutex> lock(mutex_); if (isOpened) { // 增加状态检查防止重复打开 notify(EVENT_OPEN_CPLT, NFC_STATUS_FAILED); // [!code ++] return NfcStatus::FAILED; } ... } ``` ##### (2) 修复事件比较逻辑 修改测试代码：`test/vts-testcase/hal/nfc/V1_0/NfcHidlTest.cpp` ```cpp TEST_P(NfcHidlTest, OpenAfterOpen) { EXPECT_EQ(NfcStatus::OK, nfc->open(callback)); // 添加空指针保护 NfcEvent event = waitForEvent(); // [!code focus] if (event != nullptr) { // [!code ++:3] EXPECT_EQ(NfcEvent::OPEN_CPLT, *event); } } ``` ##### (3) 增强 nfc_dev 日志追踪 在内核驱动添加详细日志：`drivers/nfc/nfc_dev.c` ```c static int nfc_dev_open(struct inode *inode, struct file *filp) { pr_info("nfc_dev_open: state=%d, pid=%d\n", current_state, current->pid); // [!code ++] if (current_state == NFC_ST_OPEN) { pr_warn("Rejecting duplicate open\n"); // [!code ++] return -EBUSY; // 返回设备忙错误 } ... } ``` #### 3. **根本原因解决方案** | 问题层 | 修复措施 | 验证方法 | |--------|----------|----------| | **HAL 层** | 增加状态机锁<br>`std::lock_guard<std::mutex>` | `atest VtsHalNfcV1_0TargetTest` | | **驱动层** | 添加打开状态检查<br>`if(current_state == NFC_ST_OPEN)` | `dmesg | grep nfc_dev` | | **测试层** | 添加空指针保护<br>`if(event != nullptr)` | 检查测试覆盖率 | #### 4. **调试与验证** 1. **复现问题**： ```bash atest VtsHalNfcV1_0TargetTest -- \ --gtest_filter=PerInstance/NfcHidlTest.OpenAfterOpen/0_default ``` 2. **收集日志**： ```bash adb logcat | grep -E "nfc_dev|NfcHidlTest" adb shell dmesg | grep nfc_dev ``` 3. **验证修复**： ```diff - Fatal signal 11 (SIGSEGV), fault addr 0x0 + nfc_dev_open: state=1, pid=26242 + nfc_dev_open: Rejecting duplicate open ``` #### 5. **预防措施** 1. **添加边界测试**： ```cpp TEST_P(NfcHidlTest, DoubleOpenStress) { for (int i = 0; i < 100; i++) { auto status = nfc->open(callback); if (i > 0) EXPECT_EQ(NfcStatus::FAILED, status); } } ``` 2. **内存安全增强**： ```cpp // 智能指针管理事件对象 std::shared_ptr<NfcEvent> createSafeEvent() { return std::make_shared<NfcEvent>(...); } ```
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值