注:本文重要信息使用 ***
屏蔽关键字。
最近国庆前,项目碰到一个很麻烦的问题,这个问题让我们加班到凌晨三点。
大概背景:
客户给了一些 C语言 写的 SDK 库,这些库打包成 .so 文件,然后我们使用 C# 调用这些库,其中有一个函数是回调函数,参数是结构体,结构体的成员是函数,将 C# 的函数赋值给委托,然后存储到这个委托中。
C# 调用 C 语言的函数,然后 C 语言执行到一些步骤后, C 语言函数调用 C# 的函数。这个在 ARM64 的机器下,是正常的,例如树莓派,华为的鲲鹏服务器等。由于突然改成使用 X64 的机器部署项目,没有测试就直接打包了(Docker)。
没有测试的原因有两个:
一是,众所周知 .NET Core 是跨平台的,既然在 ARM64 下已经测试过,那么应该没问题;
二是,项目是华为 edge IoT 项目,必须走华为云注册边缘设备,然后通过云服务下发应用(Docker)到机器才能成功运行(有许多系统自动创建的环境变量和设备连接华为 IoT 的凭证)。在机器上直接启动,是无法正常完成整个流程的。
三是,事情来得太突然,没有时间测试。
事实上,就是这么幸福,出事的时候就是加班福报~~~
大家记得,要部署上线、演示项目之前,一定要测试,测试再测试。
应用在云上下发到设备后,启动一会儿就会挂了,然后修改 Docker 容器的启动脚本,进入容器后,手动执行命令启动程序。
最后发现:
dotnet xxx.dll ... ... Segmentation fault (core dumped)
出现这个 Segmentation fault (core dumped)
问题可能是指针地址越界、访问不存在的内存、内存受保护等,参考: http://ilinuxkernel.com/?p=1388
https://www.geeksforgeeks.org/core-dump-segmentation-fault-c-cpp/
由于这个问题是内核级别的,所以可以从系统日志中找到详细的日志信息。
容器和物理机都可以查看日志,但是容器里面的信息太少,主要从物理机找到信息的日志。
在物理机:
# 内核日志 cat /var/log/kern.log
# 系统日志 cat /var/log/syslog
刚开始时,大佬提示可能是内存已被回收,函数等没有使用静态来避免 gc 回收,可能在 C 回调之前,C# 中的那部分内存就以及回收了。
但是我修改代码,都改成静态,并且打印地址,还禁止 GC 回收,结果还是一样的。
查看引用类型在内存中的地址 :
public string getMemory(object o) { GCHandle h = GCHandle.Alloc(o, GCHandleType.WeakTrackResurrection); IntPtr addr = GCHandle.ToIntPtr(h); return "0x" + addr.ToString("X"); }
禁止 GC 回收:
GC.TryStartNoGCRegion(1); ... ... GC.EndNoGCRegion();
经过提示,知道可以使用 GDB 调试 .so,于是马上 Google 查找资料,经过一段时间后,学会了使用这些工具查询异常堆栈信息。
GNU Debugger,也称为 gdb,是用于 UNIX系统调试 C 和 C ++ 程序的最流行的调试器。
If a core dump happened, then what statement or expression did the program crash on?
If an error occurs while executing a function, what line of the program contains the call to that function, and what are the parameters?
What are the values of program variables at a particular point during execution of the program?
What is the result of a particular expression in a program?
你可以使用在线的 C/C++ 编译器和 GDB ,在线体验一下:https://www.onlinegdb.com/
回到正题,要在 物理机或者 Docker 里面调试 .NET 的程序,要安装 GDB,其过程如下。
使用 apt install gdb
或者 yum install
就直接可以安装 gdb。
另外 strace 这个工具也是很有用的,能够看到堆栈信息,使用 apt install strace
即可安装上。
objcopy、strip 这两个工具可以将 .so 库的符号信息整理处理。
objcopy 、strip安装:
apt install binutils
binutils 包含了 objcopy 和 strip。
在使用 GDB 调试之前,我们了解一下 core dump 转储文件。
core dump 是包含进程的地址空间(存储)时的过程意外终止的文件。详细了解请点击:https://wiki.archlinux.org/index.php/Core_dump
相当于 .NET Core 的 dotnet-dump 工具生成的 快照文件。
为了生成转储文件,需要操作系统开启功能。
在物理机上执行:
ulimit -c unlimied
在 docker 里面执行:
ulimit -c unlimied
自定义将转储文件存放到目录
echo "/tmp/core-%e-%p-%t" > /proc/sys/kernel/core_pattern
然后进入容器,直接使用 dotnet 命令启动 .NET 程序,等待程序崩溃出现:
dotnet xxx.dll ... ... Segmentation fault (core dumped)
查看 tmp 目录,发现生成了 corefile-dotnet-{进程id}-{时间}
格式的文件。
使用命令进入 core dump
文件。
gdb -c corefile-dotnet-376-1602236839
执行 bt
命令。
发现有信息,但是可用信息太少了,而且名称都是 ??
,这样完全定位不到问题的位置。怎么办?
可以将 .so 文件一起包进来检查。
gdb -c corefile-dotnet-376-1602236839 /***/lib***.so
也可以使用多个 .so 一起加入
gdb -c corefile-dotnet-376-1602236839 /***/libAAA.so /***/libBBB.so
Linux中的 strace 命令可以跟踪系统调用和信号。
如果系统没有这个命令,可以使用 apt install strace
或者 yum install strace
直接安装。
然后使用 strace 命令启动 .NET 程序。
strace dotnet /***/***.dll
启动后就可以看到程序的堆栈信息,还可以看到函数调用时的函数定义。
执行以下命令即可启动 .NET Core runtime:
gdb dotnet
在 gdb 中 执行 start
启动程序。但是因为仅启动 .NET Core runtime
是没用的,还要启动 .NET 程序。
所以,要启动的 .NET 程序,要将其路径作为参数传递给 dotnet。
start /***/***.dll
终端显示:
(gdb) start /***/***.dll Function "main" not defined. Make breakpoint pending on future shared library load? (y or [n]) y Temporary breakpoint 1 (main) pending.
这样有点麻烦,我们可以在启动时就定义好参数:
gdb --args dotnet /***/***.dll
另外,run 是立即执行,start 会出现询问信息,还可以进行断点调试。
待程序运行崩溃之后。
然后使用 bt
命令查看异常的堆栈信息。
生成结果如下:
在 linux中, strip 命令具体就是从特定文件中剥掉一些符号信息和调试信息,可以使用以下步骤的命令,将调试信息从 .so 文件中剥出来。
objcopy --only-keep-debug lib***.so lib***.so.debug
strip lib***.so -o lib***.so.release
objcopy --add-gnu-debuglink=lib***.so.debug lib***.so.release
cp lib***.so.release lib***.so
要调试 .NET Core 程序,需要 .pdb 符号文件;要调试 .so 文件,当然也要携带一下符号信息才能调试。
可以通过以下方式判断一个 .so 文件是否能够调试。
gdb xxx.so
如果不能读取到调试信息,则是:
Reading symbols from xxx.so...(no debugging symbols found)...done.
如果能够读取到调试信息,则是:
Reading symbols from xxx.so...done.
同时还可以使用 file xxx.so 命令,
xxx.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=8007fbdc7941545fe4e0c61fa8472df1475887c3c1, stripped
如果最后是 stripped,则说明该文件的符号表信息和调试信息已被去除或不携带,不能使用 gdb 调试。
启动调试,目的是启动 .NET Core runtime 启动 .NET 程序,Linux 和 GDB 是无法直接启动 .NET 程序的。
这时就需要使用到 CLI 命令,使用 dotnet
命令启动一个 .NET 程序。
gdb --args dotnet /***/***.dll
或者
gdb dotnet ... # 进入GDB 后 set args /***/***.dll
以下两个 gdb 命令都可以查看当前调用堆栈信息,如果程序在调用某个函数时崩溃退出,则执行这些命令,会看到程序终止时的函数调用堆栈。
bt bt full backtrace backtrace full
bt 是 backtrace 的缩写,两者完全一致。
查看当前代码运行位置,如果程序已经终止,则输出程序终止前最后执行的函数堆栈。
where
使用 bt
可以看到函数的调用关系,哪个函数调用哪个函数,在哪个函数里面出现了异常。
#0 0x00007fb2cd5f66dc in ?? () from /lib/lib***.so #1 0x00007fb2ccf29d46 in ***_receiveThread () from /lib/lib***BBB.so.1 #2 0x00007fb456ef1fa3 in start_thread (arg=) at pthread_create.c:486 #3 0x00007fb456afc4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
bt full
可以看到更加详细的信息。
[Thread 0x7fb2b53b7700 (LWP 131) exited] Thread 31 "dotnet" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fb2affff700 (LWP 133)] 0x00007fb2cd5f66dc in ?? () from /lib/lib***.so (gdb) bt full #0 0x00007fb2cd5f66dc in ?? () from /lib/lib***.so No symbol table info available. #1 0x00007fb2ccf29d46 in ***_receiveThread () from /lib/lib***BBB.so.1 No symbol table info available. #2 0x00007fb456ef1fa3 in start_thread (arg=) at pthread_create.c:486 ret =pd =now =unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140405433693952, 264024675094789190, 140405521476830, 140405521476831, 140405433693952, 140407320872320, -229860650334651322, -233434198962832314}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call =#3 0x00007fb456afc4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 No locals.
可以看到,实际问题发生在另一个 .so 库上,所以我们还需要对这个 .so 制作调试信息。
lib***BBB.so.1
之前定位到,问题也许跟 in ?? () from /lib/lib***.so
有关,但是这里的信息为 ??
,能不能找到更多的信息呢?
我们先删除 /tmp 目录中的文件内容。
然后使用 strace dotnet /xxx/dll
或者 dotnet xxx.dll
重新执行一次,等待 /tmp 目录生成 core dump 转储文件。
发现还是结果还是一样~~~没办法了,算了~
gdb 的下 thread 命令可以查看所有线程调用堆栈的信息。
thread apply all bt
这里大家留意一下,pthread
,出现问题终止程序之前,都出现了 pthread
这个关键字。
然后查询了一下资料:https://man7.org/linux/man-pages/man7/pthreads.7.html
查询资料得知,linux 的 pthread 都是 kernel thread(一般情况下):https://www.zhihu.com/question/35128513
先停一下,我们来猜想一下,会不会是多线程导致的问题?我们把相关的记录拿出来看一下:
#1 0x00007fb2ccf29d46 in MQTTAsync_receiveThread () from /lib/lib***BBB.so.1 #2 0x00007fb456ef1fa3 in start_thread (arg=) at pthread_create.c:486
Thread 1 (Thread 0x7fa6a0228740 (LWP 991)): #0 futex_wait_cancelable (private=0, expected=0, futex_word=0x171dae0) at ../sysdeps/unix/sysv/linux/futex-internal.h:88 #1 __pthread_cond_wait_common (abstime=0x0, mutex=0x171da90, cond=0x171dab8) at pthread_cond_wait.c:502 #2 __pthread_cond_wait (cond=0x171dab8, mutex=0x171da90) at pthread_cond_wait.c:655 #3 0x00007fa69fa619d5 in CorUnix::CPalSynchronizationManager::ThreadNativeWait(CorUnix::_ThreadNativeWaitData*, unsigned int, CorUnix::ThreadWakeupReason*, unsigned int*) () from /usr/share/dotnet/shared/Microsoft.NETCore.App/3.1.1/libcoreclr.so #4 0x00007fa69fa615e4 in CorUnix::CPalSynchronizationManager::BlockThread(CorUnix::CPalThread*, unsigned int, bool, bool, CorUnix::ThreadWakeupReason*, unsigned int*) () from /usr/share/dotnet/shared/Microsoft.NETCore.App/3.1.1/libcoreclr.so #5 0x00007fa69fa65bff in CorUnix::InternalWaitForMultipleObjectsEx(CorUnix::CPalThread*, unsigned int, void* const*, int, unsigned int, int, int) ()
会不会是由于 CoreCLR 和 .so 库相关的 pthread 导致的?不过我不是 C 语言的专家,对 Linux 的 C 不了解,这时候需要大量恶补知识才行。
大胆猜一下,会不会是类似 https://stackoverflow.com/questions/19711861/segmentation-fault-when-using-threads-c 这样的错误?
还有这样的:https://stackoverflow.com/questions/8018272/pthread-segmentation-fault
会不会跟机器硬件有关?
为啥会这样?
能不能找到更多的信息?
我不熟悉 C 语言呀?怎么办?
难道使用 GDB 操作比较骚,就可以解决问题了?No。
眼看解决问题无果,进群问了 Jexus 的作者-宇内流云大佬,我将详细的报错信息给大佬看了,大佬给建议试试使用 InPtr。
于是我使用不安全代码,将函数参数
ST_MODULE_CBS* module_cbs, ST_DEVICE_CBS* device_cbs
改成
IntPtr module_cbs, IntPtr device_cbs
剩下就是将结构体转为 IntPtr 的问题了,IntPtr 文档亲参考 https://docs.microsoft.com/zh-cn/dotnet/api/system.intptr?view=netcore-3.1
然后使用结构体转换函数:
private static IntPtr StructToPtr(object obj) { var ptr = Marshal.AllocHGlobal(Marshal.SizeOf(obj)); Marshal.StructureToPtr(obj, ptr, false); return ptr; }
改成不安全代码调用 C 的函数:
unsafe { IntPtr a = StructToPtr(cbs); IntPtr b = StructToPtr(device_cbs); EdgeSDK.edge_set_callbacks(a, b); }
重新放上去测试,终于,正常了!!!
实践证明,要使用 C# 调用 C 语言的代码,或者回调,要多掌握 C# 中的不安全代码和 ref 等写法~~~
事实证明,当出现无法解决的问题时,不如紧紧抱住大佬的大腿比较好~~~
推一波 Jexus:
Jexus 是强劲、坚固、免费、易用的国产 WEB 服务器系统,可替代 Nginx 。Jexus 支持 Arm32/64、X86/X64、MIPS、龙芯等类型的 CPU,是一款Linux平台上的高性能WEB服务器和负载均衡网关服务器,以支持ASP.NET、ASP.NET CORE、PHP为特色,同时具备反向代理、***检测等重要功能。
可以这样说,Jexus是.NET、.NET CORE跨平台的最优秀的宿主服务器,如果我们认为它是Linux平台的IIS,这并不为过,因为,Jexus不但非常快,而且拥有IIS和其它Web服务器所不具备的高度的安全性。同时,Jexus Web Server 是完全由中国人自主开发的的国产软件,真正做到了“安全、可靠、可控”, 具备我国党政机关和重要企事业单位信息化建设所需要的关键品质。