【问题解决】ib_write_bw报错segfault at 1b1 ip 00007f80f540a137 sp 00007ffc26ac1ae0 error 4 in librdm？

北冥的备忘录

于 2025-03-18 02:56:15 发布

阅读量245

点赞数 1

分类专栏： Mellanox专区-OFED&DOCA&RDMA Linux命令文章标签： Mellanox

本文链接：https://blog.csdn.net/essencelite/article/details/146330492

版权

Mellanox专区-OFED&DOCA&RDMA 同时被 3 个专栏收录

199 篇文章

订阅专栏

Linux命令

188 篇文章

订阅专栏

GPU

20 篇文章

订阅专栏

背景

使用支持cuda的ib_write_bw的时候报错

现象

[433534.538836] ib_write_bw[828449]: segfault at 1b1 ip 00007f80f540a137 sp 00007ffc26ac1ae0 error 4 in librdmacm.so.1.3.48.0[7f80f5400000+19000]
[433534.538845] Code: ff 4c 89 f2 4c 89 ee b9 80 00 00 00 48 8d bb 98 00 00 00 e8 fb a6 ff ff 48 8b 45 08 ba 18 01 00 00 48 89 de 66 44 89 74 24 12 <8b> 38 44 89 7c 24 0c e8 5d a3 ff ff 3d 18 01 00 00 75 46 48 8d bd
[779099.041607] traps: ib_write_bw[2724906] general protection ip:7fa0a430624a sp:7fffe0611b80 error:0 in libcuda.so.550.54.15[7fa0a4160000+498000]
[779099.041731] traps: ib_write_bw[2724782] general protection ip:7f429610624a sp:7ffeba9b6070 error:0 in libcuda.so.550.54.15[7f4295f60000+498000]

在这里插入图片描述

原因

执行了使用cuda的内存，但是指定的gpuid不存在

./ib_write_bw  --use_cuda=4&
./ib_write_bw 1.1.1.2  --use_cuda=4

内核部分信息

在这里插入图片描述

分析

可能是由于指定gib_write_bw的时候尝试从cuda去分配内存，没拿到造成异常。下一步确认下GPU的信息，以及id等信息。

确定要放弃本次机会？

福利倒计时

: :

立减 ¥

普通VIP年卡可用

立即使用

北冥的备忘录

关注关注

1
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
分享

复制链接

分享到 QQ

分享到新浪微博

扫一扫
举报

举报

专栏目录

Coredump-N, segfault at 0 ip 0000000000000000 sp；被kernel 抓到

mzhan017的博客

02-10

1746

应用程序 abc，要在A 和 B 两台机器做互为备份的服务运行，AB之间会同步一些数据，如果只替换A上的abc，而B还是运行老的abc程序。可能出现程序里数据结构版本不一致，导致同步数据不能正常工作。abc应用程序memset 函数出现非法地址访问导致的 coredump；被kernel 抓到，在var/log/ kern.log。

error 4 in libc-2.12.so

sinat_42884063的博客

02-09

938

在RHEL/CentOS 64位（32位没用过）6.0以上版本中，有core文件被截断的问题，即使你已经设置了ulimit -S -c unlimited。原因好像是因为core pattern设置是abrt，abrt的问题导致core文件很小或者不产生core文件。解决的方法是不使用abrt作为core pattern segfault at 0 ip 000000387712164f sp 00007fffb37d5b48 error 4 in libc-2.12.so[3877000000+175

参与评论您还未登录，请先登录后发表或查看评论

利用dmesg和addr2line来对（动态库里的）段错误进行调试

木牛的博客

06-16

1137

工作中，我们在varnish的基础上，利用vmod机制，实现了一个可以定制策略，且策略可自动加载而不需重新启动引擎的cache（平时，大家对varnish的利用，cache策略都定义在一个vcl配置文件中，每次对策略进行修改，都需要重新启动varnish，从而使得策略生效，且当部署在varnish后面的站点很多时，不方便对每站点的cache策略进行个性化的定制），这里各种策略的控制以及加载都实现在一个vmod模块里（libvmod_ngcache.so）,很开心，产品上线了。那么问题来，（挖掘机技术那家强？

利用addr2line调试崩溃的bug

WaitForDone的博客

04-26

1995

在linux下，程序莫名奇妙崩溃，而且不是固定的崩溃，这种情况，你肯定很捉急。这里你可以利用addr2line定位到程序崩溃的地点。首先你先到/var/log/syslog，这里log不一定是这个文件，有可能时间久了，压缩了。然后打开它，你会发现general protection ip:43917e sp:7fa0ca7a3cd0 error:0 in 。 ip 指是编码器的编译后命令addre

使用 InfiniBand 写入带宽对 NVIDIA GPUDirect RDMA 进行基准测试

smartvxworks的博客

10-22

1414

性能基准测试是 HPC 的标志。最现代的超级计算机是具有异构架构的计算节点集群。在这样的节点中，我们可以看到经典 CPU 和专用计算协处理器 (GPU)。本教程介绍了使用基于 InfiniBand 写入带宽 () 构建的定制脚本对 NVIDIA GPUDirect 远程直接内存访问 (GPUDirect RDMA) 进行基准测试的方法。使用。

pptpd pptpctrl[25553]: segfault at 0 ip 00007fb6fe23ebdc sp 00007ffdef6334e8 error 4 in libc-2.17.so...

weixin_30485291的博客

06-05

806

以下是一次记录pptpd vpn无法连接后的心酸历程: pptp client拨号发现一直无响应，查看日志因为pptpd服务端是一台高质量公网地址，所以平时拨入vpn连接都非常快，今天发起拨号请求后却迟迟无相应，所以迅速登录服务端进行排查，发现有以下大量日志： Jun 5 21:29:38 Linux kernel: pptpctrl[25540]: segfault at ...

没有core文件时定位segfault at 0 ip 的问题（一）

哦，原来你也在这里。

07-28

4838

C/C++编写的程序，崩溃后有时不能生成core文件（即使设置了ulimited)，所以往往不知道发生了什么事情，生产环境根本不允许研发小朋友去调试，日志有时候看不出问题了。（如果生成了core文件，或通过日志能定位到问题所以，则可略过此文章）。本文章专门针对于没有生成core文件、不能通过日志分析问题的情况首先，写一段测试代码吧，不用怀疑，这段代码肯定是有问题的 #include <iostream> #include <cstdio> #include <mem

Python出现segfault错误解决方法

09-21

kernel:[1207747.915932]python[29797]:segfaultat7f3fc280e036ip00007f3fc0a35722sp00007fff52b6bcd0error4in cjson.so[7f3fc0a32000+5000] ``` - **替换库测试**：鉴于`cjson`非Python标准库，且疑似引发错误...

error 4 in libc-2.12.so解决办法

zhangge3663的博客

05-17

9547

最近发现在64位centos系统下，core文件的产生有些问题，dmesg发现有以下日志: xxxxx[3505] general protection ip:387780c160 sp:7fe54bb7b9e8 error:0 in libpthread-2.12.so[3877800000+17000] abrt-hook-ccpp[4661]: segfault at 0 ip 0000...

ubuntu20.04 (Linux 5.4.0-81-generic )安装驱动调试Infiniband controller: Mellanox [ConnectX-5]

weixin_38646896的博客

06-07

5197

RMDA

如何在没有core文件的情况下用dmesg+addr2line定位段错误

gezi322的专栏

11-12

1185

前言在现网环境下，程序奔溃后不一定会留下core文件，原因有很多，比如存储空间不足就是其中一个常见的原因。此时我们只能依据linux记录的错误日志来定位问题。涉及linux命令本文涉及以下几条命令 1. dmesg命令，用于获取程序出错时的堆栈地址 1）dmesg |grep -E 'segfault|general' 可以通过该命令过滤出发生崩溃的程序，以及对应的堆栈信息。之前看网上的其他文章仅过滤segfault，但我在实践中发现"general protection"的提示信息也在告诉

Imbue-70B 的 AI Infra：从0到1搭建和运维4088 H100集群的最佳实践

强化学习曾小健

08-09

1038

其他没有有用错误信息的响应实例通常可能与硬件相关，为了区分 NCCL 挂起，驱动进程挂起或 Python 代码中的死锁等问题，作者使用 Py-Spy 和 GDB 等工具来实时调试 Hang 住的进程，使用此方法能够捕获一些特定的问题。对于给定的训练任务，提供比运行所需 Node 多 10%-20% 的 Node 很有帮助（PS：阿里最新的 HPN 中，甚至牺牲无收敛性，为每 128 个 Node 提供了 8 个物理冗余备份），这样就可以在有 Node 故障时轻松重启作业。

dmesg 段错误

wangtingting_100的博客

11-05

4354

放了一个定时任务，定时执行dmesg -c $ cd /etc/cron.d $ cat dmesg_clean */1 * * * * root dmesg -c &> /dev/null $ sudo ls /var/log/messages* -alk -rw------- 1 root root 566 Aug 21 11:37 /var/log/message...

php进程异常退出,记一次进程异常退出的问题排查

weixin_29107289的博客

03-23

2537

机器搬家之后，之前一直稳定的PHP多进程程序子进程突然异常退出，但是退出的不是很频繁，查看进程日志并也没有发现有什么导致退出的，问题比较诡异。于是开启了一段问题排查之路。首先查看内核日志，使用dmesg，拉到最后发现有一些这样的错误，看来确实是崩溃了。[4791991.998535] php[16776]: segfault at 7f6443ee18c8 ip 00007f6443ee18c8 ...

微知-ib_write_bw的各种参数汇总（-d -q -s -R --run_infinitely）

最新发布

技术札记

11-19

2763

经常忘记使用ib_write_bw打流的一些参数，特此整理记录在这里方便快速查阅。尤其是run_infinitely这个参数容易写错。

segfault at 0

08-25

引用中的链接提到的错误信息"segfault at 0 ip (null) sp 00007f329e870418 error 14 in main[400000 23c000]"是指发生了一个段错误(segmentation fault)。段错误通常是由于程序访问了不存在的内存地址或者非法的内存访问引起的。具体来说，"segfault at 0"表示在地址0处发生了段错误。这个错误信息中提到的ip和sp分别表示指令指针和栈指针的值。而"error 14"则是表示发生了一个无效的页错误。根据这个错误信息，我们可以推断出在程序的main函数中发生了段错误。不过，需要注意的是，这个错误信息中的指令指针(ip)为(null)，这可能意味着没有正确的调试符号(debug symbol)来解析函数名。所以，我们需要进一步分析系统日志或者其他相关信息来确定具体的原因和解决方法。123 #### 引用[.reference_title] - *1* [Python出现segfault错误解决方法](https://download.csdn.net/download/weixin_38616330/12875269)[target="_blank" data-report-click={"spm":"1018.2226.3001.9630","extra":{"utm_source":"vip_chatgpt_common_search_pc_result","utm_medium":"distribute.pc_search_result.none-task-cask-2~all~insert_cask~default-1-null.142^v93^chatsearchT3_2"}}] [.reference_item style="max-width: 33.333333333333336%"] - *2* [没有core文件时定位segfault at 0 ip (null) 的问题(三）：艰难定位，多种原因](https://blog.csdn.net/lianshaohua/article/details/107933181)[target="_blank" data-report-click={"spm":"1018.2226.3001.9630","extra":{"utm_source":"vip_chatgpt_common_search_pc_result","utm_medium":"distribute.pc_search_result.none-task-cask-2~all~insert_cask~default-1-null.142^v93^chatsearchT3_2"}}] [.reference_item style="max-width: 33.333333333333336%"] - *3* [Coredump-N, segfault at 0 ip 0000000000000000 sp；被kernel 抓到](https://blog.csdn.net/qq_36428903/article/details/122855636)[target="_blank" data-report-click={"spm":"1018.2226.3001.9630","extra":{"utm_source":"vip_chatgpt_common_search_pc_result","utm_medium":"distribute.pc_search_result.none-task-cask-2~all~insert_cask~default-1-null.142^v93^chatsearchT3_2"}}] [.reference_item style="max-width: 33.333333333333336%"] [ .reference_list ]