[lsb-discuss] Checking Firefox for LSB-compliance

Robert Schweikert 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 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.

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 
(11259029135294516)

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: 
0x282b51c9488034> (Elf64_Shdr)

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).

Robert

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
> symbols.c:33
> #12 0x0804a19f in main (argc=2, argv=0xbf8d8124) at appchk.c:388
>
> _______________________________________________
> 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-276-7190
FAX : 401-276-4408




More information about the lsb-discuss mailing list