Segfault when reading a debug-only file.

[Kurt Roeckx]

Hi,

It seems that there is a problem with reading files that only
have debug information.  The file with debug info is split in
a file without debug info and one with only debug info.  Such
a file still contains the section headers but not the actual
data the belongs to that section.  The type has been changed
from PROGBITS to NOBITS.

Because it's set to NOBITS, nothing gets read from the file
(in __libelf_set_rawdata_wrlock()).  In relocate_section()
it seems to assume that the section was loaded in memory, but
it isn't.  tdata->d_buf is NULL.  This later results in
a segfault.

This can be reproduced with "eu-readelf -a tst.debug".

I've attached a small test case which source was:
int main(){return 0;}

I then used:
gcc tst.c -o tst -g
objcopy --only-keep-debug tst tst.debug

elflint produces a whole bunch of warnings on that file,
mostly saying "wrong type: expected PROGBITS, is NOBITS"

There is also a little more information and an other testcase
at http://bugs.debian.org/556133


Kurt

[Ulrich Drepper]

On 11/14/2009 11:59 AM, Kurt Roeckx wrote:
>  elflint produces a whole bunch of warnings on that file,
>  mostly saying "wrong type: expected PROGBITS, is NOBITS" 
That's no ELF file.  Don't run elflint on it.

-- 
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖

[Jay Vaughan]

Ulrich Drepper wrote:
>  That's no ELF file.  Don't run elflint on it. 
It has an ELF header.  It was created through the ELF-creating pipeline.  It was 
manipulated through tools using libelf.  It contains ELF sections.

It *is* an ELF file.  Fix the bug, if you are capable of doing so, or ignore it if you are

not.


-- 
;
--
Jay Vaughan
jay.vaughan(a)thalesgroup.com

[Ulrich Drepper]

On 11/16/2009 12:22 AM, Jay Vaughan wrote:
>  It *is* an ELF file. 
Wow, you know so much about this.  It must be that you wrote all that 
code.  Oh wait, no, me thinks this is not the case.  It was all done by 
my collegues and particularly myself.  So when I say it's not an ELF 
file then I rather trust that rather than the opinion of some random 
guy.  The file might have an ELF header but the format violates 
everything about the ELF file format and therefore is no ELF file.

-- 
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖

[Jay Vaughan]

Ulrich Drepper wrote:
>  On 11/16/2009 12:22 AM, Jay Vaughan wrote:
> > It *is* an ELF file.
>  
>  Wow, you know so much about this.  It must be that you wrote all that 
>  code.   
No, I just ran a standard tool, perhaps you've heard of it, its called 'file',
and it
tells you what type of file a file is, based on the files signature.

The tst.debug file is ELF because it has an ELF signature, you see.  It contains ELF
sections.  It has no other purpose than to exist in the ELF ecosystem.  It started out as
a nice pretty ELF, then it got processed by a buggy tool that deals with ELF objects
exclusively, and now .. its become an ELF file that has revealed an un-handled case on
the
part of the programmers of those tools.

You might not like to think of a lobotomized person as a person, but I do.  This
lobotomized ELF is still ELF to libelf ..

>  Oh wait, no, me thinks this is not the case.  It was all done by 
>  my collegues and particularly myself.   
Which is why its so amusing that you run away from problems instead of solve them. 
"This
is not an ELF file, thus don't run elflint on it" == "I can't handle the
complexity of
this problem, nor do I appreciate the ill light it reflects on me as "The
Expert", so go
away or I will insult you a second time".

>  So when I say it's not an ELF 
>  file then I rather trust that rather than the opinion of some random 
>  guy.   
Your authority on this issue doesn't impress me, frankly, especially when you say
"This is
not an ELF file, thus don't run elflint on it", even after the file had no other
way of
coming into existence other than through libelf itself.  Your authority, actually,
doesn't
impress me anyway, but if you say that your ELF expertise results in ELF files that are
not really ELF files, then your buggy software is crap.

It *is* an ELF file, just not a very good or useful one.  But then, the ELF spec does not
state that the contents must be good or useful.

> The file might have an ELF header but the format violates 
>  everything about the ELF file format and therefore is no ELF file. 
The ELF format is not in any way violated, by the absence of .text or PROGBIT-marked
sections.  Nowhere in the ELF spec does it say that a proper ELF file *has* to have these
sections.  Unless you're reading a magical Ulrich-Drepper version of the spec, in
which
case you can happily continue to live in ignorance of the real world while we real people
attempt to deal with your buggy software.

Fix your bugs, Ulrich.  Have a hug too, while you're at it.

Oh, wait:

>  I've made eu-readelf handle SHT_NOBITS sections gracefully for -p
> and -a as
>  it already did for -x. 
Looks like someone already cleaned up your mess for you, Mr ELF Expert.


-- 
;
--
Jay Vaughan
jay.vaughan(a)thalesgroup.com

[Roland McGrath]

I've made eu-readelf handle SHT_NOBITS sections gracefully for -p and -a as
it already did for -x.


Thanks,
Roland

[Kurt Roeckx]

On Mon, Nov 16, 2009 at 01:52:13AM -0800, Roland McGrath wrote:
>  I've made eu-readelf handle SHT_NOBITS sections gracefully for -p
> and -a as
>  it already did for -x. 
The problem doesn't only happen with eu-readelf.  It was just an
easy way for me to reproduce it.  The original submitter of
the bug was using systemtap.

eu-readelf also still segfaults on the original file, on which
it segfaults much earlier.  I might have send a bad example
file.  I've attached the original file for the bug report.


Kurt

[Roland McGrath]

I fixed the remaining crash.

Thanks,
Roland