914293 - |ValueError: invalid literal for int() with base 16: ''| during configure step of all ASAN builds

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Ryan VanderMeulen [:RyanVM]]

This shows up in all ASAN builds. It doesn't show up in regular opt/debug builds.

https://tbpl.mozilla.org/php/getParsedLog.php?id=27588029&tree=B2g-Inbound

Linux x86-64 b2g-inbound asan build on 2013-09-09 09:41:59 PDT for push 9edc229b7d09
slave: bld-linux64-ec2-354

checking whether removing dead symbols breaks debugging... Traceback (most recent call last):
  File "/builds/slave/b2g-in-l64-asan-00000000000000/build/build/autoconf/check_debug_ranges.py", line 60, in <module>
    print main(*sys.argv[1:])
  File "/builds/slave/b2g-in-l64-asan-00000000000000/build/build/autoconf/check_debug_ranges.py", line 52, in main
    range = get_range_for(compilation_unit, debug_info[0])
  File "/builds/slave/b2g-in-l64-asan-00000000000000/build/build/autoconf/check_debug_ranges.py", line 23, in get_range_for
    return int(ranges, 16)
ValueError: invalid literal for int() with base 16: ''
yes

Comment 1

[(not currently active) Ted Mielczarek]

This is here:
http://mxr.mozilla.org/mozilla-central/source/build/autoconf/check_debug_ranges.py#23

I don't know if this stuff even matters on ASAN builds, maybe we could just skip it there?

Comment 2

[Nathan Froyd [:froydnj]]

Guessing clang uses .debug_aranges, which the script doesn't check for?

Presumably ASan uses the debug information for displaying information about errors, though.  So it would be good to make sure that it's as correct as possible.

Comment 3

[Christian Holler (:decoder)]

(In reply to Nathan Froyd (:froydnj) from comment #2)
> Presumably ASan uses the debug information for displaying information about
> errors, though.  So it would be good to make sure that it's as correct as
> possible.

That's right. What do we do for OSX debug builds, since they're also clang builds?

Comment 4

[Nathan Froyd [:froydnj]]

(In reply to Christian Holler (:decoder) from comment #3)
> (In reply to Nathan Froyd (:froydnj) from comment #2)
> > Presumably ASan uses the debug information for displaying information about
> > errors, though.  So it would be good to make sure that it's as correct as
> > possible.
> 
> That's right. What do we do for OSX debug builds, since they're also clang
> builds?

We don't use GNU ld on OS X, so this bit of code that calls check_debug_ranges.py:

http://mxr.mozilla.org/mozilla-central/source/build/autoconf/compiler-opts.m4#270

never gets called.

Comment 5

[Nathan Froyd [:froydnj]]

Ideally this try will have some debugging information in the log:

https://tbpl.mozilla.org/?tree=Try&rev=9551446a0b3c

Comment 6

[Nathan Froyd [:froydnj]]

Attachment: ensure check_debug_ranges.py can cope with a nonexistant DW_AT_ranges

The problem is that we're given:

...
 <0><1a39e>: Abbrev Number: 1 (DW_TAG_compile_unit)
    <1a39f>   DW_AT_producer    : (indirect string, offset: 0x0): clang version 3.4 (trunk 185949)      
    <1a3a3>   DW_AT_language    : 12        (ANSI C99)
    <1a3a5>   DW_AT_name        : (indirect string, offset: 0x58be): conftest.c 
    <1a3a9>   DW_AT_low_pc      : 0x0       
    <1a3b1>   DW_AT_stmt_list   : 0xd669    
    <1a3b5>   DW_AT_comp_dir    : (indirect string, offset: 0x58c9): /builds/slave/try-l64-asan-00000000000000000/build/obj-firefox 
 <1><1a3b9>: Abbrev Number: 2 (DW_TAG_subprogram)
...

and the script expects that we will find DW_AT_ranges within DW_TAG_compile_unit.
That's not a good assumption.  Make sure that we have accumulated some range
information before trying to parse it.

We should really upgrade binutils on the build servers; it's complaining about unknown
DWARF bits...

Comment 7

[Mike Hommey [:glandium]]

Comment on attachment 802643 [details] [diff] [review]
ensure check_debug_ranges.py can cope with a nonexistant DW_AT_ranges

Review of attachment 802643 [details] [diff] [review]:
-----------------------------------------------------------------

I guess this results in the asan builds displaying:
Check whether removing dead symbols breaks debugging... no
?

::: js/src/build/autoconf/check_debug_ranges.py
@@ +18,5 @@
>      for nfo in debug_info.splitlines():
>          if 'DW_TAG_compile_unit' in nfo:
>              search_cu = True
>          elif 'DW_TAG_' in nfo or not nfo.strip():
> +            if name == compilation_unit and ranges != '':

and ranges.

Comment 8

[Nathan Froyd [:froydnj]]

(In reply to Mike Hommey [:glandium] from comment #7)
> I guess this results in the asan builds displaying:
> Check whether removing dead symbols breaks debugging... no
> ?

I think so.  I haven't actually pushed the patch through try, though.  The worry here is that the linker might mangle debug info, producing curious backtraces from asan?

Comment 9

[Mike Hommey [:glandium]]

(In reply to Nathan Froyd (:froydnj) from comment #8)
> I think so.  I haven't actually pushed the patch through try, though.  The
> worry here is that the linker might mangle debug info, producing curious
> backtraces from asan?

The worry is that the check would take that output as meaning the bug is present and disable gc-sections.

Comment 10

[Nathan Froyd [:froydnj]]

(In reply to Mike Hommey [:glandium] from comment #9)
> (In reply to Nathan Froyd (:froydnj) from comment #8)
> > I think so.  I haven't actually pushed the patch through try, though.  The
> > worry here is that the linker might mangle debug info, producing curious
> > backtraces from asan?
> 
> The worry is that the check would take that output as meaning the bug is
> present and disable gc-sections.

I think disabling gc-sections is OK; these are just ASAN builds for testing, not the builds we distribute to users.  Wasting a little space is OK.  *Enabling* gc-sections, however, might cause problems.  I will run this through try just to check.

Comment 11

[Nathan Froyd [:froydnj]]

From https://tbpl.mozilla.org/php/getParsedLog.php?id=27698439&tree=Try&full=1 :

checking whether removing dead symbols breaks debugging... yes

So I think this is OK...and it will DTRT on other compilers that don't output .debug_ranges, like GCC 4.8ish.

Comment 12

[Nathan Froyd [:froydnj]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/5f4d6a6d849f

Committed.  It makes the error go away and doesn't make the situation any worse for future compiler upgrades (e.g. GCC 4.8, bug 837445).

Comment 13

[Ed Morley [:emorley]]

Thank you :-)

Comment 14

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/5f4d6a6d849f