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
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils