Re: nmap crash -- NmapOutputTable.cc:153: void NmapOutputTable::addItem(unsigned int, unsigned int, bool, const char*, int): Assertion `row < numRows' failed.

[David Fifield <david () bamsoftware com>]

On Tue, Jan 19, 2010 at 04:40:19PM -0500, Jon Kibler wrote:
> David Fifield wrote:
> > On Mon, Jan 18, 2010 at 01:01:32PM -0500, Jon Kibler wrote:
> > > Jon Kibler wrote:
> > > > I am having nmap crash and getting empty files for output:
> > > >
> > > > > # nmap -sS -sV -sU -sC -oA cts -O -p- -T4 --min-rtt-timeout=1 --max-rtt-timeout=8 --initial-rtt-timeout=4 
> > > > > --min-parallelism=64 --max-parallelism=128 --max-retries=3 --version-light 10.22.149.132
> > > > > WARNING: You specified a round-trip time timeout (8 ms) that is EXTRAORDINARILY SMALL.  Accuracy may suffer.
> > > > > Starting Nmap 5.10BETA2 ( http://nmap.org ) at 2010-01-16 21:48 GMT
> > > > > Nmap scan report for 10.22.149.132
> > > > > Host is up (0.00042s latency).
> > > > > Not shown: 65533 open|filtered ports, 65526 filtered ports
> > > > > nmap: NmapOutputTable.cc:153: void NmapOutputTable::addItem(unsigned int, unsigned int, bool, const char*, int): 
> > > > > Assertion `row < numRows' failed.
> > > > > Aborted
> > > I hate to respond to my own email... but I notice that this had been a
> > > problem that was previously fixed in 4.01.
> > >
> > > I have rerun the scan with -d, and it doesn't seem to tell anything not
> > > already known (attaching log... if it passes filter).
> > >
> > > What can I do to help get this debugged?
> >
> > See if you can simplify the command line and still get the crash. For
> > example, does it still happen if you don't use -sV? What if you narrow
> > the port range with -p? The most likely culprits are the options that
> > add rows to the ports table: -sS -sU -sC. If you can rule any of those
> > out it would help.
>
> I was able to narrow down the problem. I got it so that it only occurs
> on a sU+sV on a relatively small number of ports. I have included pcap
> files (tshark) of the successful and failed scans, as well as nmap debug
> logs.
>
> More specifically...
> # fails
> $ nmap -sV -sU -d -p160-688 -T4  --min-rtt-timeout=1 --max-rtt-timeout=8
> - --initial-rtt-timeout=4 --min-parallelism=64 --max-parallelism=128
> - --max-retries=3 --version-light 10.22.149.132 >
> nmap-sU-sV-p160-688.log 2>&1
>
> # works
> $ nmap -sV -sU -d -p160-672 -T4  --min-rtt-timeout=1 --max-rtt-timeout=8
> - --initial-rtt-timeout=4 --min-parallelism=64 --max-parallelism=128
> - --max-retries=3 --version-light 10.22.149.132 >
> nmap-sU-sV-p160-672.log 2>&1

Thank you for the logs. This is strange. The target sent back the same
responses in both packet captures--none of the additional ports 673-688
should have been able to make a difference. Also strange is this:

> $ nmap -sV -sU -d -p160-672 -T4  --min-rtt-timeout=1 --max-rtt-timeout=8 --initial-rtt-timeout=4 --min-parallelism=64 
> --max-parallelism=128 --max-retries=3 --version-light 10.22.149.132
> Host is up, received arp-response (0.00050s latency).
> Scanned at 2010-01-19 21:23:36 GMT for 86s
> PORT    STATE   SERVICE         REASON           VERSION
> 160/udp unknown sgmp-traps      unknown-response
> 161/udp open    snmp            udp-response     net-snmp
> 162/udp unknown snmptrap        unknown-response
> 163/udp unknown cmip-man        unknown-response

STATE=unknown shouldn't happen. Same with REASON=unknown-response. This
may well be a bug in the memory reduction changes I made. Every port
that didn't get a response shares a single Port object, so an error
could manifest itself this way.

I can't reproduce this, though. Your scan that failed showed that the
ports were properly detected open|filtered and not unknown:

> $ nmap -sV -sU -d -p160-688 -T4  --min-rtt-timeout=1 --max-rtt-timeout=8 --initial-rtt-timeout=4 --min-parallelism=64 
> --max-parallelism=128 --max-retries=3 --version-light 10.22.149.132
> Nmap scan report for 10.22.149.132
> nmap: NmapOutputTable.cc:153: void NmapOutputTable::addItem(unsigned int, unsigned int, bool, const char*, int): 
> Assertion `row < numRows' failed.
> Host is up, received arp-response (0.00062s latency).
> Scanned at 2010-01-19 21:19:04 GMT for 92s
> Not shown: 528 open|filtered ports

Perhaps it does have something to do with the timing options. Possibly
some code is not getting a chance to run. Try your above scans again,
only this time use -T3 and the default timing and parallelism. Do each
scan three times to see if the results are consistent.

If the error only happens with short timeouts and high parallelism,
we'll know where to start looking next.

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