Red Hat Bugzilla – Bug 444354
segfault in dvgrab [solved]
Last modified: 2008-05-12 02:26:57 EDT
Description of problem:
dvgrab is segfaulting
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. dvgrab -d 2 test
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:
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?
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
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
> 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
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 :)