Bug 838279
| Summary: | [abrt] cheese-3.4.2-3.fc17: v4lconvert_yuyv_to_yuv420: Process /usr/bin/cheese was killed by signal 11 (SIGSEGV) | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Brandon <lordnynex> | ||||||||||||
| Component: | v4l-utils | Assignee: | Hans de Goede <hdegoede> | ||||||||||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||||
| Severity: | unspecified | Docs Contact: | |||||||||||||
| Priority: | unspecified | ||||||||||||||
| Version: | 17 | CC: | hdegoede, mchehab, mclasen | ||||||||||||
| Target Milestone: | --- | Keywords: | Reopened | ||||||||||||
| Target Release: | --- | ||||||||||||||
| Hardware: | x86_64 | ||||||||||||||
| OS: | Unspecified | ||||||||||||||
| Whiteboard: | abrt_hash:7f16e794c7f56a9d8bad77e895616b5c3dce43a2 | ||||||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||||||
| Doc Text: | Story Points: | --- | |||||||||||||
| Clone Of: | Environment: | ||||||||||||||
| Last Closed: | 2012-07-21 02:49:11 UTC | Type: | --- | ||||||||||||
| Regression: | --- | Mount Type: | --- | ||||||||||||
| Documentation: | --- | CRM: | |||||||||||||
| Verified Versions: | Category: | --- | |||||||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||||||
| Embargoed: | |||||||||||||||
| Attachments: |
|
||||||||||||||
|
Description
Brandon
2012-07-08 08:17:39 UTC
Created attachment 596854 [details]
File: backtrace
Created attachment 596855 [details]
File: maps
Created attachment 596856 [details]
File: dso_list
Created attachment 596857 [details]
File: build_ids
*** This bug has been marked as a duplicate of bug 810429 *** Looking at the backtrace this is a completely different bug then bug 810429 . The problem most people with tv/radio devices were having is that cheese crashed while enumerating video devices. Your trace-back is way past that point, when cheese is actually trying to stream video from the device, and happens inside libv4l rather then inside cheese itself -> re-opening this one to track the crash you're seeing. Hi Brandon, I would like to try and reproduce the crash you're seeing. So I've a few questions: 1) Is this crash reproducable, iow if you try cheese again it crashes again ? 2) What video hardware are you using? Can you attach the output of lspci and lsusb here to help me identify it? 3) Assuming the answer to 1 is yes, can you do the following from a terminal: export LIBV4L2_LOG_FILENAME=/tmp/log cheese Then wait for cheese to crash, and after the crash attach /tmp/log here? Thanks, Hans (In reply to comment #7) > > 1) Is this crash reproducable, iow if you try cheese again it crashes again ? Yes. Start up and segfault immediately. It is worth noting that the cheese window does display some video from the camera before it segfaults. > 2) What video hardware are you using? Can you attach the output of lspci and > lsusb here to help me identify it? Nvidia Gforce 9500 GT. Output is below. > 3) Assuming the answer to 1 is yes, can you do the following from a terminal: > export LIBV4L2_LOG_FILENAME=/tmp/log > cheese > Then wait for cheese to crash, and after the crash attach /tmp/log here? > Below is lsusb. It is worth noting that this is a 7M USB endoscope. It is a generic chinese camera that identifies as 'Generic USB Camera' on OS X and Windows. $ lsusb Bus 001 Device 005: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB Bus 001 Device 010: ID 0bda:5801 Realtek Semiconductor Corp. Bus 002 Device 002: ID 049f:0051 Compaq Computer Corp. KU-0133 Easy Access Interner Keyboard Bus 002 Device 003: ID 046d:c016 Logitech, Inc. Optical Wheel Mouse Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 006: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB Bus 001 Device 012: ID 0548:1005 Tyan Computer Corp. EZ Cart II GameBoy Flash Programmer Bus 001 Device 007: ID 0471:485d Philips (or NXP) Senselock SenseIV v2.x $ lspci 00:00.0 Host bridge: nVidia Corporation C55 Host Bridge (rev a2) 00:00.1 RAM memory: nVidia Corporation C55 Memory Controller (rev a1) 00:00.2 RAM memory: nVidia Corporation C55 Memory Controller (rev a1) 00:00.3 RAM memory: nVidia Corporation C55 Memory Controller (rev a1) 00:00.4 RAM memory: nVidia Corporation C55 Memory Controller (rev a1) 00:00.5 RAM memory: nVidia Corporation C55 Memory Controller (rev a2) 00:00.6 RAM memory: nVidia Corporation C55 Memory Controller (rev a1) 00:00.7 RAM memory: nVidia Corporation C55 Memory Controller (rev a1) 00:01.0 RAM memory: nVidia Corporation C55 Memory Controller (rev a1) 00:01.1 RAM memory: nVidia Corporation C55 Memory Controller (rev a1) 00:01.2 RAM memory: nVidia Corporation C55 Memory Controller (rev a1) 00:01.3 RAM memory: nVidia Corporation C55 Memory Controller (rev a1) 00:01.4 RAM memory: nVidia Corporation C55 Memory Controller (rev a1) 00:01.5 RAM memory: nVidia Corporation C55 Memory Controller (rev a1) 00:01.6 RAM memory: nVidia Corporation C55 Memory Controller (rev a1) 00:02.0 RAM memory: nVidia Corporation C55 Memory Controller (rev a1) 00:02.1 RAM memory: nVidia Corporation C55 Memory Controller (rev a1) 00:02.2 RAM memory: nVidia Corporation C55 Memory Controller (rev a1) 00:03.0 PCI bridge: nVidia Corporation C55 PCI Express bridge (rev a1) 00:09.0 RAM memory: nVidia Corporation MCP51 Host Bridge (rev a2) 00:0a.0 ISA bridge: nVidia Corporation MCP51 LPC Bridge (rev a3) 00:0a.1 SMBus: nVidia Corporation MCP51 SMBus (rev a3) 00:0a.2 RAM memory: nVidia Corporation MCP51 Memory Controller 0 (rev a3) 00:0b.0 USB Controller: nVidia Corporation MCP51 USB Controller (rev a3) 00:0b.1 USB Controller: nVidia Corporation MCP51 USB Controller (rev a3) 00:0d.0 IDE interface: nVidia Corporation MCP51 IDE (rev a1) 00:0e.0 IDE interface: nVidia Corporation MCP51 Serial ATA Controller (rev a1) 00:0f.0 IDE interface: nVidia Corporation MCP51 Serial ATA Controller (rev a1) 00:10.0 PCI bridge: nVidia Corporation MCP51 PCI Bridge (rev a2) 00:10.1 Audio device: nVidia Corporation MCP51 High Definition Audio (rev a2) 00:14.0 Bridge: nVidia Corporation MCP51 Ethernet Controller (rev a3) 01:00.0 PCI bridge: nVidia Corporation Device 05bf (rev a2) 02:00.0 PCI bridge: nVidia Corporation Device 05bf (rev a2) 02:01.0 PCI bridge: nVidia Corporation Device 05bf (rev a2) 02:02.0 PCI bridge: nVidia Corporation Device 05bf (rev a2) 02:03.0 PCI bridge: nVidia Corporation Device 05bf (rev a2) 03:00.0 VGA compatible controller: nVidia Corporation G96 [GeForce 9500 GT] (rev a1) 07:08.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller (rev c0) DMESG: [56534.478015] usb 1-8: new high-speed USB device number 13 using ehci_hcd [56535.138751] usb 1-8: New USB device found, idVendor=0bda, idProduct=5801 [56535.138754] usb 1-8: New USB device strings: Mfr=3, Product=1, SerialNumber=2 [56535.138757] usb 1-8: Product: USB Camera [56535.138759] usb 1-8: Manufacturer: Generic [56535.138761] usb 1-8: SerialNumber: 200901010001 [56535.148036] uvcvideo: Found UVC 1.00 device USB Camera (0bda:5801) [56535.166367] input: USB Camera as /devices/pci0000:00/0000:00:0b.1/usb1/1-8/1-8:1.0/input/input14 Created attachment 596927 [details]
LIBV4L2_LOG_FILENAME=/tmp/log
(In reply to comment #8) > (In reply to comment #7) > > 2) What video hardware are you using? Can you attach the output of lspci and > > lsusb here to help me identify it? > > Nvidia Gforce 9500 GT. Output is below. > I meant video input hardware not video output hardware, looking at the lspci / lsusb output you only have the UVC USB device as video input devices and no tv-cards / radio devices, etc. correct? (In reply to comment #9) > Created attachment 596927 [details] > LIBV4L2_LOG_FILENAME=/tmp/log Ah, now that one is very useful. So the problem seems to be that sometimes the UVC device returns incomplete frames, from the log: libv4l2: warning error while converting frame data: v4l-convert: error short yu request == VIDIOC_DQBUF result == 0 This one is fine, as libv4l2 automatically retries and that succeeds, further down the log we've: libv4l2: warning error while converting frame data: v4l-convert: error short yu libv4l2: warning error while converting frame data: v4l-convert: error short yu libv4l2: warning error while converting frame data: v4l-convert: error short yu libv4l2: warning error while converting frame data: v4l-convert: error short yu libv4l2: got 4 consecutive short frame errors, returning short frame request == VIDIOC_DQBUF result == 0 And then the next qbuf fails, this is because of a bug in libv4l2 where it requeues the buffer on an error which is retry-able, even if it is the last try! So then gstreamer tries to re-queue the already re-queued buf, and things go downhill from there. I'll prepare an update fixing this. v4l-utils-0.8.8-2.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/v4l-utils-0.8.8-2.fc17 v4l-utils-0.8.8-2.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/v4l-utils-0.8.8-2.fc16 Brandon, You can grab the new libv4l here: http://koji.fedoraproject.org/koji/buildinfo?buildID=329558 Download the version for your arch, and then do: sudo rpm -Uvh libv4l*.rpm And then try again please. Thanks & Regards, Hans Package v4l-utils-0.8.8-2.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing v4l-utils-0.8.8-2.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-10423/v4l-utils-0.8.8-2.fc16 then log in and leave karma (feedback). v4l-utils-0.8.8-2.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report. v4l-utils-0.8.8-2.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report. |