Re: [RFA/Darwin v2] Avoid a crash when working on OSO without symbol.

[Simon Marchi <simon dot marchi at ericsson dot com>]

On 2018-03-01 06:38 AM, Xavier Roirand wrote:
> From: Tristan Gingold <gingold@adacore.com>
> 
> When reading OSO file without symbol, macho_add_oso_symfile
> may crash when creating empty hash table.
> 
> This patch fix this.
> 
> gdb/ChangeLog: (Tristan Gingold <gingold@adacore.com>)
> 
> 	* machoread.c (macho_add_oso_symfile): Handle case
> 	when OSO does not have symbol.
> ---
>  gdb/ChangeLog   | 6 ++++++
>  gdb/machoread.c | 5 +++++
>  2 files changed, 11 insertions(+)
> 
> diff --git a/gdb/ChangeLog b/gdb/ChangeLog
> index 59265157b4..050376a696 100644
> --- a/gdb/ChangeLog
> +++ b/gdb/ChangeLog
> @@ -1,3 +1,9 @@
> +2018-02-27  Tristan Gingold  <gingold@adacore.com>
> +
> +	Pushed by Xavier Roirand <roirand@adacore.com>
> +	* machoread.c (macho_add_oso_symfile): Handle case when
> +	OSO does not have symbol.
> +
>  2018-02-28  Sergio Durigan Junior  <sergiodj@redhat.com>
>  	    Simon Marchi  <simon.marchi@polymtl.ca>
>  
> diff --git a/gdb/machoread.c b/gdb/machoread.c
> index b270675d61..b00ef133a9 100644
> --- a/gdb/machoread.c
> +++ b/gdb/machoread.c
> @@ -579,6 +579,11 @@ macho_add_oso_symfile (oso_el *oso, const gdb_bfd_ref_ptr &abfd,
>                  {
>                    struct macho_sym_hash_entry *ent;
>  
> +		  /* Nothing to do if there is no symbol (and avoid a crash
> +		     while creating an empty hash table).  */
> +		  if (oso->nbr_syms == 0)
> +		    continue;
> +
>                    ent = (struct macho_sym_hash_entry *)
>                      bfd_hash_lookup (&table, sym->name, FALSE, FALSE);
>                    if (ent != NULL)
> 

Hi Xavier and Tristan,

If you are able to reproduce the crash yourself, could you give just
a bit more details?  I have no context, but I don't think it should
be a problem to do a lookup on an empty hash table (it shouldn't crash).

Maybe the problem is that we call bfd_hash_table_init_n with size == 0,
which puts the table in a wrong state and makes further lookups crash?
If so, I think it would better to fix the call to bfd_hash_table_init_n
to avoid passing 0.  Otherwise, bfd_hash_table_init_n could check for
size == 0 (and use size = 1 instead in that case), but that would
have to be contributed to the BFD project (on the binutils mailing list).

Simon