[lsb-discuss] Checking Firefox for LSB-compliance

[Robert Schweikert]

Here is a more detailed description of the symptom, not that I can make 
any sense of this now.

When we first call PURPOSE_START, i.e. output_purpose_start in output.c 
on line 28 in check_file.c we make the call with a string literal 
("check file details").  In output_purpose_start we then call strdup and 
assign the result of strdup to the char* current_purpose. Based on the 
way strdup is supposed to work the result should be an allocated ptr. 
This pointer is then freed in output_purpose_end when called from line 
53 in check_file.c

At some point later strdup happens to try to allocate memory at the same 
address as was allocated when we duplicated the literal "check file 
details". This happens to occur when we  try to duplicate 
"XSetInputFocus".  But this time the code blows up. In between strdup 
was called many times with different addresses being produced.

Here are some debug information I printed:

Binary ../firefox/firefox-bin:
RJS open elf file: '../firefox/firefox-bin'
RJS elffileptr: 8223ed0
RJS free current_purpose: 'check file details' at 08223fc0
RJS free current_purpose: 'Check header id EI_MAG0 is ELFMAG0' at 082240b0
RJS free current_purpose: 'Check header id EI_MAG1 is ELFMAG1' at 082240b0
RJS free current_purpose: 'Check header id EI_MAG2 is ELFMAG2' at 082240b0
RJS free current_purpose: 'Check header id EI_MAG3 is ELFMAG3' at 082240b0

The print statement indicates the address of the pointer we are freeing. 
Note that for the 'Check....' the addresses are all the same, i.e. 
strdup allocated memory for these strings in the same place and there is 
no problem. For any of these calls output_purpose_start is also called 
with a literal.

At some point later however we end up calling output_purpose_start and 
strdup tries to get memory at the same address as was used when 'check 
file details' was duplicated and then we crash:

*** glibc detected *** malloc(): memory corruption (fast): 0x08223fc0 ***

Thus my guess is that we stepped on something somewhere along the way. 
I'll try and extract some more information but am not sure how much time 
I will have for this the rest of the day.

Enjoy,
Robert

Sam Hart wrote:
> Alright, to add weirdness to weirdness, for giggles I built Firefox
> with the lsb dev kit and re-ran the test. No SIGABRT errors.
>
> lsbappchk completes with a full report of all libraries not found in LSB.
>
> At the moment, the list is meaningless as I need to cull through the
> ones that are self-referential inside the Mozilla build directory, but
> the fact that I'm not getting any errors from lsbappchk is strange.
>
> _______________________________________________
> 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