mailing list archives
Re: Zenmap Crashing and CPU Utilisation hangs at 50%
From: David Fifield <david () bamsoftware com>
Date: Tue, 18 Jan 2011 11:08:39 -0800
On Tue, Jan 18, 2011 at 12:07:20PM +0000, Rob Nicholls wrote:
On Mon, 17 Jan 2011 12:31:13 -0800, David Fifield wrote:
I don't have a good workaround to suggest other than running the
in a terminal. (You can copy and paste the command line from
a -oX option to save the output, and then open the XML file in Zenmap
later.) Another thing you might try is changing this setting to
enable_highlight = True
I don't know how much the highlighting contributes to the
but it might be enough to allow your scan to finish.
It makes an incredibly huge difference to a quick test scan I
performed with --packet-trace against a single host (default ports).
It managed to display around 100 lines (rough estimate) before
Zenmap stopped responding (I gave up after a few minutes and killed
the process, I don't know whether waiting for hours would allow it
to catch up and get back to normal). Repeating the scan with
enable_highlight set to False allowed the default scan to complete
without any issues. I've just finished it with --packet-trace
against -p- and Zenmap just about coped okay (the output viewer's
scrollbar went mad and the application got very sluggish towards the
end), even though there were a staggering 132178 lines by the end.
The issue is most apparent with a fast/noisy scan (the quick test
scan with -T4 caused Zenmap to play up, but with -T2 it seemed to
cope better, althought it eventually stopped responding about 25% of
the way through the scan). I don't know whether the issue is purely
down to the highlighting taking too long or if the delay causes
something more important to go wrong.
I know the highlighting is pretty, but should we consider disabling
it by default if it's too easy to make Zenmap stop responding?
My guess is that the main problem is the O(n^2) output updating, and
that the highlighting only adds a large coefficient. But disabling
highlighting sounds reasonable as a stopgap until the output viewer is
It's also entirely possible that the pattern-matching highlighter is not
very efficient; if anyone cares to check, the code is in
zenmapGUI/NmapOutputViewer.py, and the regular expressions are stored in
Sent through the nmap-dev mailing list
Archived at http://seclists.org/nmap-dev/