GDB 调试 .NET 程序实录 - .NET 调用 .so 出现问题怎么解决

内容纲要

注:本文重要信息使用 *** 屏蔽关键字。

最近国庆前,项目碰到一个很麻烦的问题,这个问题让我们加班到凌晨三点。

大概背景:

客户给了一些 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

《GDB 调试 .NET 程序实录 - .NET 调用 .so 出现问题怎么解决》

# 系统日志
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 查找资料,经过一段时间后,学会了使用这些工具查询异常堆栈信息。

GDB

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

另外 strace 这个工具也是很有用的,能够看到堆栈信息,使用 apt install strace 即可安装上。

binutils

objcopy、strip 这两个工具可以将 .so 库的符号信息整理处理。

objcopy 、strip安装:

apt install binutils

binutils 包含了 objcopy 和 strip。

调试、转储 core 文件

在使用 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}-{时间} 格式的文件。

《GDB 调试 .NET 程序实录 - .NET 调用 .so 出现问题怎么解决》

使用命令进入 core dump 文件。

gdb -c corefile-dotnet-376-1602236839

执行 bt 命令。

《GDB 调试 .NET 程序实录 - .NET 调用 .so 出现问题怎么解决》

发现有信息,但是可用信息太少了,而且名称都是 ??,这样完全定位不到问题的位置。怎么办?

可以将 .so 文件一起包进来检查。

gdb -c  corefile-dotnet-376-1602236839 /***/lib***.so

也可以使用多个 .so 一起加入

gdb -c  corefile-dotnet-376-1602236839 /***/libAAA.so /***/libBBB.so

strace 的使用

Linux中的 strace 命令可以跟踪系统调用和信号。

如果系统没有这个命令,可以使用 apt install strace 或者 yum install strace 直接安装。

然后使用 strace 命令启动 .NET 程序。

strace dotnet /***/***.dll

启动后就可以看到程序的堆栈信息,还可以看到函数调用时的函数定义。

GDB 调试启动 .NET 程序

执行以下命令即可启动 .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 命令查看异常的堆栈信息。

生成结果如下:

《GDB 调试 .NET 程序实录 - .NET 调用 .so 出现问题怎么解决》

.so 文件剥调试信息

在 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

检查 .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 /opt/ganwei/IoTCenter/bin/GWHost1.dll

或者

gdb dotnet
...
# 进入GDB 后
set args /opt/ganwei/IoTCenter/bin/GWHost1.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=<optimized out>) 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=<optimized out>) at pthread_create.c:486
        ret = <optimized out>
        pd = <optimized out>
        now = <optimized out>
        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 = <optimized out>
#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

《GDB 调试 .NET 程序实录 - .NET 调用 .so 出现问题怎么解决》

这里大家留意一下,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=<optimized out>) 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

《GDB 调试 .NET 程序实录 - .NET 调用 .so 出现问题怎么解决》

会不会跟机器硬件有关?

为啥会这样?

能不能找到更多的信息?

我不熟悉 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 是完全由中国人自主开发的的国产软件,真正做到了“安全、可靠、可控”, 具备我国党政机关和重要企事业单位信息化建设所需要的关键品质。

点赞

发表评论

电子邮件地址不会被公开。 必填项已用*标注