dump_syms creates invalid symbol files (lines with empty function names)

[GoogleCodeExporter]

What steps will reproduce the problem?

dump_syms /lib/libc-2.5.so

What is the expected output? What do you see instead?

The symbol file can't be read by minidump_stackwalk. A FUNC line (7456 on 
rhel5.5) doesn't contain the function name.

Here is the problematic line :
FUNC 275e0 3b 0 __hash_string
275e0 6 29 590
...
27616 5 47 590
FUNC 27620 ab 0
27620 14 86 393
...
276c3 8 111 393
FUNC 276d0 80 0 catclose
276d0 1a 117 393
276ea 5 121 393

File 393 is :
FILE 393 catgets.c

What version of the product are you using? 

trunk, r753

On what operating system?

$  cat /etc/redhat-release 
Red Hat Enterprise Linux Client release 5.5 (Tikanga)
$ uname -m 
i686

Bare release from DVD, without any security patch applied.

Please provide any additional information below.

The attached patch fix the problem.

Original issue reported on code.google.com by tonton1...@gmail.com on 13 Jan 2011 at 5:41

Attachments:

• do-not-output-empty-functions.patch

[GoogleCodeExporter]

Presumably it would be more interesting to find out what is causing the symbol 
dumping code to produce that FUNC record without a name.

Original comment by ted.mielczarek on 7 Mar 2011 at 1:13

[GoogleCodeExporter]

Well, yes. But I know nothing about DWARF ...

It seems that the function having problems is catgets :
# grep catgets */*
BD56F36E5BCC098768E2E1905DCB65590/libc-2.5.so.sym:FILE 393 catgets.c
E383BDB3936E8FB51D132700084794530/libc-2.5.so.sym:FILE 393 catgets.c
# nm /lib/libc-2.5.so | grep catgets
00027620 T catgets

The source for catgets.c can be found here :
http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=catgets/catgets.c;hb=88cc6
1e84e8e75e6e91b1a2e51147aeb63712ff8

Nothing special in the definition nor the declaration ...

Original comment by tonton1...@gmail.com on 7 Mar 2011 at 1:41

[GoogleCodeExporter]

If I could get a copy of the given libc-2.5.so, that would help me reproduce 
this. GLIBC is GPL, so it should be fine to put up a copy for me somewhere.

Original comment by jimbla...@gmail.com on 8 Mar 2011 at 2:12

[GoogleCodeExporter]

$ dump_syms lib/libc-2.5.so usr/lib/debug/lib

Original comment by tonton1...@gmail.com on 8 Mar 2011 at 2:30

Attachments:

• glibc-rhel5.5.tar.gz

[GoogleCodeExporter]

Thanks; I can reproduce this now. The DWARF information is incorrect --- 
perhaps there is a bug in the linker or compiler? --- but dump_syms should 
never generate invalid symbol files, so there's still a breakpad bug.

The bad FUNC line generated looks like this, as you say:
FUNC 27620 ab 0 

The DWARF entry for that function looks like this:

 <1><348ee>: Abbrev Number: 17 (DW_TAG_subprogram)
    <348ef>   DW_AT_sibling     : <0x3496c> 
    <348f3>   DW_AT_external    : 1 
    <348f4>   DW_AT_name        : (indirect string, offset: 0x5ae0):    
    <348f8>   DW_AT_decl_file   : 1 
    <348f9>   DW_AT_decl_line   : 86    
    <348fa>   DW_AT_prototyped  : 1 
    <348fb>   DW_AT_type        : <0x34761> 
    <348ff>   DW_AT_low_pc      : 0x27620   
    <34903>   DW_AT_high_pc     : 0x276cb   
    <34907>   DW_AT_frame_base  : 0x12564   (location list)

So you can see that the debug information indeed points to a null string as the 
name of the function. That specific portion of the .debug_str section looks 
like this:

...
  [  5aa0]  catclose
  [  5aa9]  name_ptr
  [  5ab2]  /usr/src/debug/glibc-2.5-20061008T1257/catgets
  [  5ae1]  atgets
  [  5ae8]  file_size
  [  5af2]  plane_depth
...

The DW_AT_name attribute is weird, because it's pointing to the null character 
at the end of the 5ab2 entry (the filename), not at the next entry --- and the 
next entry should probably be "catgets", not "atgets". So I think this was 
generated by a buggy linker, or some post-processing tool botched something.

Working on a fix.

Original comment by jimbla...@gmail.com on 8 Mar 2011 at 8:08

[GoogleCodeExporter]

Posted patch:
http://breakpad.appspot.com/270001

Original comment by jimbla...@gmail.com on 8 Mar 2011 at 9:48

[GoogleCodeExporter]

Original comment by jimbla...@gmail.com on 8 Mar 2011 at 9:48

• Changed state: Started

[GoogleCodeExporter]

Should be fixed in r779.

Original comment by jimbla...@gmail.com on 11 Mar 2011 at 10:17

• Changed state: Fixed

[GoogleCodeExporter]

In r779, at the last moment, I added a default call count expectation for
the UnnamedFunction warning to the CUFixtureBase constructor, but didn't
re-run the tests.

The patch here adjusts all affected tests:
http://breakpad.appspot.com/272001

Original comment by jimbla...@gmail.com on 14 Mar 2011 at 5:08

[GoogleCodeExporter]

Tests fixed in r782.

Original comment by jimbla...@gmail.com on 15 Mar 2011 at 7:24