Bug 444354 - segfault in dvgrab [solved]
segfault in dvgrab [solved]
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: libraw1394 (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Jarod Wilson
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-04-27 13:22 EDT by Mladen Kuntner
Modified: 2008-05-12 02:26 EDT (History)
2 users (show)

See Also:
Fixed In Version: 1.3.0-6.fc8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-04-29 16:55:52 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
unmap the correct max_packet_size on iso tear-down (854 bytes, patch)
2008-04-28 15:16 EDT, Jarod Wilson
no flags Details | Diff

  None (edit)
Description Mladen Kuntner 2008-04-27 13:22:02 EDT
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
Comment 1 Jarod Wilson 2008-04-28 14:05:08 EDT
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.
Comment 2 Jarod Wilson 2008-04-28 15:16:58 EDT
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.
Comment 3 Jarod Wilson 2008-04-28 15:52:55 EDT
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...
Comment 4 Fedora Update System 2008-04-28 18:28:42 EDT
libraw1394-1.3.0-6.fc8 has been submitted as an update for Fedora 8
Comment 5 Fedora Update System 2008-04-29 16:55:50 EDT
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.
Comment 6 Jindrich Novy 2008-05-11 06:18:42 EDT
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/.
Comment 7 Jarod Wilson 2008-05-12 01:22:16 EDT
(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.
Comment 8 Jarod Wilson 2008-05-12 01:23:22 EDT
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.
Comment 9 Jindrich Novy 2008-05-12 02:26:57 EDT
Indeed, the old libraw1394 originated from atrpms so not our problem. Anyway
thanks for the good news :)

Note You need to log in before you can comment on or make changes to this bug.