Description of problem: Running dvgrab results in a segmentation fault and no video files gets written. Version-Release number of selected component (if applicable): kernel-2.6.23.1-42.fc8 dvgrab-3.0-2.fc8 libraw1394-1.3.0-3.fc8 libavc1394-0.5.3-1.fc6 How reproducible: Always Steps to Reproduce: 1. Run dvgrab 2. dvgrab correctly identifies the camera and starts it 3. Segmentation fault Actual results: Segmentation fault Expected results: A video file Additional info: I have attached a file with the output of various runs of dvgrab using different options. [maxx@ice ~]$ dmesg |grep OHCI ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver firewire_ohci: Added fw-ohci device 0000:03:01.4, OHCI version 1.10 Output in /var/log/messages: Nov 8 10:05:04 localhost kernel: firewire_core: BM lock failed, making local node (ffc0) root. Nov 8 10:05:04 localhost kernel: firewire_core: phy config: card 0, new root=ffc0, gap_count=5 Nov 8 10:05:06 localhost kernel: firewire_core: phy config: card 0, new root=ffc1, gap_count=5 Nov 8 10:05:08 localhost kernel: firewire_core: created new fw device fw1 (1 config rom retries, S400) Nov 8 10:06:08 localhost kernel: dvgrab[6284]: segfault at b0f41c2c eip 00bc78ac esp b0ea413c error 6 Nov 8 10:06:10 localhost kernel: dvgrab[6288]: segfault at b0fe6e5c eip 00bc78ac esp b0f4913c error 6 Nov 8 10:06:23 localhost kernel: dvgrab[6295]: segfault at 06101418 eip 06101418 esp b0f8713c error 4 Nov 8 10:06:51 localhost kernel: dvgrab[6323]: segfault at b0fbf6dc eip 00bc78ac esp b0f2213c error 6 Nov 8 10:06:51 localhost kernel: firewire_ohci: context_stop: still active (0x48000411) Nov 8 10:07:00 localhost kernel: dvgrab[6335] general protection eip:92c968 esp:b0f65140 error:0
Created attachment 251301 [details] Output from dvgrab
i have this Found AV/C device with GUID 0x08004601044380f6 ioctl call failed, retval = -1 ieee1394io.cc:460: In function "virtual bool iec61883Reader::StartReceive()": "iec61883_dv_fb_start( m_iec61883.dv, channel )" evaluated to -1 ieee1394io.cc:460: errno: 38 (Function not implemented) Warning: Cannot set RR-scheduler Warning: Cannot disable swapping "" 0.00 MB 0 frames Capture Stopped How i fix this?
I just started running into this same segmentation fault myself. Looking into it...
Re comment #2 (Function not implemented): This appears to be bug 344851.
Is there any further information I can give that might help with this bug?
I have now tried this with kernel 2.6.23.13-106.fc8 and I still get a segmentation fault. I /var/log/messages the following appears: Jan 15 22:13:45 localhost kernel: firewire_core: BM lock failed, making local node (ffc0) root. Jan 15 22:13:45 localhost kernel: firewire_core: phy config: card 0, new root=ffc0, gap_count=5 Jan 15 22:13:47 localhost kernel: firewire_core: phy config: card 0, new root=ffc1, gap_count=5 Jan 15 22:13:49 localhost kernel: firewire_core: created new fw device fw1 (1 config rom retries, S400) Jan 15 22:14:57 localhost kernel: dvgrab[3726]: segfault at b0fa713c eip 00bc78ac esp b0f0a13c error 6 Furthermore dvgrab no longer started the video camera automatically - I had to manually press play for anything to happen.
Ignore the part about dvgrab no longer starting the video camera. I had added the noavc option to dvgrab. Without it dvgrab correctly starts the video camera. Still with the segfault though.
The 'BM lock failed' message seems to be a good indicator of forthcoming problems with dvgrab. I've seen that regularly on Via OHCI 1.0 systems that only capture a frame or two before hanging, as well as on systems that hit this segfault. However, I've also seen this segfault without the message.
The segfault is unrelated to the capture hang. Probably something in library code or dvgrab, concerning freeing of resources during shutdown. I have to look up the code and the spec what's up with the BM lock. It relates to higher-level bus management functions, hence is also unlikely to be connected with either of the other problems.
Mads, what controller does lspci say you have there? We've got a work-around patch for a bug in certain TI chipsets that *might* help out some here... Its in the rawhide kernel now, and will be in F8 kernel 2.6.24.4-81.fc8 and later.
[root@ice ~]# lspci | grep 1394 03:01.4 FireWire (IEEE 1394): O2 Micro, Inc. Firewire (IEEE 1394) (rev 02) In the meantime I have moved on to Fedora 9 - but I am still seeing a segfault (might be something different though): [root@ice ~]# dvgrab -autosplit -format raw -size 0 -timestamp foo- Found AV/C device with GUID 0x0000f0000c480971 *** buffer overflow detected ***: dvgrab terminated ======= Backtrace: ========= /lib/libc.so.6(__fortify_fail+0x48)[0x8d7ce8] /lib/libc.so.6[0x8d5de0] /lib/libc.so.6[0x8d54d8] /lib/libc.so.6(_IO_default_xsputn+0xc8)[0x84ce48] /lib/libc.so.6(_IO_vfprintf+0x14dc)[0x820c2c] /lib/libc.so.6(__vsprintf_chk+0xa7)[0x8d5587] Segmentation fault This is with the following software: kernel-2.6.25-14.fc9.i686 libavc1394-0.5.3-2.fc9.i386 libraw1394-1.3.0-6.fc9.i386 libdc1394-2.0.1-4.fc9.i386 dvgrab-3.1-2.fc9.i386
Any better with libraw1394-1.3.0-7.fc9 or even libraw1394-2.0.0-somethingorother in rawhide? There were a number of leaks plugged that might help here. I haven't been able to reproduce this one myself in a while...
I am currently 0using libraw1394 from Dan's git repo (last checked out: f9681ff59...) plus "Plug dir leak and initialize data structs". dvgrab's segfault at exit is indeed gone now. Only "-autosplit" without any "-size" still often (but not always) segfaults very early: $ dvgrab -autosplit Found AV/C device with GUID 0x008088030960484b Capture Started "dvgrab-009.dv": 0.14 MiB 1 frames timecode 180880164:-343379260:-1219637240.177513212 date 2008.06.24 07:19:19 Segmentation fault $ dvgrab -autosplit Found AV/C device with GUID 0x008088030960484b Capture Started "dvgrab-011.dv": buffer underrun near: timecode -1324125616:-1208056240:134520075.575116475 date 2008.06.24 07:19:23 This error means that the frames could not be written fast enough. ^C"dvgrab-011.dv": 97.50 MiB 710 frames timecode -1078045404:-1078045640:-1209854791.192078520 date 2008.06.24 07:19:51 Capture Stopped Warning: 1 dropped frames. $ ls -l dvgrab-{009,010,011}.dv -rw-r--r-- 1 abc def 144000 Jun 24 08:20 dvgrab-009.dv -rw-r--r-- 1 abc def 144000 Jun 24 08:20 dvgrab-010.dv -rw-r--r-- 1 abc def 102240000 Jun 24 08:21 dvgrab-011.dv This was a quick test on an OHCI 1.1 VT6307. Setting an arbitrary "-size" option seems to prevent the premature split and segfault.
PS: from syslog: Jun 24 08:20:34 stein dvgrab[12392]: segfault at 64 ip 080551ca sp b1138100 error 4 in dvgrab[8048000+3a000] The former segfaults were different: Jun 8 11:46:49 stein dvgrab[32687]: segfault at b092f008 ip b7fb831a sp bfffe070 error 4 in libiec61883.so.0.1.0[b7fb0000+c000]
Created attachment 310175 [details] [dvgrab patch] fix segfault when timecodes are bad (from Patrick Mansfield) In a posting today, Dan pointed to the following patches: http://sourceforge.net/mailarchive/forum.php?thread_name=20080413184243.GA5815%40aracnet.com&forum_name=kino-dev http://sourceforge.net/mailarchive/forum.php?thread_name=20080414015310.GA10728%40aracnet.com&forum_name=kino-dev Of them, "fix segfault when timecodes are bad" applied on top of vanilla dvgrab-3.1 (built on Gentoo) fixes the autosplit segfault mentioned in my previous comment. What still happens is that the timestamps are wrong. This may sometimes cause the autosplit feature to create a myriad of small .dv files. See next comment on the other of the two patches which deals with timestamps.
Created attachment 310176 [details] [dvgrab patch] fix odd timecode values (from Patrick Mansfield) This patch replaces garbage timecodes with zero timecodes. However, this does no good if run on Juju. Apparently many or all timestamps delivered by Juju are bad, hence dvgrab will often or always get 0 timestamps with this patch, and the result is that dvgrab does not save a .dv file anymore at all.
Comment on attachment 310176 [details] [dvgrab patch] fix odd timecode values (from Patrick Mansfield) This patch is not actually "obsolete" but rather not useful, at least not with Juju.
Ah, don't think I'd tried with autosplit lately. I'll get the patch from comment #15 into the Fedora builds ASAP. Thanks much! If I'm remembering correctly, krh said lack of timestamps was a known issue that we still need to remedy...
dvgrab-3.1-3.fc9 has been submitted as an update for Fedora 9
dvgrab-3.1-3.fc8 has been submitted as an update for Fedora 8
dvgrab-3.1-3.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
dvgrab-3.1-3.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.
[maxx@ice ~]$ rpm -q dvgrab libraw1394 dvgrab-3.1-3.fc9.i386 libraw1394-1.3.0-7.fc9.i386 I still get the segfault - and it doesn't matter what options I use. With/without -autosplit, with/without -size, with/without -timestamp. I always get the following error immediately after starting dvgrab: Found AV/C device with GUID 0x0000f0000c480971 "": buffer underrun near: timecode 00:00:00.00 date ????.??.?? ??:??:?? This error means that the frames could not be written fast enough. *** buffer overflow detected ***: dvgrab terminated ======= Backtrace: ========= /lib/libc.so.6(__fortify_fail+0x48)[0xacfce8] /lib/libc.so.6[0xacdde0] /lib/libc.so.6[0xacd4d8] /lib/libc.so.6(_IO_default_xsputn+0xc8)[0xa44e48] /lib/libc.so.6(_IO_vfprintf+0x697)[0xa17de7] /lib/libc.so.6(__vsprintf_chk+0xa7)[0xacd587] /lib/libc.so.6(__sprintf_chk+0x2d)[0xacd4cd] dvgrab[0x8054f6f] dvgrab[0x805581e] dvgrab[0x8055c01] /lib/libpthread.so.0[0xb7c32f] /lib/libc.so.6(clone+0x5e)[0xab727e]
I really wish I'd noted which system and which controller I hit this segfault on myself. Going back through all my systems and controllers looking for the reproducer is on the TODO list, but other duties keep getting in the way...
This message is a reminder that Fedora 8 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 8. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '8'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 8's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 8 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
A few recent fixes in libraw1394 *might* have cured this bug. Would be good to see if it can be reproduced on F10.
I just updated to libraw1394-2.0.0-6.fc10 from the testing repo, and this problem still exists with Fedora 10. [maxx@ice Videos]$ dvgrab -autosplit -showstatus -t foo Found AV/C device with GUID 0x0000f0000c480971 Warning: Cannot set RR-scheduler Warning: Cannot disable swapping "": buffer underrun near: timecode ??:??:??.?? date ????.??.?? ??:??:?? This error means that the frames could not be written fast enough. Segmentation fault Output from /var/log/messages: Jan 17 15:25:33 localhost kernel: firewire_core: skipped bus generations, destroying all nodes Jan 17 15:25:34 localhost kernel: firewire_core: BM lock failed, making local node (ffc0) root. Jan 17 15:25:34 localhost kernel: firewire_core: phy config: card 0, new root=ffc0, gap_count=5 Jan 17 15:25:34 localhost kernel: firewire_core: created device fw0: GUID 434fc00037814050, S400 Jan 17 15:25:35 localhost kernel: firewire_core: phy config: card 0, new root=ffc1, gap_count=5 Jan 17 15:25:37 localhost kernel: firewire_core: created device fw1: GUID 0000f0000c480971, S400, 1 config ROM retries Jan 17 15:25:44 localhost kernel: dvgrab[17706]: segfault at b0d1477c ip 00df4315 sp b0c72120 error 6 in libiec61883.so.0.1.0[dec000+d000] Jan 17 15:25:49 localhost kernel: dvgrab[17713] general protection ip:df4288 sp:b0c73120 error:0 in libiec61883.so.0.1.0[dec000+d000] Jan 17 15:25:49 localhost kernel: firewire_ohci: context_stop: still active (0x48000411) Jan 17 15:25:59 localhost kernel: dvgrab[17720] general protection ip:df4288 sp:b0adc120 error:0 in libiec61883.so.0.1.0[dec000+d000]
libiec61883 1.2.0 has been released by upstream two days ago. According to the changelog, data validation was improved. May be relevant to this bug. http://ieee1394.wiki.kernel.org/index.php/Release_Notes_-_Libraries#libiec61883
Sounded like a good idea with libiec61883, so I downloaded the latest version (1.2.0), but unfortunately it didn't help. The errors changed, though. It seems that it is now libdv that is crashing. Here is the output in /var/log/messages: Jan 18 00:05:28 localhost kernel: firewire_core: phy config: card 0, new root=ffc1, gap_count=5 Jan 18 00:05:30 localhost kernel: firewire_core: phy config: card 0, new root=ffc1, gap_count=5 Jan 18 00:05:32 localhost kernel: firewire_core: created device fw1: GUID 0000f0000c480971, S400, 1 config ROM retries Jan 18 00:06:21 localhost kernel: dvgrab[20053]: segfault at 20 ip 00d2fa67 sp b0ac1050 error 6 in libdv.so.4.0.3[d28000+1b000] Jan 18 00:06:34 localhost kernel: dvgrab[20064]: segfault at 20 ip 00d2fa67 sp b0b9e050 error 6 in libdv.so.4.0.3[d28000+1b000] Jan 18 00:07:31 localhost kernel: dvgrab[20163]: segfault at 20 ip 00d2fa67 sp b0ba7050 error 6 in libdv.so.4.0.3[d28000+1b000] And from running dvgrab: [maxx@ice ~]$ dvgrab -autosplit -showstatus -t foo Found AV/C device with GUID 0x0000f0000c480971 Warning: Cannot set RR-scheduler Warning: Cannot disable swapping "": buffer underrun near: timecode ??:??:??.?? date ????.??.?? ??:??:?? This error means that the frames could not be written fast enough. Capture Started "": buffer underrun near: timecode ??:??:??.?? date 1999.11.30 00:00:00 This error means that the frames could not be written fast enough. "foo1999.11.30_00-00-00": 0.11 MiB 1 frames timecode ??:??:??.?? date 1999.11.30 00:00:00 Warning: 4 dropped frames. "foo1999.11.30_00-00-00": buffer underrun near: timecode ??:??:??.?? date ????.??.?? ??:??:?? This error means that the frames could not be written fast enough. "foo1999.11.30_00-00-00": buffer underrun near: timecode ??:??:??.?? date ????.??.?? ??:??:?? This error means that the frames could not be written fast enough. "foo1999.11.30_00-00-00": buffer underrun near: timecode ??:??:??.?? date ????.??.?? ??:??:?? This error means that the frames could not be written fast enough. "foo1999.11.30_00-00-00": buffer underrun near: timecode ??:??:??.?? date ????.??.?? ??:??:?? This error means that the frames could not be written fast enough. "foo1999.11.30_00-00-00": buffer underrun near: timecode ??:??:??.?? date ????.??.?? ??:??:?? This error means that the frames could not be written fast enough. "foo1999.11.30_00-00-00": buffer underrun near: timecode ??:??:??.?? date 1999.11.30 00:00:00 This error means that the frames could not be written fast enough. "foo1999.11.30_00-00-00": 0.14 MiB 1 frames timecode ??:??:??.?? date 1999.11.30 00:00:00 Warning: 7 dropped frames. "foo1999.11.30_00-00-00": buffer underrun near: timecode ??:??:??.?? date ????.??.?? ??:??:?? This error means that the frames could not be written fast enough. "foo1999.11.30_00-00-00": buffer underrun near: timecode ??:??:??.?? date ????.??.?? ??:??:?? This error means that the frames could not be written fast enough. "foo1999.11.30_00-00-00": buffer underrun near: timecode ??:??:??.?? date ????.??.?? ??:??:?? This error means that the frames could not be written fast enough. "foo1999.11.30_00-00-00": buffer underrun near: timecode ??:??:??.?? date ????.??.?? ??:??:?? This error means that the frames could not be written fast enough. "foo1999.11.30_00-00-00": buffer underrun near: timecode ??:??:??.?? date ????.??.?? ??:??:?? This error means that the frames could not be written fast enough. "foo1999.11.30_00-00-00": 0.11 MiB 1 frames timecode ??:??:??.?? date 1999.11.30 00:00:00 Warning: 11 dropped frames. "foo1999.11.30_00-00-00": buffer underrun near: timecode ??:??:??.?? date ????.??.?? ??:??:?? This error means that the frames could not be written fast enough. "foo1999.11.30_00-00-00": 0.14 MiB 1 frames timecode ??:??:??.?? date 1999.11.30 00:00:00 Warning: 4 dropped frames. "foo1999.11.30_00-00-00": buffer underrun near: timecode ??:??:??.?? date ????.??.?? ??:??:?? This error means that the frames could not be written fast enough. "foo1999.11.30_00-00-00": 0.11 MiB 1 frames timecode ??:??:??.?? date 1999.11.30 00:00:00 Warning: 14 dropped frames. "foo1999.11.30_00-00-00": buffer underrun near: timecode ??:??:??.?? date ????.??.?? ??:??:?? This error means that the frames could not be written fast enough. "foo1999.11.30_00-00-00": 0.11 MiB 1 frames timecode 37:65:38.35 date 1999.11.30 00:00:00 Warning: 6 dropped frames. "foo1999.11.30_00-00-00": buffer underrun near: timecode ??:??:??.?? date ????.??.?? ??:??:?? This error means that the frames could not be written fast enough. "foo1999.11.30_00-00-00": buffer underrun near: timecode ??:??:??.?? date ????.??.?? ??:??:?? This error means that the frames could not be written fast enough. "foo1999.11.30_00-00-00": buffer underrun near: timecode ??:??:??.?? date ????.??.?? ??:??:?? This error means that the frames could not be written fast enough. "foo1999.11.30_00-00-00": buffer underrun near: timecode ??:??:??.?? date ????.??.?? ??:??:?? This error means that the frames could not be written fast enough. "foo1999.11.30_00-00-00": 0.11 MiB 1 frames timecode 37:65:38.35 date 1999.11.30 00:00:00 Warning: 25 dropped frames. "foo1999.11.30_00-00-00": 0.14 MiB 1 frames timecode 37:65:38.35 date 1999.11.30 00:00:00 "foo1999.11.30_00-00-00": 0.11 MiB 1 frames timecode 37:65:38.35 date 1999.11.30 00:00:00 "foo1999.11.30_00-00-00": buffer underrun near: timecode ??:??:??.?? date ????.??.?? ??:??:?? This error means that the frames could not be written fast enough. "foo1999.11.30_00-00-00": 0.11 MiB 1 frames timecode 37:65:38.35 date 1999.11.30 00:00:00 Warning: 6 dropped frames. Segmentation fault
Just an update to tell that this is still happening with Fedora 11. dvgrab-3.4-2.fc11.i586 libiec61883-1.2.0-2.fc11.i586 libraw1394-2.0.1-2.fc11.i586 kernel-2.6.29.1-111.fc11.i586
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '11'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 11's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 11 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.