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

RESOLVED FIXED in Firefox 26

Status

()

Core
Build Config
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: RyanVM, Assigned: froydnj)

Tracking

(Blocks: 1 bug)

Trunk
mozilla26
x86_64
Linux
Points:
---
Bug Flags:
in-testsuite -

Firefox Tracking Flags

(firefox25 unaffected, firefox26 fixed, firefox-esr24 unaffected)

Details

Attachments

(1 attachment)

(Reporter)

Description

4 years ago
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
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?
(Assignee)

Comment 2

4 years ago
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.
(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?
(Assignee)

Comment 4

4 years ago
(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.
(Assignee)

Comment 5

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

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

Comment 6

4 years ago
Created attachment 802643 [details] [diff] [review]
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...
Attachment #802643 - Flags: review?(mh+mozilla)
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.
Attachment #802643 - Flags: review?(mh+mozilla) → review+
(Assignee)

Comment 8

4 years ago
(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?
Flags: needinfo?(mh+mozilla)
(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.
Flags: needinfo?(mh+mozilla)
(Assignee)

Comment 10

4 years ago
(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.
(Assignee)

Comment 11

4 years ago
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.
(Assignee)

Comment 12

4 years ago
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).
Flags: in-testsuite-
Thank you :-)
(Reporter)

Comment 14

4 years ago
https://hg.mozilla.org/mozilla-central/rev/5f4d6a6d849f
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla26
(Reporter)

Updated

4 years ago
Assignee: nobody → nfroyd
status-firefox25: --- → unaffected
status-firefox26: --- → fixed
status-firefox-esr24: --- → unaffected
You need to log in before you can comment on or make changes to this bug.