|
From: Amadeus W. M. <ama...@ca...> - 2006-08-06 23:45:08
|
I'm trying to debug a gtkmm program I'm writing, using valgrind. Each time I get the following --17079-- WARNING: unhandled syscall: 311 --17079-- You may be able to write your own handler. --17079-- Read the file README_MISSING_SYSCALL_OR_IOCTL. I followed closely the instructions in README_MISSING_SYSCALL_OR_IOCTL. but the system calls in /usr/include/asm/unistd.h end at 309. There's no system call 311. What next? And how come? I do believe I need to correct the warning, by writing a wrapper, because there are a bunch of other errors that I think are triggered by the missing wrapper. Thanks! |
|
From: Nicholas N. <nj...@cs...> - 2006-08-07 00:05:08
|
On Sun, 6 Aug 2006, Amadeus W. M. wrote: > I'm trying to debug a gtkmm program I'm writing, using valgrind. > Each time I get the following > > --17079-- WARNING: unhandled syscall: 311 > --17079-- You may be able to write your own handler. > --17079-- Read the file README_MISSING_SYSCALL_OR_IOCTL. > > I followed closely the instructions in README_MISSING_SYSCALL_OR_IOCTL. > but the system calls in /usr/include/asm/unistd.h end at 309. > There's no system call 311. > > What next? And how come? New syscalls get added to Linux every so often. Look in Valgrind's source code at coregrind/vki_unistd-x86-linux.h (or similar file if you're on a different platform). If you are on x86/Linux, 311 is "set_robust_list"... your next job is to work out what it does :) Nick |
|
From: Tom H. <to...@co...> - 2006-08-07 07:27:07
|
In message <Pin...@mu...>
Nicholas Nethercote <nj...@cs...> wrote:
> On Sun, 6 Aug 2006, Amadeus W. M. wrote:
>
>> I'm trying to debug a gtkmm program I'm writing, using valgrind.
>> Each time I get the following
>>
>> --17079-- WARNING: unhandled syscall: 311
>> --17079-- You may be able to write your own handler.
>> --17079-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
>>
>> I followed closely the instructions in README_MISSING_SYSCALL_OR_IOCTL.
>> but the system calls in /usr/include/asm/unistd.h end at 309.
>> There's no system call 311.
>>
>> What next? And how come?
>
> New syscalls get added to Linux every so often. Look in Valgrind's source
> code at coregrind/vki_unistd-x86-linux.h (or similar file if you're on a
> different platform). If you are on x86/Linux, 311 is "set_robust_list"...
> your next job is to work out what it does :)
I implemented that system call for x86 and amd64 and it should be
supported in the 3.2.0 release.
If Amadeus is still seeing this problem in 3.2.0 then he should
open a ticket for it in the bug tracker.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Amadeus W. M. <ama...@ca...> - 2006-08-07 00:20:58
|
On Mon, 07 Aug 2006 10:04:53 +1000, Nicholas Nethercote wrote: > On Sun, 6 Aug 2006, Amadeus W. M. wrote: > >> I'm trying to debug a gtkmm program I'm writing, using valgrind. >> Each time I get the following >> >> --17079-- WARNING: unhandled syscall: 311 >> --17079-- You may be able to write your own handler. >> --17079-- Read the file README_MISSING_SYSCALL_OR_IOCTL. >> >> I followed closely the instructions in README_MISSING_SYSCALL_OR_IOCTL. >> but the system calls in /usr/include/asm/unistd.h end at 309. >> There's no system call 311. >> >> What next? And how come? > > New syscalls get added to Linux every so often. Look in Valgrind's source > code at coregrind/vki_unistd-x86-linux.h (or similar file if you're on a > different platform). If you are on x86/Linux, 311 is "set_robust_list"... > your next job is to work out what it does :) > > Nick Thanks for the quick reply. Sorry, I forgot to mention in my first post, I'm running Fedora Core 5 with kernel-smp-2.6.17-1.2157_FC5. I downloaded the valgrind source, and I did see set_robust_list in vki_unista-x86-linux.h. First of all, why does valgrind have a different list of syscalls than the system itself? Second, exactly how do I know what that system call is supposed to do? I ain't psychic. |
|
From: Nicholas N. <nj...@cs...> - 2006-08-07 00:59:31
|
On Sun, 6 Aug 2006, Amadeus W. M. wrote: > Thanks for the quick reply. Sorry, I forgot to mention in my first > post, I'm running Fedora Core 5 with kernel-smp-2.6.17-1.2157_FC5. > > I downloaded the valgrind source, and I did see set_robust_list in > vki_unista-x86-linux.h. First of all, why does valgrind have a different > list of syscalls than the system itself? Because Valgrind's list is up-to-date with more recent versions of the kernel than the one you have. > Second, exactly how do I know what that system call is supposed to do? I > ain't psychic. Google or the Linux source code. Nick |
|
From: Amadeus W. M. <ama...@ca...> - 2006-08-07 02:35:26
|
On Mon, 07 Aug 2006 10:59:17 +1000, Nicholas Nethercote wrote:
> On Sun, 6 Aug 2006, Amadeus W. M. wrote:
>
>> Thanks for the quick reply. Sorry, I forgot to mention in my first
>> post, I'm running Fedora Core 5 with kernel-smp-2.6.17-1.2157_FC5.
>>
>> I downloaded the valgrind source, and I did see set_robust_list in
>> vki_unista-x86-linux.h. First of all, why does valgrind have a different
>> list of syscalls than the system itself?
>
> Because Valgrind's list is up-to-date with more recent versions of the
> kernel than the one you have.
>
>> Second, exactly how do I know what that system call is supposed to do? I
>> ain't psychic.
>
> Google or the Linux source code.
>
> Nick
Found something in linux-2.6.17.7/kernel/futex.c:
asmlinkage long
sys_set_robust_list(struct robust_list_head __user *head,
size_t len)
{
/*
* The kernel knows only one size for now:
*/
if (unlikely(len != sizeof(*head)))
return -EINVAL;
current->robust_list = head;
return 0;
}
No idea how to write a valgrind wrapper though, so maybe I'll
just stop short of hacking the kernel and valgrind, and wait
till the kernel >= 2.6.17-7 is available in FC5.
Thanks for the help.
|
|
From: Peter \Firefly\ L. <fi...@di...> - 2006-08-07 03:41:19
|
On Sun, 6 Aug 2006, Amadeus W. M. wrote: > No idea how to write a valgrind wrapper though, so maybe I'll > just stop short of hacking the kernel and valgrind, and wait > till the kernel >= 2.6.17-7 is available in FC5. Here's the background: http://lwn.net/Articles/172149/ http://lwn.net/Articles/172134/ I think you misunderstand the situation: you are not waiting for the kernel to catch up, you are waiting for valgrind to catch up. This is a system call glibc issues even on kernels that don't support it because that's easier than first checking whether it is actually supported. If it isn't, it is quite harmless. glibc very often uses this technique (you can see for yourself by stracing just about any program). In some cases a new system call is tried first and if that fails, an older and less capable system call is tried next. This is often faster and easier than checking kernel version numbers. It also handles backported system call implementations. The thing is, valgrind needs to understand what the program tries to tell the kernel because, who knows, it could be important. You can probably either use an older glibc or if you are lucky tell it to assume it has an older kernel from before this call was introduced (by setting the ASSUME_KERNEL environment variable). Or you can write a very simple syscall wrapper for valgrind that just returns -ENOSYS. There are probably others of that kind already. Good luck :) -Peter |
|
From: Amadeus W. M. <ama...@ca...> - 2006-08-07 04:57:29
|
On Mon, 07 Aug 2006 05:41:04 +0200, Peter "Firefly" Lund wrote: > On Sun, 6 Aug 2006, Amadeus W. M. wrote: > >> [quoted text muted] > > Here's the background: > > http://lwn.net/Articles/172149/ > http://lwn.net/Articles/172134/ > > I think you misunderstand the situation: you are not waiting for the > kernel to catch up, you are waiting for valgrind to catch up. This is a > system call glibc issues even on kernels that don't support it because > that's easier than first checking whether it is actually supported. If it > isn't, it is quite harmless. glibc very often uses this technique (you > can see for yourself by stracing just about any program). In some cases > a new system call is tried first and if that fails, an older and less > capable system call is tried next. This is often faster and easier than > checking kernel version numbers. It also handles backported system call > implementations. > I don't know what I was thinking. As long as valgrind does not have a wrapper for that syscall, it would still issue that warning, even on a kernel that does have that system call. > The thing is, valgrind needs to understand what the program tries to tell > the kernel because, who knows, it could be important. > > You can probably either use an older glibc or if you are lucky tell it to > assume it has an older kernel from before this call was introduced (by > setting the ASSUME_KERNEL environment variable). Or you can write a very > simple syscall wrapper for valgrind that just returns -ENOSYS. There are > probably others of that kind already. > > Good luck :) > Like so, you mean? PRE(sys_set_robust_list) { PRINT("sys_set_robust_list ( %p, %d )", ARG1,ARG2); PRE_REG_READ2(long, "set_robust_list", struct vki_robust_list_head *, head, vki_size_t, len); /* Just check the robust_list_head structure is readable - don't try and chase the list as the kernel will only read it when the thread exits so the current contents is irrelevant. */ if (ARG1 != 0) PRE_MEM_READ("set_robust_list(head)", ARG1, ARG2); } He, he! It's already done in valgrind-3.2.0. Compiled and installed, and now I got rid of the warning. The bad news is I'm still getting the errors that I thought were being triggered by the missing wrapper. The most trivial program in gtkmm produces 2 errors: #include <gtkmm.h> // Compilation: // // g++ -g -Wall -o main `pkg-config gtkmm-2.4 --cflags --libs` main.C int main(int argc, char * argv[]) { Gtk::Main m(argc, argv); return 0; } If valgrind is correct, then the two errors reported must be in gtk/gtkmm or in the X server. |