[lsb-discuss] Checking Firefox for LSB-compliance
Robert Schweikert
robert.schweikert at abaqus.com
Fri Apr 20 17:51:23 PDT 2007
Jeff,
Touche, was testing the 32 bit firefox binary with the 64 bit appchk. We
probably should safeguard against that crash with a check.
I'll get a consistent check going next week.
Robert
Jeff Licquia wrote:
> On Fri, 2007-04-20 at 09:41 -0400, Robert Schweikert wrote:
>
>> I have reproduced the problem on x86_64 with the firefox-bin recently
>> downloaded from mozilla for version 2.0.0.3. The good news is appcheck
>> still dumps, the bad new is it dumps in a different place as compared to
>> the stack trace posted by Jeff.
>>
>> However, the dumps may be related.
>>
>
> Fun.
>
>
>> The rot cause for the dump is a bad address calculation hdr.c on line
>> 28. Here we add the address stored in the ElfFile struct in the addr
>> member (file1->addr) and the address we find in the Elf64_Ehdr struct
>> for the shared offset (e_shoff) (hdr1->e_shoff). While the earlier
>> calculation for paddr worked (3 lines previous) the shared off set
>> calculation fails. THerefore we are setting the saddr member in the
>> ElfFile struct to garbage. Once this is accessed things of course blow up.
>>
>> I don't know enough about ELF to keep debugging this effectively on my own.
>>
>
> Here's the offending code:
>
> if( hdr1->e_shoff ) {
> file1->saddr=(Elf_Shdr *)((caddr_t)file1->addr+hdr1->e_shoff);
> file1->numsh = hdr1->e_shnum;
> }
>
> "file1" is the ElfFile * in question. It has an "addr" member, which is
> set to point to an mmap() of the ELF file header. "hdr1" is actually
> set to file1->addr, typecase to Elf_Phdr *.
>
> So if e_shoff is coming through incorrectly, that could mean that appchk
> is misreading the ELF header from the Mozilla executable.
>
> One possible reason for that is if we're checking an ia32 executable
> with an x86_64 appchk, or vice versa. What architecture did the Mozilla
> binary represent itself as?
>
>
>> The stack trace posted by Jeff points to a "garbage pointer" culprit.
>> The call that actually causes the dump in (I presume IA32) the original
>> post is the strdup() call. strdup of course allocates and frees memory.
>> Looks to me we are passing garbage to strdup(). This garbage could be
>> triggered by a similar miscalculation of the saddr, by luck we don't
>> blow up on the other platform as early as we do on x86_64 (my best guess).
>>
>
> If we're passing garbage to strdup() in my trace, then I can't figure
> out where the garbage is. Here's the full function being called:
>
> void output_purpose_start(unsigned int activity, unsigned int tpnumber,
> const char *message)
> {
> current_tpnum = tpnumber;
> if ((message != NULL) && (strlen(message) > 0))
> current_purpose = strdup(message);
> else
> current_purpose = NULL;
> }
>
> current_purpose and current_tpnum are globals. The "message" parameter
> is reported to be OK by gdb (the backtrace output lists its contents as
> "XSetInputFocus").
>
> On the other hand, here's the code which calls that function:
>
> symbol_name = ElfGetStringIndex(file, syms1[i].st_name,
> file->dynsymhdr->sh_link);
>
> PURPOSE_START(tetj_activity_count, tetj_tp_count, symbol_name);
>
> (PURPOSE_START is a macro which, in this case, evaluates to the above
> function.)
>
> So, yes, the ultimate source for that string is an ElfFile *. Which,
> given Robert's evaluation, is very suspect. I wonder if we might be
> using the memory after freeing it, or something.
>
> Incidentally, if the program is run under valgrind, it does not throw a
> SIGABRT. Ditto for MALLOC_CHECK_ (even at 2, which should immediately
> abort at these kinds of crashes). As far as I can tell, building with
> mtrace() and running with MALLOC_TRACE on does not seem to make a
> difference, although it doesn't seem to tell us anything interesting
> when it does crash.
>
> _______________________________________________
> lsb-discuss mailing list
> lsb-discuss at lists.freestandards.org
> http://lists.freestandards.org/mailman/listinfo/lsb-discuss
>
>
--
Robert Schweikert MAY THE SOURCE BE WITH YOU
(Robert.Schweikert at abaqus.com) LINUX
ABAQUS Inc.
Phone: 401-727-4200
FAX: 401-727-4208
More information about the lsb-discuss
mailing list