valgrind backtrace: ==23951== Syscall param ioctl(generic) points to uninitialised byte(s) ==23951== at 0x43F7FB7: syscall (syscall.S:30) ==23951== by 0x404D784: v4l2_fd_open (in /usr/lib/i386-linux-gnu/libv4l2.so.0) ==23951== by 0x8049DE8: main (main.c:8) ==23951== Address 0xbe870b58 is on thread 1's stack gdb backtrace: #0 0x04001172 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x043e1fb7 in syscall () at ../sysdeps/unix/sysv/linux/i386/syscall.S:29 #2 0x0404d785 in v4l2_fd_open () from /usr/lib/i386-linux-gnu/libv4l2.so.0 #3 0x0404dc7e in v4l2_open () from /usr/lib/i386-linux-gnu/libv4l2.so.0 #4 0x0804b09a in v4l_capture () at v4l_capture.c:67 #5 0x08049de9 in main () at main.c:8 Relevant C code: int fd = -1; const char *dev_name = "/dev/video0"; fd = v4l2_open(dev_name, O_RDWR | O_NONBLOCK, 0); Reproducible: Always I think this was reported downstream here: https://bugs.launchpad.net/ubuntu/+source/libv4l/+bug/432477 The suggestion was to report upstream, which is what I'm doing since I get the same error and I don't see it reported in Valgrind.
Created attachment 84737 [details] reduced testcase
It's impossible to say if it's a false positive without examining the source of v4l2_open to see what it is doing. It may be that valgrind needs better support for whatever ioctl it is doing - currently the "generic" handler is being used rather than a custom handler for that ioctl. if you're not able to examine the v4l2 source yourself then I suggest you refer this to the v4l2 developers who will be able to determine if it's a bug in their code or a problem with valgrind, and if the latter will be able to provide more information.
João, please feel free to reopen if you have more information about this ioctl.