5.0.1版本qemu-arm-linux-min启动后Kernel Panic

【问题描述】

从 [https://gitee.com/openharmony/docs/blob/master/zh-cn/release-notes/OpenHarmony-v5.0.1-release.md#%E4%BB%8E%E9%95%9C%E5%83%8F%E7%AB%99%E7%82%B9%E8%8E%B7%E5%8F%96]() 下载 全量代码（标准、轻量和小型系统） 压缩包，解压缩后未进行任何修改。

使用命令：

hb build -p qemu-arm-linux-min

或者

./build.sh --product-name qemu-arm-linux-min --ccache --jobs 4

编译QEMU-ARM-LINUX镜像成功，未报错。

使用命令启动镜像

./vendor/ohemu/qemu_arm_linux_min/qemu_run.sh -e /xx/ohos5.0.1/OpenHarmony-v5.0.1-Release/OpenHarmony/out/qemu-arm-linux/packages/phone/images

结果 Kernel Panic：

[   10.079660][    T1] [pid=1][Init][INFO][init_cmds.c:383]DoUmount /data
[   10.085712][    T1] sysrq: Trigger a crash
[   10.086299][    T1] Kernel panic - not syncing: sysrq triggered crash
[   10.086713][    T1] CPU: 0 PID: 1 Comm: init Not tainted 5.10.208 #1
[   10.086992][    T1] Hardware name: Generic DT based system
[   10.087262][    T1] Backtrace: 
[   10.088056][    T1] [<c030ffa0>] (dump_backtrace) from [<c030ff88>] (show_stack+0x28/0x40)
[   10.088430][    T1]  r7:00000080 r6:c1c0a728 r5:00000000 r4:c16fcc15
[   10.088711][    T1] [<c030ff60>] (show_stack) from [<c1183b98>] (dump_stack+0xd8/0x120)
[   10.089032][    T1]  r5:60000093 r4:c16fcc15
[   10.089219][    T1] [<c1183ac0>] (dump_stack) from [<c1183420>] (panic+0x160/0x3e0)
[   10.089521][    T1]  r10:00000000 r8:c1b32df0 r7:00000000 r6:00000000 r5:c1cddbc0 r4:c16bb2d8
[   10.089946][    T1] [<c11832c0>] (panic) from [<c0b45e40>] (sysrq_handle_showlocks+0x0/0x20)
[   10.090308][    T1] [<c0b45e40>] (sysrq_handle_showlocks) from [<c0b45880>] (__handle_sysrq+0x1e0/0x280)
[   10.090668][    T1] [<c0b456a0>] (__handle_sysrq) from [<c0b46aec>] (write_sysrq_trigger+0xac/0xc0)
[   10.090988][    T1]  r10:00000004 r9:00000001 r8:c2955f60 r7:c4ebad80 r6:c1c68268 r5:00000063
[   10.091316][    T1]  r4:00000001
[   10.091460][    T1] [<c0b46aec>] (write_sysrq_trigger) from [<c05fb178>] (proc_reg_write+0x98/0x120)
[   10.091827][    T1] [<c05fb178>] (proc_reg_write) from [<c055f118>] (vfs_write+0x118/0x380)
[   10.092156][    T1] [<c055f000>] (vfs_write) from [<c055f540>] (ksys_write+0x80/0x100)
[   10.092479][    T1]  r10:00000004 r8:00000001 r7:c2955f60 r6:b6da6b58 r5:c4ebad80 r4:c4ebad80
[   10.092873][    T1] [<c055f4c0>] (ksys_write) from [<c055f5ec>] (sys_write+0x2c/0x40)
[   10.093242][    T1]  r9:c2954000 r8:c0300304 r7:00000004 r6:0000000b r5:b6da6b58 r4:00000001
[   10.093591][    T1] [<c055f5ec>] (sys_write) from [<c03000c0>] (ret_fast_syscall+0x0/0x2c)
[   10.093956][    T1] Exception stack(0xc2955f8c to 0xc2955fd4)
[   10.094316][    T1] 5f80:                            c055f5ec fffff000 b6dc9458 00000000 00000004
[   10.094763][    T1] 5fa0: 00000000 c03000c0 fffff000 b6dc9458 0000000b b6da6b58 00000001 00000000
[   10.095191][    T1] 5fc0: fffff000 b6dc9458 00000000 00000004 00000000
[   10.095880][    T1] Kernel Offset: disabled
[   10.096367][    T1] ---[ end Kernel panic - not syncing: sysrq triggered crash ]---

根据日志上下文，初步分析panic可能是由于前面的自动reboot导致的，附上完整日志

回复 cstriker1407: Hello, 请问题主解决了吗。我碰到的同样的问题 5.0上

根据日志结尾可以看到系统在启动到一定程度后，Panic，然后自动重启。回溯日志进行分析，发现有如下关键信息：

对比代码源文件：

可以初步分析为，一个名称为“foundation”的关键基础服务，尝试启动了4次均失败，然后系统Panic。

结合上下文分析代码调用流程，大概函数调用流程为：

1. ServiceReap
   
2. -ServiceStart
   
3. --RunChildProcess
   
4. ---ServiceExec
   
5. ----execv(pathArgs->argv[0], pathArgs->argv)

复制代码

经过对镜像目录进行分析，可以初步发现系统启动目录中有如下配置文件foundation.cfg：

该文件即为“foundation”的配置文件。综合对比代码，可以有初步结论，系统通过执行如下命令来启动foundation：

1. /system/bin/sa_main /system/profile/foundation.json

复制代码

对镜像文件进行分析，发现目录中没有该文件：

至此，可以初步断定foundation启动失败是因为配置文件缺失导致。

-----------------------------------

继续分析代码，通过查看配置文件，可以发现sa_main的编译源码为如下目录：

通过对该目录下的代码进行通读和测试，额外发现

1. bool LocalAbilityManager::CheckAndGetProfilePath(const std::string& profilePath, std::string& realProfilePath)
   
2. if (realpath(profilePath.c_str(), realPath) == nullptr)

复制代码

中的realpath 有错误，当入参已经是绝对路径时，realpath的调用会失败。