[Bug 236228] net-mgmt/etherape: produces high graphics and cpu load, makes display freeze, dumps core

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236228

            Bug ID: 236228
           Summary: net-mgmt/etherape: produces high graphics and cpu
                    load, makes display freeze, dumps core
           Product: Ports & Packages
           Version: Latest
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: Individual Port(s)
          Assignee: woodsb02 at freebsd.org
          Reporter: d8zNeCFG at aon.at
          Assignee: woodsb02 at freebsd.org
             Flags: maintainer-feedback?(woodsb02 at freebsd.org)

Scenario:
- Machine A acting as a gateway to the internet, running mpd5 with PPPoE
(interface ng0)
- Machine B used as desktop
- Both machines FreeBSD 12.0 latest patchset (releng/12.0), latest ports
compiled using portmaster
- X server on machine B configured to accept remote connections
- $DISPLAY on machine A pointing to B:0
- An xterm/zsh is running on A being displayed on B
- 'etherape -i ng0 &' started on B (should display on A)

Result:
- The etherape window appears on B and starts drawing a few connections
- The display on B becomes sluggish
- One unit of load is added on B, obviously by the X server
- The connection to the xterm on A becomes sluggish

Scenario (continued):
- With great delay, I am able to enter the command 'kill %1' on A

Result:
- After a few seconds, the following appears on the xterm:

write(2) failed in write_all(): Broken pipe

** (etherape:41428): ERROR **: 21:34:51.424: Failed to send message to
packet-capture process

- A core dump starts to get written, ultimately reaching nearly 1.5 GB in size:

[0]# 
[1]  + trace trap (core dumped)  etherape -i ng0
[0]# ll *.core
-rw-------  1 root  wheel  1391161344 Mar  4 21:36 etherape.core
[0]# 

Notes:
- The program behaved normally before the upgrade to 0.9.18
- I have the impression that the program should be waiting for a second or so
before redrawing the screen but instead runs in a tight loop without any wait,
thereby spamming the X server and also the network between A and B.
- The same behavior occurs if I select another interface, including the
ethernet between A and B.

-- 
You are receiving this mail because:
You are the assignee for the bug.