This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
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