Red Hat Bugzilla – Bug 201412
no images captured - cpu use goes to 100%
Last modified: 2008-05-06 16:55:01 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:126.96.36.199) Gecko/20060614 Fedora/188.8.131.52-1.2.fc5 Firefox/184.108.40.206 pango-text
Description of problem:
On running /usr/sbin/driftnet, it opens a window that is 0x0 in dimension. The only thing viewable is a tiny fraction of the window titlebar (metacity). An attempt at stretching that window to a usable size already causes a spike in the CPU usage levels.
With driftnet running (with the resized window), and CPU levels back down to normal, once a page with images is opened, none of the images are captured and the CPU usage levels shoot to 100%. At this point driftnet has probably hung since closing the window does not kill the program. It will also not respond to ^C.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Start with fully updated official FC5 system
2. Install driftnet & run '/usr/sbin/driftnet'
3. Open a webpage with some jpeg pictures
driftnet hangs, no images captures, CPU load is at 100% (driftnet).
driftnet should open a window with non-zero dimensions and display the images captured from the network.
Tried the binary from the Dries RPM repository as well. It opens a proper sized display window, but also hangs when a page with JPEGs is loaded.
The Dries binary works fine on a i386 FC4 machine. There are no FC4 i386 versions of driftnet in extras so I couldn't try that.
I have just upgraded the FC4 machine to FC5 and driftnet still does not work.
When I start it as 'driftnet -v' I can see that it is picking up the new network
connections but nothing is displayed on the screen. The program itself does not
hang however -- maybe that is a x86_64 only issue?
I think it's an x86-64 only issue.
Could you please try the patch attached?
Created attachment 134667 [details]
Okay, the patch definitely solves the software hang on x86_64. Closing the
window also kills the process as expected. However, driftnet still does not
display any captured images. The capture process itself seems to be working
since the command
driftnet -v -a -d /tmp
does save copies of the captured images in /tmp which can then be viewed using
an external viewer. So, the bottom line is that the built-in display of driftnet
does not seem to work on FC5 (i386/x86_64).
(In reply to comment #4)
> Okay, the patch definitely solves the software hang on x86_64. Closing the
> window also kills the process as expected. However, driftnet still does not
> display any captured images. The capture process itself seems to be working
> since the command
> driftnet -v -a -d /tmp
> does save copies of the captured images in /tmp which can then be viewed using
> an external viewer. So, the bottom line is that the built-in display of driftnet
> does not seem to work on FC5 (i386/x86_64).
Cool, it's most likely due to the gtk2 port code. I'll look into it soon.
I just send of a build request for driftnet-0.1.6-13.20040426cvs that should fix
all the problems. It works for me on my FC-7 x86_64.
I don't understand why, but it looks like the g_free(template) call causes the
tmpdir variable to get emptied. Since the template variable is no longer used,
I'm not sure why that happens at all. But commenting out that line made things
work for me. This only happens when not specifying -d, when creating a tmpdir
out of the template dirname using mkdtemp().
hmm, seems the endianness code fails on ppc64, so the build failed. I'll pick it
Please try driftnet-0.1.6-15.20040426cvs. It just finished building. It fixes
all problems for me (1 pixel window, hanging driftnet's, not capturing anything
Where do I find the rpm? Thanks.
You should be able to find it in the current rawhide/development tree, but I've
alo put one up for you at
I guess it just hadn't propagated through the mirrors yet. I'll try it out using
the rpm from your ftp.
I grabbed the rpm from your ftp and tried installing it but it seems to require
a version of libpcap (Missing Dependency: libpcap.so.0.9.4()(64bit)) that is not
available through _any_ of the repositories (I enabled them all using
--enablerepo=*). Since you mentioned that I should be able to get driftnet
through the development repo anyway, I waited for the last 5 days. As of today,
the only version available in rawhide is 0.1.6-12.
Could you please double-check whether the packages (driftnet/libpcap/...?) have
indeed been published through rawhide?
I finally managed to get the new driftnet via rawhide. After some testing, the
old issues seem to have been resolved. However, I did note a few more glitches:
1. When launched without an explicit interface specification, no images are
captured. According to the documentation, it should be listening on all interfaces.
2. Clicking on an image is supposed to save it. This does not seem to work (I
could not find any saved images under $HOME or /tmp).
Thanks for your efforts in fixing the package.
With the package I just pushed out, I can launch driftnet without any arguments,
and it captures from my eth0.
Clicking on an image to save, apparently only works when you specify -d somedir.
This error could be improved (or somedir could be set to . if it was not set I
driftnet-0.1.6-18.20040426cvs.fc7 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report.
driftnet-0.1.6-19.20040426cvs.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.
Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.
If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.
If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
Thanks for your help, and we apologize again that we haven't handled
these issues to this point.
The process we are following is outlined here:
We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers
This bug is open for a Fedora version that is no longer maintained and
will not be fixed by Fedora. Therefore we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen thus bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.
It is present in the others too. I have a fix that's in devel, that needs to be
pushed to the other releases..... please don't close this bug.
Paul, in which Fedora releases is this bug still present?
Actually, I just checked with the fedora 8.92 package, and it works now. And
that version is in F8 and F7 (it's the versions based on 20040426cvs).
So i guess we can really close this bug.