|
From: Oleg K. <ele...@gm...> - 2011-06-09 14:06:22
|
Hello. I'm trying to debug my very big appliction using valgrind. Thank you for this great instrument! But i can't understand one valgrind message: Application startup: ==1019== Warning: noted but unhandled ioctl 0xae03 with no size/direction hints ==1019== This could cause spurious value errors to appear. ==1019== See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper. Application shutting down: ==1019== Warning: noted but unhandled ioctl 0xae06 with no size/direction hints ==1019== This could cause spurious value errors to appear. ==1019== See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper. I read valgrind documents about MISSING_SYSCALL_OR_IOCTL, but still don't understand. Which and where syscall is unhandled, how to explain this message? Thanks. Best regards, Oleg. |
|
From: John R. <jr...@bi...> - 2011-06-09 15:03:28
|
> ==1019== Warning: noted but unhandled ioctl 0xae03 with no size/direction hints > ==1019== This could cause spurious value errors to appear. > ==1019== See README_MISSING_SYSCALL_OR_IOCTL for guidance on > writing a proper wrapper. The syscall is: ioctl(fd, 0xae03, ...) where 'fd' is some file descriptor, and the ellipsis '...' means that there may be more arguments. In most cases, there are three arguments, and the last one is the address of some 'struct' that is specific to the "operation code" 0xae03. Notice that 0==(0xffff0000 & 0xae03) , which means that the operation code 0xae03 has no direction hints (the 0xc0000000 bits) and also omits the size hint (the 0x3fff0000 bits.) There are literally thousands of ioctl opcodes (the 0x0000ffff bits), and knowing the size and direction of data transfer is a big pain. Therefore in most cases the size and direction are part of the high 16 bits of the opcode; but not in this case. You can try searching /usr/include/.../*.h files for "ae03", but this is likely to fail because the source for the opcode probably is something like "(FOO|3)" with a "#define FOO 0xae00". One good way to learn more is to run the app under 'strace'. Strace decodes and prints syscalls as they occur. Strace knows many ioctl already, but perhaps not 0xae03. However, the output from strace will enable you to find the 'fd' and probably its filename. Find the syscall with 0xae03 as the second argument, then search backward for the 'open' whose return value equals the first argument to the ioctl. -- |
|
From: John R. <jr...@bi...> - 2011-06-10 13:44:36
|
On 06/10/2011 05:38 AM, Igmar Palsenberg wrote: > > On Jun 9, 2011, at 5:04 PM, John Reiser wrote: > >>> ==1019== Warning: noted but unhandled ioctl 0xae03 with no size/direction hints >>> ==1019== This could cause spurious value errors to appear. >>> ==1019== See README_MISSING_SYSCALL_OR_IOCTL for guidance on >>> writing a proper wrapper. >> The syscall is: >> ioctl(fd, 0xae03, ...) Igmar Palsenberg <mai...@pa...> writes: > I would bet my money on KVM_CHECK_EXTENSION. The KVM ioctl() from what I can remember is two dozens of ioctl()'s, so if no one else volenteers, I'm willing to supply a patch for this. That is, if Oleg can somehow confirm that this really is KVM. linux/include/linux/kvm.h has ----- #define KVMIO 0xAE #define KVM_CHECK_EXTENSION _IO(KVMIO, 0x03) ----- and in this particular case there are only two arguments used by the ioctl, so the valgrind Warning is just a warning: the ioctl does not access user address space. -- |