首先,如果我在错误的地方写了这个,请允许我道歉.
我似乎找不到在valgrind用户论坛中发布这种性质的东西,并且由于这个地方似乎相当笼罩,因此我想尝试一下.
运行我的代码时,我需要使用一个有点非传统的linux内核.
我对内核了解不多,具体原因是我没有写过.
无论出于何种原因,我的内核看起来都像扩展了默认linux内核的syscall表.
发生的情况是,在.ko文件为insmod时,当前的标准syscall表得到了扩展,从似乎是333开始,到341,保存了原始的syscall表,并在.ko时恢复了该表. rmmoded.
这些额外的系统调用似乎可以执行某种独特的IPC通信
我正在运行的专有软件.
当然,这似乎在与valgrind玩地狱.
我想使用valgrind来对我的程序进行内存检查,但是valgrind总是崩溃
我的应用程序立即执行系统调用.
这是我从valgrind获得的输出,减去了我宁愿做的几件事
==26045== Thread 2:
==26045== Syscall param preadv(vector) points to unaddressable byte(s)
==26045== at 0x4000982: ??? (in /lib/ld-2.9.so)
==26045== by 0x426C756: syscall (in /lib/libc-2.9.so)
==26045== by 0x4037430: com_lock (coms.c:114)
--23932-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting
--23932-- si_code=1; Faulting address: 0x165; sp: 0x63a6dde4
valgrind: the 'impossible' happened:
Killed by fatal signal
==23932== at 0x3809D5E0: vgSysWrap_linux_sys_preadv_before (syswrap-linux.c:3413)
==23932== by 0x380785CB: vgPlain_client_syscall (syswrap-main.c:1382)
==23932== by 0x38076330: vgPlain_scheduler (scheduler.c:929)
==23932== by 0x380A13E8: run_a_thread_NORETURN (syswrap-linux.c:98)
==23932== by 0x380A1732: vgModuleLocal_start_thread_NORETURN (syswrap-linux.c:268)
==23932== by 0x380A8AC8: ??? (in /usr/local/lib/valgrind/memcheck-x86-linux)
不幸的是,我不可能不使用这些额外的系统调用.
我面临的挑战是如何应对它们.
到目前为止,我了解到的是,我可以在valgrind中指定新的或自定义的syscall包装器.不幸的是,当我在运行时将系统调用地址全部转换后,我不太了解如何实现这一目标.
如果有人对为自己添加到内核中的非标准系统调用编写valgrind syscall包装器有任何经验(并且知道如何告诉valgrind切换包装器),请以一些详细信息,引用或其他方式回覆.我真的很感激.
我正在使用valgrind 3.7,g 4.1.1和基于2.6.29 gentoo构建的自定义内核
(出于所有意图和目的,在加载我专有的内核模块之前为2.6.29 gentoo)
编辑:
自从我第一次发布以来,我发现了与此有关的其他几件事.
似乎valgrind有一个名为include / vki / vki-scnums-x86-linux.h的文件.
根据其中的注释(这里记住了valgrind 3.7.0),它或多或少是从2.6.9内核中复制和粘贴的asm-i386 / unistd.h.
在指令枚举333中,定义了__NR_preadv.
对我来说,valgrind在对名为my_ipc的东西执行系统调用时就死了,这是我的内核独有的系统调用,枚举为333.
似乎在针对valgrind进行编译的内容与内核中实际发生的内容之间存在系统调用映射错误.这样,当系统调用包装程序valgrind看到系统调用333无法真正处理系统调用333时,它会尝试进行调用,因为函数调用签名可能不匹配.
我认为preadv看起来像…
preadv(int fd, const struct iovec *iov, int iovcnt, off_t offset);
据我所知,我的ipc通话看起来像
asmlinkage long my_ipc (uint, long, long, long, long, long);
解决方法:
基本上,解决此问题的唯一方法是修改valgrind以删除对与自定义系统冲突的系统调用的支持,并至少添加对自定义系统调用的最小支持.就目前情况而言,valgrind试图将自定义系统调用的参数解释为使用相同插槽的标准系统调用.
valgrind源代码树的根目录中的README_MISSING_SYSCALL_OR_IOCTL文件是开始如何为valgrind添加系统调用包装程序的指南的最佳位置.
要回答有关valgrind论坛的问题,请在freenode上找到mailing lists或#valgrind IRC频道.