[lsb-discuss] Checking Firefox for LSB-compliance
robert.schweikert at abaqus.com
Fri Apr 20 06:41:25 PDT 2007
OK, here is my current status:
I have reproduced the problem on x86_64 with the firefox-bin recently
downloaded from mozilla for version 22.214.171.124. 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.
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 are the values the structures hold:
Shared offset in Elf64_Ehdr
e_shoff Elf64_Off 0x2b4ac9288028 0x0028000700200034
P offset in Elf64_Ehdr
e_phoff Elf64_Off 0x2b4ac9288020 0x0000000000a0bb3c (10533692)
Address in ElfFile
addr caddr_t 0x0072e328 0x2b4ac9288000 -> "\177ELF\001\001\001"
The paddr member in ElfFile after executing line 24 in hdr.c
paddr Elf64_Phdr * 0x0072e340 0x2b4ac9c93b3c -> (Elf64_Phdr)
The shaddr member in ElfFile after executing line 28 in hdr.c
saddr Elf64_Shdr * 0x0072e338 0x282b51c9488034 -> <Bad address:
It looks to me that the e_shoff in the Elf64_Ehdr struct is already
hosed. But I have no clue how this struct is set up/initialized and how
this would happen.
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).
Jeff Licquia wrote:
> On Thu, 2007-04-19 at 11:58 -0400, Robert Schweikert wrote:
>> can you post the actual stack trace? While gdb will point to abort() in
>> glibc the trace (3 or 4 stack frames later) will show in which routine
>> the offending free() call is made.
> Here's the stack trace I was able to get:
> (gdb) bt
> #0 0xb7f40410 in ?? ()
> #1 0xbf8d5b80 in ?? ()
> #2 0x00000006 in ?? ()
> #3 0x000067b2 in ?? ()
> #4 0xb7e20811 in raise () from /lib/tls/i686/cmov/libc.so.6
> #5 0xb7e21fb9 in abort () from /lib/tls/i686/cmov/libc.so.6
> #6 0xb7e55d3a in __fsetlocking () from /lib/tls/i686/cmov/libc.so.6
> #7 0xb7e5e610 in free () from /lib/tls/i686/cmov/libc.so.6
> #8 0xb7e5f92f in malloc () from /lib/tls/i686/cmov/libc.so.6
> #9 0xb7e630c0 in strdup () from /lib/tls/i686/cmov/libc.so.6
> #10 0x0804b9e8 in output_purpose_start (activity=0, tpnumber=49,
> message=0xb72884dc "XSetInputFocus") at output.c:319
> #11 0x0804a4f5 in checksymbols (file=0x8225eb8, modules=223) at
> #12 0x0804a19f in main (argc=2, argv=0xbf8d8124) at appchk.c:388
> lsb-discuss mailing list
> lsb-discuss at lists.freestandards.org
Robert Schweikert MAY THE SOURCE BE WITH YOU
(Robert.Schweikert at abaqus.com) LINUX
Phone : 401-276-7190
FAX : 401-276-4408
More information about the lsb-discuss