Re: Zenmap Crashing and CPU Utilisation hangs at 50%

[David Fifield <david () bamsoftware com>]

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
> > command
> > in a terminal. (You can copy and paste the command line from
> > Zenmap, add
> > 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
> > False in
> > zenmap.conf:
> >
> > [output_highlight]
> > enable_highlight = True
> >
> > I don't know how much the highlighting contributes to the
> > inefficiency,
> > 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
fixed.

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
zenmap.conf.

David Fifield
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/