Description of problem: When running motion (motion sensor/security camera software) with libv4l2convert.so LD_PRELOADED (in order to support the pixel formats for my Logitech QuickCam Chat camera, which uses the spca561 driver), it periodically crashes with a divide error inside libv4lconvert. The crash seems to coincide with some rather wild, unexplained white balance fluctuations that the auto white balance feature seems to be causing. This may be related to the root cause. Version-Release number of selected component (if applicable): libv4l-0.5.99-1.fc11.x86_64 How reproducible: Fairly Steps to Reproduce: 1. Run motion daemon with LD_PRELOAD=/usr/lib64/libv4l/v4l2convert.so daemon /usr/bin/motion 2> /dev/null 2. Wait a while 3. Actual results: Divide error crash Expected results: No crash Additional info: Stack trace with debug info below. I added the local variables that were available, let me know if you need more out of the core file. It appears the immediate cause of the crash is that comp2_avg is zero. #0 0x00000032ad60fd10 in whitebalance_calculate_lookup_tables_bayer (data=<value optimized out>, buf=<value optimized out>, fmt=<value optimized out>, starts_with_green=<value optimized out>) at processing/whitebalance.c:77 x = <value optimized out> y = 288 a1 = <value optimized out> a2 = <value optimized out> b1 = 0 b2 = <value optimized out> green_avg = 25245 comp1_avg = 25245 comp2_avg = 0 avg_avg = 16830 #1 0x00000032ad60f8da in v4lprocessing_update_lookup_tables (fmt=<value optimized out>, buf=<value optimized out>, data=<value optimized out>) at processing/libv4lprocessing.c:82 #2 v4lprocessing_processing (fmt=<value optimized out>, buf=<value optimized out>, data=<value optimized out>) at processing/libv4lprocessing.c:172 #3 0x00000032ad601d6e in v4lconvert_convert_pixfmt (data=0x7f779c000a00, src=0x7f77a1ff6000 <Address 0x7f77a1ff6000 out of bounds>, src_size=<value optimized out>, dest=<value optimized out>, fmt=<value optimized out>, dest_pix_fmt=842093913) at libv4lconvert.c:721 #4 0x00000032ad602ed7 in v4lconvert_convert (data=0x7f779c000a00, src_fmt=<value optimized out>, dest_fmt=<value optimized out>, src=0x7f77a1ff6000 <Address 0x7f77a1ff6000 out of bounds>, src_size=<value optimized out>, dest=0x7f7798000000 "\252\252\252\252\252\252\252\252\252\252\252\252\252\247\243\234\223\220\215\217\224\220\224\227\232\235\241\247\252\252\252\252\252\252\252\252\252\252\252\246\242\246\250\246\251\236\235\230\225\225\226\230\232\234\235\232\232\236\242\242\243\242\241\244\243\250\252\251\252\244\242\244\243\247\252\252\252\252\252\247\241\247\252\252\252\252\252\252\252\252\252\247\250\247\251\245\250\246\252\237\226\225\223\227\235\230\224\225\226\227\235\227\223\227\235\227\224\224\223\221\224\230\236\227\225\225\226\232\241\246\252\244\241\243\252\237\236\241\252\252\252\252\252\242\236\230\224\230\226\243\252\252\252\242\250\247\252\251\252\252\252\252\252\252\252\246\250\251\252\252\252\252\252\252\252\252\252\252\252\252\252\252\252\252\252\252\252\252\252\252\252\252\252\252\252\252\252\252\252\252"..., dest_size=16777216) at libv4lconvert.c:1004 #5 0x00000032ada030b8 in v4l2_dequeue_and_convert (index=<value optimized out>, buf=0x7f779c001420, dest=0x0, dest_size=<value optimized out>) at libv4l2.c:278 #6 0x00000032ada03953 in v4l2_ioctl (fd=<value optimized out>, request=<value optimized out>) at libv4l2.c:1014 #7 0x00007f77a20049ab in ioctl (fd=-1677717872, request=25245) at v4l2convert.c:138 #8 0x000000000040d198 in xioctl (fd=3, request=<value optimized out>, arg=0x7f779c001420) at video2.c:128 #9 0x000000000040d366 in v4l2_next (cnt=0x13b2030, viddev=0x7f779c000940, map=0x7f7797ba6010 "\177\200\210\207\217\227\256\256\256\244\227\214\206thea_^_a_bcdfhknorsuqrolmmkikkklgecbbcddffeeghhihhjiquoljijinurvyyqhoxyzxutusrmkkljklqibbacecbbbcecacecaaa`acfcbbcdhoxnhilgfly\177\214\200|nfcacclqsxlkmroqu}znnollnr\221\256\256\256\256\256\256\256\256\256\256\256\256\256\256\256\256\256\256\256\256\256\256\256\256\256\256\256\256\256\256"..., width=352, height=288) at video2.c:789 #10 0x000000000040f4da in vid_next (cnt=0x13b2030, map=0x7f7797ba6010 "\177\200\210\207\217\227\256\256\256\244\227\214\206thea_^_a_bcdfhknorsuqrolmmkikkklgecbbcddffeeghhihhjiquoljijinurvyyqhoxyzxutusrmkkljklqibbacecbbbcecacecaaa`acfcbbcdhoxnhilgfly\177\214\200|nfcacclqsxlkmroqu}znnollnr\221\256\256\256\256\256\256\256\256\256\256\256\256\256\256\256\256\256\256\256\256\256\256\256\256\256\256\256\256\256\256"...) at video_common.c:949 #11 0x0000000000405ce6 in motion_loop (arg=<value optimized out>) at motion.c:1116 #12 0x0000003f5200686a in start_thread (arg=<value optimized out>) at pthread_create.c:297 #13 0x0000003f514de25d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #14 0x0000000000000000 in ?? ()
Thanks for the report, this is a bit strange, but non the less the divide by 0 is a bug. Here is a new version which should have this fixed, and which only allows slow changes to the whitebalance, which should filter out the "unexplained white balance fluctuations": http://koji.fedoraproject.org/koji/taskinfo?taskID=1433390 I believe the root cause for these lives outside libv4l (either a driver bug, or maybe motion is doing something to the buffers while we're using them), but this should fix things anyways. Can you please give this new version a try?
I haven't seen any crashes yet with the new version. However, the white balance behavior doesn't really seem improved. I'm still seeing the white balance fluctuating back and forth, sometimes wildly. The behavior is a little bit odd in other ways, too: if I start v4l2ucp and hit the "update" button for white balance while auto white balance is enabled, the displayed value doesn't seem to change even though the white balance seems to be changing based on the image. (For the exposure setting, the displayed value does update when the library is making adjustments.) Also, even if I disable auto white balance and adjust the white balance manually all the way to minimum or maximum (1 or 127), I don't get such significant color shifts as I'm seeing with auto white balance enabled, which seems odd..
(In reply to comment #2) > I haven't seen any crashes yet with the new version. However, the white balance > behavior doesn't really seem improved. I'm still seeing the white balance > fluctuating back and forth, sometimes wildly. > I'm thinking this is a motion bug actually, I just saw a similar report on the uvc mailing list, in a case where libv4l doesn't come into play. I'll forward the mail. > The behavior is a little bit odd in other ways, too: if I start v4l2ucp and hit > the "update" button for white balance while auto white balance is enabled, the > displayed value doesn't seem to change even though the white balance seems to > be changing based on the image. Ah, yes I must admit this is confusing, the auto whitebalance option enables a software algorithm, which modifies the image in software, there are 2 reasons for this: 1) Some webcams don't have a hardware whitebalance adjustment 2) We do not know exactly what sort of color gain correction factors the whitebalance hardware control does, so we cannot use as we do not know at which value to put it. > (For the exposure setting, the displayed value > does update when the library is making adjustments.) > Ack, the autogain software processing will change the hardware controls (doing gain in software makes no sense) instead of manipulating the image as the whitebalance code does. > Also, even if I disable auto white balance and adjust the white balance > manually all the way to minimum or maximum (1 or 127), I don't get such > significant color shifts as I'm seeing with auto white balance enabled, which > seems odd.. See above. Regards, Hans
Ah, that explains why the color can fluctuate more, if it's not actually modifying the hardware white balance settings. That report you forwarded doesn't seem like quite the same issue though.. they seem to be complaining about statically wrong white balance, whereas in my case the auto white balance usually seems to find a reasonable setting, but sometimes tends to bounce around, sometimes really severely..
Here's Motion's output on startup, if it's any use: [0] Processing thread 0 - config file /etc/motion/motion.conf [0] Motion 3.2.11 Started [0] ffmpeg LIBAVCODEC_BUILD 3412992 LIBAVFORMAT_BUILD 3415808 [0] Thread 1 is from /etc/motion/motion.conf [1] Thread 1 started [0] motion-httpd/3.2.11 running, accepting connections [0] motion-httpd: waiting for data on port TCP 8080 [1] cap.driver: "spca561" [1] cap.card: "Camera" [1] cap.bus_info: "usb-0000:00:02.1-4.2" [1] cap.capabilities=0x05000001 [1] - VIDEO_CAPTURE [1] - READWRITE [1] - STREAMING [1] v4l2_select_input: name = "spca561", type 0x00000002, status 00000000 [1] - CAMERA [1] Supported palettes: [1] 0: RGB3 (RGB3) [1] 1: BGR3 (BGR3) [1] 2: YU12 (YU12) [1] Selected palette YU12 [1] index_format 8 Test palette YU12 (352x288) [1] Using palette YU12 (352x288) bytesperlines 352 sizeimage 152064 colorspace 00000008 [1] found control 0x00980910, "Gamma (software)", range 500,3000 [1] "Gamma (software)", default 1000, current 1000 [1] found control 0x00980911, "Exposure", range 1,3195 [1] "Exposure", default 200, current 3195 [1] found control 0x00980912, "Auto Gain (software)", range 0,1 [1] "Auto Gain (software)", default 1, current 1 [1] found control 0x00980913, "Gain", range 0,36 [1] "Gain", default 36, current 36 [1] mmap information: [1] frames=4 [1] 0 length=16777216 [1] 1 length=16777216 [1] 2 length=16777216 [1] 3 length=16777216 [1] Using V4L2
Created attachment 349667 [details] Video that illustrates the kind of white balance fluctuations I'm seeing A short video clip from Motion that shows what I'm talking about.. especially the significant brief white balance shift at about 5 seconds in. The brief blips earlier in the video are happening pretty regularly.
Robert, The camera which you are using is not only using auto whitebalance, but also autogain, after gain / exposure changes it may take a (short) time for the whitebalance algorithm to compensate. Try disabling the autogain control, then this should go away. Regards, Hans
Unfortunately disabling autogain isn't really an option for me, it's actually more important than the auto white balance as the camera experiences significant light level fluctuations being aimed outside. Any chance of getting the two options to play nicer together, if that is indeed the cause? That seems a bit odd to me, the white balance fluctuations seem a bit extreme to be caused by the usual exposure changes which are pretty minute..
v4l2ucp-1.3-2.fc11,libv4l-0.6.0-1.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/v4l2ucp-1.3-2.fc11,libv4l-0.6.0-1.fc11
v4l2ucp-1.3-2.fc11, libv4l-0.6.0-1.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update v4l2ucp libv4l'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-7594
v4l2ucp-1.3-2.fc11,libv4l-0.6.1-1.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/v4l2ucp-1.3-2.fc11,libv4l-0.6.1-1.fc11
v4l2ucp-1.3-2.fc10,libv4l-0.6.1-1.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/v4l2ucp-1.3-2.fc10,libv4l-0.6.1-1.fc10
v4l2ucp-1.3-2.fc10, libv4l-0.6.1-1.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update v4l2ucp libv4l'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-9209
v4l2ucp-1.3-2.fc11, libv4l-0.6.1-1.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update v4l2ucp libv4l'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-9215
v4l2ucp-1.3-2.fc11, libv4l-0.6.1-1.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
v4l2ucp-1.3-2.fc10, libv4l-0.6.1-1.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.
It doesn't seem like the last updates really address the auto white balance problem I was seeing - the auto white balance still seems to go nuts with motion sometimes, causing wild color shifts sometimes (against a frozen image, strangely enough).