This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gdb.mi/mi-cli.exp failures


On Tue, Apr 01, 2003 at 11:22:09AM -0500, Andrew Cagney wrote:
> 
> >On what target - I don't see these...
> 
> RH 7.2 i386, PPC and d10v also show a jump in failures but I've not 
> checked that they are 100% identical.

Bizarre, I can not reproduce this.

> >This looks like a crash in the same function that changed interface...
> >perhaps the memory leak fix for simple.c was wrong, although I can't
> 
> Applying the simple.c change causes the problem.
> 
> Index: simple.c
> ===================================================================
> RCS file: /cvs/src/src/bfd/simple.c,v
> retrieving revision 1.5
> retrieving revision 1.6
> diff -u -r1.5 -r1.6
> --- simple.c    30 Nov 2002 08:39:40 -0000      1.5
> +++ simple.c    31 Mar 2003 18:13:25 -0000      1.6
> @@ -1,5 +1,5 @@
>  /* simple.c -- BFD simple client routines
> -   Copyright 2002
> +   Copyright 2002, 2003
>     Free Software Foundation, Inc.
>     Contributed by MontaVista Software, Inc.
> 
> @@ -135,7 +135,7 @@
>    struct bfd_link_order link_order;
>    struct bfd_link_callbacks callbacks;
>    bfd_byte *contents, *data;
> -  int storage_needed, number_of_symbols;
> +  int storage_needed;
>    asymbol **symbol_table;
> 
>    if (! (sec->flags & SEC_RELOC))
> @@ -187,7 +187,7 @@
> 
>    storage_needed = bfd_get_symtab_upper_bound (abfd);
>    symbol_table = (asymbol **) bfd_malloc (storage_needed);
> -  number_of_symbols = bfd_canonicalize_symtab (abfd, symbol_table);
> +  bfd_canonicalize_symtab (abfd, symbol_table);
> 
>    contents = bfd_get_relocated_section_contents (abfd,
>                                                  &link_info,
> @@ -208,5 +208,6 @@
> 
>    bfd_link_hash_table_free (abfd, link_info.hash);
> 
> +  free (symbol_table);
>    return contents;
>  }
> 
> A guess is that something still has a reference to the symbab.

OK, that's pretty strange.  It must be cached in the BFD somewhere.  Do
you have valgrind available?  It will identify the access to a freed
resource.

I can't find the problem here, and reading the code I can not find the
reference.

> >quite see why.  By the way, adding or removing the NULL at the end is
> >all that GDB needs to do to work with both interfaces.
> 
> Doesn't work.  To test my patches, I've had to adjust upwards the 
> expected failure list.

Don't follow... if you add/remove the NULL so that GDB compiles, it
should work fine.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]