Bug 201412 - no images captured - cpu use goes to 100%
no images captured - cpu use goes to 100%
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: driftnet (Show other bugs)
5
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Paul Wouters
Fedora Extras Quality Assurance
bzcl34nup
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-08-04 18:01 EDT by Mostafa Afgani
Modified: 2008-05-06 16:55 EDT (History)
3 users (show)

See Also:
Fixed In Version: 20040426cvs
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-06 16:55:01 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)
driftnet-64bit-spin.patch (1.58 KB, patch)
2006-08-22 16:08 EDT, Bastien Nocera
no flags Details | Diff

  None (edit)
Description Mostafa Afgani 2006-08-04 18:01:14 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.0.4) Gecko/20060614 Fedora/1.5.0.4-1.2.fc5 Firefox/1.5.0.4 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):
driftnet-0.1.6-9.fc5.3

How reproducible:
Always


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

Actual Results:
driftnet hangs, no images captures, CPU load is at 100% (driftnet).

Expected Results:
driftnet should open a window with non-zero dimensions and display the images captured from the network.

Additional info:
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.
Comment 1 Mostafa Afgani 2006-08-09 07:05:28 EDT
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?
Comment 2 Bastien Nocera 2006-08-22 16:07:32 EDT
I think it's an x86-64 only issue.
Could you please try the patch attached?
Comment 3 Bastien Nocera 2006-08-22 16:08:05 EDT
Created attachment 134667 [details]
driftnet-64bit-spin.patch
Comment 4 Mostafa Afgani 2006-08-23 17:45:07 EDT
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).
Comment 5 Bastien Nocera 2006-08-24 05:19:39 EDT
(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.
Comment 6 Paul Wouters 2007-10-22 01:33:55 EDT
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().
Comment 7 Paul Wouters 2007-10-22 01:38:00 EDT
hmm, seems the endianness code fails on ppc64, so the build failed. I'll pick it
up tomorrow.
Comment 8 Paul Wouters 2007-10-22 21:19:11 EDT
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
at all).
Comment 9 Mostafa Afgani 2007-10-23 04:09:11 EDT
Where do I find the rpm? Thanks.
Comment 10 Paul Wouters 2007-10-23 09:21:04 EDT
You should be able to find it in the current rawhide/development tree, but I've
alo put one up for you at
ftp://ftp.xelerance.com/driftnet-0.1.6-15.20040426cvs.x86_64.rpm

Comment 11 Mostafa Afgani 2007-10-23 11:16:44 EDT
I guess it just hadn't propagated through the mirrors yet. I'll try it out using
the rpm from your ftp.
Comment 12 Mostafa Afgani 2007-10-28 13:08:52 EDT
Hi Paul,

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?

Thank you.
Comment 13 Mostafa Afgani 2007-11-17 08:00:47 EST
Hi Paul,

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.
Comment 14 Paul Wouters 2007-11-30 02:08:10 EST
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
suppose.
Comment 15 Fedora Update System 2007-12-03 06:49:41 EST
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.
Comment 16 Fedora Update System 2007-12-03 06:49:52 EST
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.
Comment 17 Bug Zapper 2008-04-03 23:26:47 EDT
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.
http://fedoraproject.org/wiki/LifeCycle/EOL

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
the change.

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:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

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
Comment 18 Bug Zapper 2008-05-06 12:11:52 EDT
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.
Comment 19 Paul Wouters 2008-05-06 12:20:57 EDT
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.
Comment 20 petrosyan 2008-05-06 16:04:04 EDT
Paul, in which Fedora releases is this bug still present?
Comment 21 Paul Wouters 2008-05-06 16:54:20 EDT
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.

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