CFC4N

OK，看到密码了。 `last2`文件里内容，宕机的点应该是`SDHMS:a1.e: 7735`进程，大概是该手机ROM自定义的进程，不清楚他如何实现，不能判断是否跟ebpf有关。 ```shell [ 438.287296] [2: SDHMS:a1.e: 7735] kernel BUG at drivers/soc/qcom/rpmh-rsc.c:898! [ 438.287312] [2: SDHMS:a1.e: 7735] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP [ 438.287433] [2:...

Missing equipment, cannot reproduce.

你在目标机器上自己编译一次，会有问题吗？

OK， 就像#581 里提到的，我需要一个准确的重现办法，你知道这个问题的关键因素吗？

近期我抽空测试一下。 总是卡在vm安装arch系统这里，很繁琐。

> > 我的建议是这个问题不太好解决，因为需要要求客户锁依赖。最好的方式是通过容器运行，保证二进制的一致性 > > 但是只有从 0.8.1 开始才会出问题，会是哪个 commit 引入的问题呢？ 我还没有重现，我的猜测应该是启用CGO引入libpcap类库后，编译环境的C类库跟运行的环境有差异。 编译构建的环境，期望是可以兼容更多内核的。 如果问题是这里的话，那确实不太好解决。

确实，这个结论比较合理，能很好地解释了报错堆栈里的`_cgo_97ab22c4dc7b_C2func_getaddrinfo `等信息。 感谢您的定位。 至于修复方式，我觉得是可以启用`-tags netgo`参数的。 另外，我也看到go的官方issue里提到过，使用 `// go:debug netdns`等方式 ，都可以尝试。 也包括你提到的不支持域名 address的绑定 ，这个决策也可行，本身就应该是来自本机的对应网卡。 另外，报错信息中还有一个关键信息`warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.` ，这里只是warning的提醒，没有影响运行，问题原因是[Fedora上发行的libc缺少`libthread_db `符号的调试信息](https://bugzilla.redhat.com/show_bug.cgi?id=1960867)。...

还有，在编译时，能够看到`libpcap`类库也引用了`getaddrinfo`，理论来说，也会出现异常崩溃。只是当前并没有触发libpcap内涉及DNS解析的逻辑。 如果想完全避免这类问题，要么就是跟对不同libc版本进行构建，要么就是弃用libpcap的`bpf filter`特性。 我需要仔细斟酌一下。 ```shell /usr/bin/ld: /ecapture/lib/libpcap//libpcap.a(nametoaddr.o): in function `pcap_nametoaddrinfo': /ecapture/lib/libpcap/./nametoaddr.c:207: warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for...

底层类库变更，稳定性风险更大，暂时不考虑。

Firstly, an SSL handshake involves only one key exchange. Secondly, the program filters out identical `CLIENT_RANDOM` results (multiple HOOK points triggered in a single process). https://github.com/gojue/ecapture/blob/d50ee780c0c26df50bdcd262e792b02cef55b1f4/user/module/probe_openssl.go#L388-L393