|
From: Adam S. <ase...@gm...> - 2011-03-30 00:09:15
|
Hi, I'm trying to debug an app on Ubuntu 10.10 x86_64. When I open it in exp-ptrcheck, I get the following error: sysno == 290 exp-ptrcheck: the 'impossible' happened: unhandled syscall ==8235== at 0x3801303F: report_and_quit (m_libcassert.c:191) ==8235== by 0x38013138: panic (m_libcassert.c:275) ==8235== by 0x38013157: vgPlain_tool_panic (m_libcassert.c:290) ==8235== by 0x38002B83: h_post_syscall (h_main.c:2588) ==8235== by 0x380509C9: vgPlain_post_syscall (syswrap-main.c:1728) ==8235== by 0x38051A4D: vgPlain_client_syscall (syswrap-main.c:1626) ==8235== by 0x3804DED2: handle_syscall (scheduler.c:885) ==8235== by 0x3804F66A: vgPlain_scheduler (scheduler.c:1081) ==8235== by 0x380791A0: run_a_thread_NORETURN (syswrap-linux.c:94) As far as I can tell from Web searches, this means that support simply doesn't exist for this particular syscall? Is there anything I can do about it, or do I just have to work around it? Thanks, Adam |
|
From: John R. <jr...@bi...> - 2011-03-30 00:31:39
|
> I'm trying to debug an app on Ubuntu 10.10 x86_64. When I open it in exp-ptrcheck, I get the following error: > > sysno == 290 > exp-ptrcheck: the 'impossible' happened: > unhandled syscall -----/usr/include/asm/unistd_64.h #define __NR_eventfd2 290 ----- http://lwn.net/Articles/234123/ Kernel prepatch 2.6.22-rc1 May 13, 2007 -- |
|
From: John R. <jr...@bi...> - 2011-03-30 03:12:21
|
> Thanks for the reply. ... I'm not sure what 2.6.22-rc1 has to do with this syscall? Or what, if anything, I can do? The eventfd2 syscall was added to the Linux kernel in mid 2007, for Linux 2.6.22, but exp-ptrcheck has no handler for it today. Section 11.6, Limitations, of the valgrind manual http://valgrind.org/docs/manual/valgrind_manual.pdf: Heap checks: Ptrcheck needs to "understand" which system calls return pointers and which don’t. Many, but not all system calls are handled. If an unhandled one is encountered, Ptrcheck will abort. Fortunately, adding support for a new syscall is very easy. So knock on the door of a valgrind developer, and ask nicely. The best way to do so is to file a polite, complete, bug report. Or, get the source code and do it yourself. In the meantime, one possible work-around is to change the usage of the app so that eventfd2() is not used. -- |
|
From: Adam S. <ase...@gm...> - 2011-03-30 03:41:52
|
On Mar 29, 2011, at 11:11 PM, John Reiser wrote: >> Thanks for the reply. ... I'm not sure what 2.6.22-rc1 has to do with this syscall? Or what, if anything, I can do? > > The eventfd2 syscall was added to the Linux kernel in mid 2007, for Linux 26.22, > but exp-ptrcheck has no handler for it today. Section 11.6, Limitations, of the > valgrind manual http://valgrind.org/docs/manual/valgrind_manual.pdf: > > Heap checks: Ptrcheck needs to "understand" which system calls return pointers > and which don’t. Many, but not all system calls are handled. If an unhandled one > is encountered, Ptrcheck will abort. Fortunately, adding support for a new syscall > is very easy. > > So knock on the door of a valgrind developer, and ask nicely. The best way to do so > is to file a polite, complete, bug report. Or, get the source code and do it yourself. > In the meantime, one possible work-around is to change the usage of the app so that > eventfd2() is not used. Ah, thanks! That makes sense. I'll take a look. If it's easy enough that I can figure it out, I'll make the change myself; otherwise I'll file an appropriate bug report. Adam |
|
From: Julian S. <js...@ac...> - 2011-03-30 08:26:03
|
On Wednesday, March 30, 2011, Adam Seering wrote: > I'll take a look. If it's easy enough that I can figure it out, I'll make > the change myself; otherwise I'll file an appropriate bug report. It's trivial -- look at the code. The only distinction you need to make is whether or not the returned value is a pointer, and it almost always isn't. J |
|
From: Adam S. <ase...@gm...> - 2011-03-30 14:12:53
|
On Mar 30, 2011, at 4:20 AM, Julian Seward wrote: > On Wednesday, March 30, 2011, Adam Seering wrote: >> I'll take a look. If it's easy enough that I can figure it out, I'll make >> the change myself; otherwise I'll file an appropriate bug report. > > It's trivial -- look at the code. The only distinction you need > to make is whether or not the returned value is a pointer, and it > almost always isn't. Well, it did look trivial. It's not clear that it worked, though... I'm now getting a different error. Not sure if it's related, or if it should start a new thread?: get_IntRegInfo(amd64):failing on (176,8) exp-ptrcheck: h_main.c:1490 (get_IntRegInfo): the 'impossible' happened. ==25863== at 0x38013467: report_and_quit (m_libcassert.c:209) ==25863== by 0x380136A0: vgPlain_assert_fail (m_libcassert.c:283) ==25863== by 0x38002274: get_IntRegInfo (h_main.c:1490) ==25863== by 0x380022F1: is_integer_guest_reg (h_main.c:1956) ==25863== by 0x38008A33: h_instrument (h_main.c:5231) ==25863== by 0x380A0736: LibVEX_Translate (main_main.c:559) ==25863== by 0x3802A71C: vgPlain_translate (m_translate.c:1504) ==25863== by 0x38050158: vgPlain_scheduler (scheduler.c:871) ==25863== by 0x38079AC4: run_a_thread_NORETURN (syswrap-linux.c:94) Any thoughts? Reading the code, it looks maybe like an unknown register? Thanks, Adam |