Description of problem: dvgrab is segfaulting Version-Release number of selected component (if applicable): How reproducible: always Steps to Reproduce: 1. dvgrab -d 2 test 2. segfault 3. Actual results: segfault Expected results: no segfault Additional info: There is iso_init in libraw1394-juju.patch There is a line: handle->iso.max_packet_size = round_to_power_of_two(max_packet_size); and there is a line: handle->iso.buffer = mmap(NULL, buf_packets * max_packet_size, prot, MAP_SHARED, handle->iso.fd, 0); If we replace max_packet_size with round_to_power_of_two(max_packet_size) in mmap call there is no segfault. Can somebody verify that this is correct? Thanks
I believe you're absolutely correct, and its the munmap in raw1394_iso_shutdown() that uses handle->iso.max_packet_size vs. the original max_packet_size that must trigger the segfault.
Created attachment 304028 [details] unmap the correct max_packet_size on iso tear-down Yeah, this is definitely a winner in functional testing too. I'm going to get new builds out ASAP.
libraw1394-1.3.0-6.fc9 built, requesting it for inclusion in the f9 release iso, will get builds done for other dists after lunch...
libraw1394-1.3.0-6.fc8 has been submitted as an update for Fedora 8
libraw1394-1.3.0-6.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.
I see this while updating: Transaction Check Error: file /usr/lib64/libraw1394.so.8.2.0 from install of libraw1394-1.3.0-6.fc8.x86_64 conflicts with file from package libraw1394_8-1.3.0-3_11.fc8.x86_64 The same thing happens on i386 for /usr/lib/.
(In reply to comment #6) > I see this while updating: > > Transaction Check Error: > file /usr/lib64/libraw1394.so.8.2.0 from install of > libraw1394-1.3.0-6.fc8.x86_64 conflicts with file from package > libraw1394_8-1.3.0-3_11.fc8.x86_64 > > The same thing happens on i386 for /usr/lib/. Not our problem. You have ATrpms' libraw1394 packages installed. Either don't do that, or talk to Axel about packing his stuff in a way that doesn't hork up yum upgrades.
Nb: Real Soon Now, there will be a libraw1394 with unified support for both the old ieee1394 and the new firewire driver stacks, which will eliminate the need for ATrpms to ship any libraw1394 at all.
Indeed, the old libraw1394 originated from atrpms so not our problem. Anyway thanks for the good news :)