Re: many scripts with output cause abort

[David Fifield <david () bamsoftware com>]

On Tue, Mar 17, 2009 at 02:26:42AM +0000, Brandon Enright wrote:
> > > I've run into a problem that causes an ABORT for all the branches
> > > I'm doing performance testing on for NSE. The problem appears to be
> > > unrelated to NSE except having huge numbers of scripts with output
> > > seems to cause it. Sometime while the output table is being printed
> > > the code will mess the heap up. I've attached example output and the
> > > shell script that creates the scripts.
> >
> > This is the first time I've looked at this code so I still need to
> > figure out what is broken but so far this is what I have.  Ultimately
> > the problem is in NmapOutputTable::printableSize().
> >
> > The issue is that maxsz is not computed properly in the
> > NmapOutputTable::printableSize() routine.  I haven't figured out what
> > printtableSize() is supposed to be doing because I'm not sure I
> > understand what a cell is supposed to be.
> >
> > If printtableSize() is doing what I think it is then in most cases it
> > would cause *way* to much memory to be allocated.  In this case
> > obviously it wasn't enough.
> >
> > A better approach may be to dynamically reallocate memory in
> > NmapOutputTable::printableTable() whenever a cell string + space
> > padding is too much to fit.  If we started off at 1k and doubled the
> > size sent to realloc() every time we ran out we'd waste quite a bit
> > less memory in the general case and probably wouldn't have to worry
> > about making printtableSize() correct.
>
> I have located the problem.  printableSize() was calculating the max
> row length as the size of the max full row string length and not taking
> into account that printableTable() has to add a "\n" to the end of
> every row.
>
> I confirmed that in the above case, the max rowlen was calculated at 37
> but in most cases p was actually increased by 38 because of the
> newline.  This bug will only show up when nearly every single row being
> printed is exactly at the max row length.  Normally several bytes would
> be saved on most rows that would more than make up for the extra \n on
> the longest row.
>
> Attached is the patch that fixes this problem.

Please do commit this patch while we are looking at your other
NmapOutputTable patch. Then Patrick can continue with his performance
testing.

David Fifield

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