https://www.linuxtv.org/wiki/index.php?title=Talk:V4L_Test_Suite&feed=atom&action=historyTalk:V4L Test Suite - Revision history2024-03-19T05:13:21ZRevision history for this page on the wikiMediaWiki 1.39.6https://www.linuxtv.org/wiki/index.php?title=Talk:V4L_Test_Suite&diff=29664&oldid=prevCityK: adjust context slightly2011-10-05T22:39:45Z<p>adjust context slightly</p>
<table style="background-color: #fff; color: #202122;" data-mw="interface">
<col class="diff-marker" />
<col class="diff-content" />
<col class="diff-marker" />
<col class="diff-content" />
<tr class="diff-title" lang="en">
<td colspan="2" style="background-color: #fff; color: #202122; text-align: center;">← Older revision</td>
<td colspan="2" style="background-color: #fff; color: #202122; text-align: center;">Revision as of 22:39, 5 October 2011</td>
</tr><tr>
<td colspan="2" class="diff-lineno">Line 1:</td>
<td colspan="2" class="diff-lineno">Line 1:</td>
</tr>
<tr>
<td class="diff-marker" data-marker="−"></td>
<td style="color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #ffe49c; vertical-align: top; white-space: pre-wrap;"><div>It seems the 2 V4L2 examples (capture.c and vivi.c) don't play well with each other. I am not really sure where to post about this, so I will start here and move it to the appropriate place once I find it. so far http://bugzilla.kernel.org seems the most likely. I am dumping my notes <del style="font-weight: bold; text-decoration: none;">at the bottom of</del> this page to try to keep the point of <del style="font-weight: bold; text-decoration: none;">this</del> page from getting buried.</div></td>
<td class="diff-marker" data-marker="+"></td>
<td style="color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div>It seems the 2 V4L2 examples (capture.c and vivi.c) don't play well with each other. I am not really sure where to post about this, so I will start here and move it to the appropriate place once I find it. so far http://bugzilla.kernel.org seems the most likely. I am dumping my notes <ins style="font-weight: bold; text-decoration: none;">on</ins> this page to try to keep the point of <ins style="font-weight: bold; text-decoration: none;">the article</ins> page from getting buried.</div></td>
</tr>
<tr>
<td class="diff-marker"></td>
<td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><br /></td>
<td class="diff-marker"></td>
<td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><br /></td>
</tr>
<tr>
<td class="diff-marker"></td>
<td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><br /></td>
<td class="diff-marker"></td>
<td style="background-color: #f8f9fa; color: #202122; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #eaecf0; vertical-align: top; white-space: pre-wrap;"><br /></td>
</tr>
</table>CityKhttps://www.linuxtv.org/wiki/index.php?title=Talk:V4L_Test_Suite&diff=29663&oldid=prevCityK: add end user report of vivi & capture compatibility problems2011-10-05T22:38:28Z<p>add end user report of vivi & capture compatibility problems</p>
<p><b>New page</b></p><div>It seems the 2 V4L2 examples (capture.c and vivi.c) don't play well with each other. I am not really sure where to post about this, so I will start here and move it to the appropriate place once I find it. so far http://bugzilla.kernel.org seems the most likely. I am dumping my notes at the bottom of this page to try to keep the point of this page from getting buried.<br />
<br />
<br />
==Bugs in Examples==<br />
capture.c and vivi.c are V4L2 examples:<br />
<br />
capture: "Video for Linux Two API Specification: Revision 0.24 Appendix B. Video Capture Example" <br />
<br />
vivi: "It is intended to be a working example code for current V4L2 Driver and Stub driver to facilitate the implementation of new video drivers. <br />
<br />
They don't play well with each other. There is a memory leak, and I think vivi is telling capture to use a buffer mode that isn't valid - I call this "capabilities mismatch" but I am not really sure what the problem is.<br />
<br />
====Summary====<br />
<br />
detailed report: "vivi memory leak = kernel panic"<br />
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/294951<br />
<br />
=====memory leak=====<br />
sudo modprobe vivi<br />
gcc capture.c -g -o capture<br />
valgrind ./capture --userp -d /dev/video1<br />
==17153== malloc/free: in use at exit: 2,457,632 bytes in 5 blocks.<br />
<br />
=====capabilities mismatch=====<br />
./capture --userp -d /dev/video1<br />
VIDIOC_QBUF error 22, Invalid argument<br />
<br />
====Detail====<br />
setup for both: (capture.c is the original, same problem with capture_example.c, see URL above)<br />
<br />
wget http://www.linuxtv.org/downloads/video4linux/API/V4L2_API/v4l2spec/capture.c<br />
gcc capture.c -g -o capture<br />
sudo modprobe vivi<br />
dmesg | grep /dev/video1<br />
[ 1015.491550] vivi: V4L2 device registered as /dev/video1<br />
<br />
=====memory leak=====<br />
<pre><br />
# memleak.sh<br />
# runs capture to cause "Cannot allocate memory"<br />
# and logs /proc/meminfo along the way<br />
<br />
set -x<br />
<br />
sudo modprobe vivi<br />
dmesg|grep vivi<br />
<br />
# make sure the above grep matchs:<br />
DEV=/dev/video0<br />
<br />
if [ -d proc ]; then<br />
# wipe out previous run<br />
rm -f proc/meminfo*<br />
else<br />
# make a place to log proc/meminfo<br />
mkdir proc<br />
fi<br />
<br />
# 0.0 = start<br />
let a=0<br />
cp /proc/meminfo proc/meminfo$a.0.txt<br />
<br />
# loop until "Cannot allocate memory"<br />
while true; do<br />
<br />
((a+=1))<br />
<br />
# run using valid params, therefore should not error.<br />
./capture --read -d $DEV<br />
# unless something has sucked all the memory from somewhere.<br />
if [ "0" != "$?" ]; then break; fi<br />
# shouldn't be anything interesting, but log the state, just to be sure.<br />
cp /proc/meminfo proc/meminfo$a.1.txt<br />
<br />
# run with unsupported buffer mode<br />
./capture --userp -d $DEV<br />
# which didn't release memory from who knows where, so log the state:<br />
cp /proc/meminfo proc/meminfo$a.2.txt<br />
<br />
done<br />
<br />
# x.3 = final state. should be about the same as x.2<br />
cp /proc/meminfo proc/meminfo$a.3.txt<br />
</pre><br />
<br />
resulting data:<br />
http://spreadsheets.google.com/ccc?key=pIfz0wOzPtW1-oZkXXbvcLA&hl=en<br />
<br />
The runaways:<br />
HighFree go from 72608 to 252<br />
VmallocUsed from 6440 to 109724<br />
VmallocChunk from 103620 to 336<br />
<br />
<br />
Using valgrind (a suite of tools for debugging and profiling programs)<br />
<br />
<pre><br />
valgrind -v --leak-check=full --show-reachable=yes ./capture --userp -d /dev/video1<br />
<br />
==5166== Memcheck, a memory error detector.<br />
==5166== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.<br />
==5166== Using LibVEX rev 1854, a library for dynamic binary translation.<br />
==5166== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.<br />
==5166== Using valgrind-3.3.1-Debian, a dynamic binary instrumentation framework.<br />
==5166== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.<br />
==5166==<br />
--5166-- Command line<br />
--5166-- ./capture<br />
--5166-- --userp<br />
--5166-- -d<br />
--5166-- /dev/video1<br />
--5166-- Startup, with flags:<br />
--5166-- --suppressions=/usr/lib/valgrind/debian-libc6-dbg.supp<br />
--5166-- -v<br />
--5166-- --leak-check=full<br />
--5166-- --show-reachable=yes<br />
--5166-- Contents of /proc/version:<br />
--5166-- Linux version 2.6.27-7-generic (buildd@palmer) (gcc version 4.3.2<br />
(Ubuntu 4.3.2-1ubuntu11) ) #1 SMP Thu Oct 30 04:18:38 UTC 2008<br />
--5166-- Arch and hwcaps: X86, x86-sse1-sse2<br />
--5166-- Page sizes: currently 4096, max supported 4096<br />
--5166-- Valgrind library directory: /usr/lib/valgrind<br />
--5166-- Reading syms from /lib/ld-2.8.90.so (0x4000000)<br />
--5166-- Reading debug info from /lib/ld-2.8.90.so...<br />
--5166-- ... CRC mismatch (computed 371b8ee6 wanted cc0a418a)<br />
--5166-- Reading debug info from /usr/lib/debug/lib/ld-2.8.90.so...<br />
--5166-- Reading syms from /home/juser/vga2usb/v4l.org/examples/capture (0x8048000)<br />
--5166-- Reading syms from /usr/lib/valgrind/x86-linux/memcheck (0x38000000)<br />
--5166-- object doesn't have a dynamic symbol table<br />
--5166-- Reading suppressions file: /usr/lib/valgrind/debian-libc6-dbg.supp<br />
--5166-- Reading suppressions file: /usr/lib/valgrind/default.supp<br />
--5166-- REDIR: 0x40155d0 (index) redirected to 0x3802cf63<br />
(vgPlain_x86_linux_REDIR_FOR_index)<br />
--5166-- Reading syms from /usr/lib/valgrind/x86-linux/vgpreload_core.so (0x401F000)<br />
--5166-- Reading syms from /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so<br />
(0x4022000)<br />
==5166== WARNING: new redirection conflicts with existing -- ignoring it<br />
--5166-- new: 0x040155d0 (index ) R-> 0x040261a0 index<br />
--5166-- REDIR: 0x40157c0 (strlen) redirected to 0x4026450 (strlen)<br />
--5166-- Reading syms from /usr/lib/debug/libc-2.8.90.so (0x402A000)<br />
--5166-- REDIR: 0x409d2f0 (rindex) redirected to 0x4026080 (rindex)<br />
--5166-- REDIR: 0x409cf00 (strlen) redirected to 0x4026430 (strlen)<br />
--5166-- REDIR: 0x409d110 (strncmp) redirected to 0x40266a0 (strncmp)<br />
--5166-- REDIR: 0x409c7e0 (index) redirected to 0x4026170 (index)<br />
--5166-- REDIR: 0x409df70 (memset) redirected to 0x4027340 (memset)<br />
--5166-- REDIR: 0x4099c50 (calloc) redirected to 0x4023d20 (calloc)<br />
--5166-- REDIR: 0x409a190 (memalign) redirected to 0x4023b80 (memalign)<br />
--5166-- REDIR: 0x409e490 (memcpy) redirected to 0x40268a0 (memcpy)<br />
--5166-- REDIR: 0x409e180 (stpcpy) redirected to 0x40270d0 (stpcpy)<br />
--5166-- REDIR: 0x409dfd0 (mempcpy) redirected to 0x4027470 (mempcpy)<br />
--5166-- REDIR: 0x409f010 (strchrnul) redirected to 0x4027410 (strchrnul)<br />
<br />
VIDIOC_QBUF error 22, Invalid argument<br />
<br />
--5166-- REDIR: 0x4097730 (free) redirected to 0x4024a90 (free)<br />
==5166==<br />
==5166== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 11 from 1)<br />
--5166--<br />
--5166-- supp: 11 dl-hack3-cond-1<br />
==5166== malloc/free: in use at exit: 2,457,632 bytes in 5 blocks.<br />
==5166== malloc/free: 5 allocs, 0 frees, 2,457,632 bytes allocated.<br />
==5166==<br />
==5166== searching for pointers to 5 not-freed blocks.<br />
==5166== checked 51,772 bytes.<br />
==5166==<br />
==5166== 32 bytes in 1 blocks are still reachable in loss record 1 of 2<br />
==5166== at 0x4023DE2: calloc (vg_replace_malloc.c:397)<br />
==5166== by 0x80494AF: init_userp (in<br />
/home/juser/vga2usb/v4l.org/examples/capture)<br />
==5166== by 0x80498B0: init_device (in<br />
/home/juser/vga2usb/v4l.org/examples/capture)<br />
==5166== by 0x8049B63: main (in /home/juser/vga2usb/v4l.org/examples/capture)<br />
==5166==<br />
==5166==<br />
==5166== 2,457,600 bytes in 4 blocks are still reachable in loss record 2 of 2<br />
==5166== at 0x4023C4A: memalign (vg_replace_malloc.c:460)<br />
==5166== by 0x8049536: init_userp (in<br />
/home/juser/vga2usb/v4l.org/examples/capture)<br />
==5166== by 0x80498B0: init_device (in<br />
/home/juser/vga2usb/v4l.org/examples/capture)<br />
==5166== by 0x8049B63: main (in /home/juser/vga2usb/v4l.org/examples/capture)<br />
==5166==<br />
==5166== LEAK SUMMARY:<br />
==5166== definitely lost: 0 bytes in 0 blocks.<br />
==5166== possibly lost: 0 bytes in 0 blocks.<br />
==5166== still reachable: 2,457,632 bytes in 5 blocks.<br />
==5166== suppressed: 0 bytes in 0 blocks.<br />
--5166-- memcheck: sanity checks: 0 cheap, 1 expensive<br />
--5166-- memcheck: auxmaps: 0 auxmap entries (0k, 0M) in use<br />
--5166-- memcheck: auxmaps_L1: 0 searches, 0 cmps, ratio 0:10<br />
--5166-- memcheck: auxmaps_L2: 0 searches, 0 nodes<br />
--5166-- memcheck: SMs: n_issued = 10 (160k, 0M)<br />
--5166-- memcheck: SMs: n_deissued = 0 (0k, 0M)<br />
--5166-- memcheck: SMs: max_noaccess = 65535 (1048560k, 1023M)<br />
--5166-- memcheck: SMs: max_undefined = 34 (544k, 0M)<br />
--5166-- memcheck: SMs: max_defined = 20 (320k, 0M)<br />
--5166-- memcheck: SMs: max_non_DSM = 10 (160k, 0M)<br />
--5166-- memcheck: max sec V bit nodes: 0 (0k, 0M)<br />
--5166-- memcheck: set_sec_vbits8 calls: 0 (new: 0, updates: 0)<br />
--5166-- memcheck: max shadow mem size: 464k, 0M<br />
--5166-- translate: fast SP updates identified: 1,933 ( 89.4%)<br />
--5166-- translate: generic_known SP updates identified: 128 ( 5.9%)<br />
--5166-- translate: generic_unknown SP updates identified: 100 ( 4.6%)<br />
--5166-- tt/tc: 4,312 tt lookups requiring 4,351 probes<br />
--5166-- tt/tc: 4,312 fast-cache updates, 3 flushes<br />
--5166-- transtab: new 2,035 (43,121 -> 617,673; ratio 143:10) [0 scs]<br />
--5166-- transtab: dumped 0 (0 -> ??)<br />
--5166-- transtab: discarded 8 (200 -> ??)<br />
--5166-- scheduler: 25,512 jumps (bb entries).<br />
--5166-- scheduler: 0/2,355 major/minor sched events.<br />
--5166-- sanity: 1 cheap, 1 expensive checks.<br />
--5166-- exectx: 769 lists, 8 contexts (avg 0 per list)<br />
--5166-- exectx: 16 searches, 8 full compares (500 per 1000)<br />
--5166-- exectx: 4 cmp2, 26 cmp4, 0 cmpAll<br />
--5166-- errormgr: 8 supplist searches, 271 comparisons during search<br />
--5166-- errormgr: 11 errlist searches, 26 comparisons during search<br />
</pre><br />
<br />
from v4l list Andy Walls:<br />
<br />
It looks like init_userp() allocated a bunch of "buffers", which<br />
has to happen for a program to use user pointer mode of v4l2. The<br />
function errno_exit() doesn't bother to clean up when the VIDIOC_QBUF<br />
ioctl() call fails. free() is only called by uninit_device(). Since<br />
the alternate flow of the program through errno_exit() to termination<br />
doesn't call free() on "buffers", you should have a process heap memory<br />
leak on error exit.<br />
<br />
program didn't close it's file descriptors with the driver on errno_exit()<br />
<br />
=====capabilities mismatch=====<br />
<br />
Looking at the source, capture.c should have reported "does not support user pointer" by: <br />
<br />
411 init_userp (unsigned int buffer_size)<br />
421 req.count = 4;<br />
req.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;<br />
req.memory = V4L2_MEMORY_USERPTR;<br />
427 if (-1 == xioctl (fd, VIDIOC_REQBUFS, &req)) {<br />
if (EINVAL == errno) {<br />
fprintf (stderr, "%s does not support "<br />
"user pointer i/o\n", dev_name);<br />
exit (EXIT_FAILURE);<br />
<br />
<br />
But instead it errors here:<br />
<br />
250 start_capturing (void)<br />
260 case IO_METHOD_USERPTR:<br />
if (-1 == xioctl (fd, VIDIOC_QBUF, &buf))<br />
errno_exit ("VIDIOC_QBUF");<br />
<br />
====Canonical source of capture and vivi====<br />
* http://www.linuxtv.org/downloads/video4linux/API/V4L2_API/v4l2spec/capture.c<br />
<br />
*[http://git.linuxtv.org/media_tree.git/blob/HEAD:/drivers/media/video/vivi.c vivi.c]</div>CityK