Re: [Bug binutils/4110] Broken object file crashes nm

[Nick Clifton]

Hi Sami,

  Right, first of all, I have checked in the patch as it currently 
exists (patch.5).  We will be branching for release 2.18 at some point 
in the near future and I want to make sure that the error checking we 
have already developed gets into that release.  I added this ChangeLog 
entry:

bfd/ChangeLog
        PR binutils/4110
        * elf.c (IS_VALID_GROUP_SECTION_HEADER): New macro.
        (setup_group): Use it.  Report corrupt group section headers.
        (bfd_section_from_shdr): Use new macro.  Replace constant 4 with
        GRP_ENTRY_SIZE.  Cope with NULLs in the group section table.
        (elf_fake_section): Replace constant 4 with GRP_ENTRY_SIZE.

> Sorry for taking some time to reply. It seems I can't reproduce the SEGV 
> anymore myself (don't know what changed), but I do get a valgrind error. And I 
> also have a log of nm crashing twice on that input file. By the way now that I 
> test I also get the same Valgrind error with broken3.o and broken4.o. It seems 
> the uninitialized variable has to be still idx->shdr as probably was the case 
> with broken4.o, however I can't get that either to crash any more.

> ==15602== Conditional jump or move depends on uninitialised value(s)
> ==15602==    at 0x433A71: bfd_section_from_shdr (elf.c:2181)

> (gdb) print idx
> $1 = (Elf_Internal_Group *) 0x4d5c9f0
> (gdb) print *idx
> $2 = {shdr = 0x0, flags = 0}
> (gdb) l
> 2176              idx += n_elt;
> 2177              while (--n_elt != 0)
> 2178                {
> 2179                  --idx;
> 2180
> 2181                  if (idx->shdr != NULL
> 2182                      && (s = idx->shdr->bfd_section) != NULL
> 2183                      && elf_next_in_group (s) != NULL)
> 2184                    {
> 2185                      elf_next_in_group (hdr->bfd_section) = s;

Hmm, I do not see how the idx->shdr array can be uninitialized... I did 
find another place in elf.c where we assume that the group section 
contents will always be valid pointers, hence I am uploading another 
patch to fix that.  But I doubt if that will resolve the valgrind issue. 
 I think that we need a seg-faulting test case before we can proceed 
any further.

(Just as a guess, do you get a seg fault if you run any of the tests 
with the environment variable MALLOC_CHECK_ set to 2 ?  I tried, but 
they all ran OK).

Cheers
  Nick