Re: [patch] Fix for PR gdb/10819

[Pedro Alves <pedro at codesourcery dot com>]

On Thursday 22 October 2009 07:14:21, Paul Pluzhnikov wrote:
> Comment added.

> +  if (cie_table->num_entries == 0)
> +    {
> +      /* On Solaris 8 bsearch may call comparison function even when given
> +        an empty table.  As a work around, don't call bsearch under these
> +        conditions.  */
> +      return NULL;
> +    }

>Apparently calling bsearch on a table with zero elements is unsafe on Solaris
>8.

FTR, so that this is archived, see:
 http://cvs.opensolaris.org/source/xref/pef/phase_I/usr/src/lib/libbc/libc/gen/common/bsearch.c

     43 	int two_width = width + width;
     44 	POINTER last = base + width * (nel - 1); /* Last element in table */
     45 
     46 	while (last >= base) {

The issue happens because you're passing a NULL BASE (your ENTRIES), so
LAST wraps around, and the while loop enters.  That bsearch assumes
BASE is a pointer into a valid object, which seems valid given
that BASE should point at an array of NEL objects.  You don't have
a table with zero elements, you have no table at all.  Note that
the solaris man page doesn't explicitly specify that when NEL is 0, the
compare function should not be called, no matter what.  opengroup.org
does, but that probably post dates the original bsearch appearences.

This seems to have been considered in more recent sources:
 http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/common/util/bsearch.c

It is quite possible that other unix hosts have the same
valid-object assumption, if not by chance, because it's quite
possible that they've inherited the exact same bsearch.c
implementation.  I see that netbsd's implementation even
asserts (in devel builds only it seems) that base is not null.


There's another bsearch call in dwarf2-frame.c and another one
in objfiles.c (all recent and yours, it seems :-)).  Do they need
attention to the base==NULL or number-elements==0 case as well?

- 
Pedro Alves