InvalidAddressRange on a special address should not make process crash or exit #326
Comments
|
Probably what we need to do is change gimli to treat 0 as a tombstone address, so that it skips rows until the next valid address. |
|
The ELF file is private, so sorry I can not upload it. How can I help do any test about |
|
You can try changing this line to |
|
Great! It works well and all 50K+ addresses are parsed successfully. BTW, how to output a function name like |
|
Um it's a bit strange that sometimes this |
|
I'm interested in finding out which symbols it can't demangle. Can you give a few of the mangled symbols that it fails on? (obtained without the |
|
You could try changing this code to: demangle(name.as_ref(), gimli::DW_LANG_Rust)
.or_else(|| demangle(name.as_ref(), gimli::DW_LANG_C_plus_plus))
.map(Cow::from)
.unwrap_or(name)That is, ignore the |
|
Um the
This project's |
|
Ah I see, it's not failing to demangle, it's failing to get the mangled name in the first place. Can you run |
|
Another address reports partial name: This project vs. LLVM-18: |
|
I think both of those are because we are failing to find Another possibility is that the linkage name isn't in the DWARF at all, and |
|
Sorry but |
|
It should be enough to do |
➜ shm nm /path/to/main | grep -w _ZN6google10LogMessage9LogStreamC1EPcil
0000000004e31530 t _ZN6google10LogMessage9LogStreamC1EPcil
➜ shm <pprof-debug-rs-demangling.sym ~/github/addr2line/target/debug/addr2line -f -e /path/to/main -a -i
0x0000000004e31530
LogStream
/proc/self/cwd/bazel-out/k8-opt/bin/external/glog/_virtual_includes/glog/glog/logging.h:1263
➜ shm LANG=C.UTF-8 objdump -W /home/gdh1995/sync/walle3/.cache/68cce18e346283f1d454605f04e495f3/execroot/autocar/bazel-out/k8-opt/bin/common/tools/simulation/simulation_main | grep -B4 -A12 4e31530
DW_CFA_offset: r16 (rip) at cfa-8
DW_CFA_nop
DW_CFA_nop
007405f0 0000000000000034 00000024 FDE cie=007405d0 pc=0000000004e31530..0000000004e3165e
Augmentation data: 53 84 04 ff
DW_CFA_advance_loc: 1 to 0000000004e31531
DW_CFA_def_cfa_offset: 16
DW_CFA_offset: r6 (rbp) at cfa-16
DW_CFA_advance_loc: 3 to 0000000004e31534
DW_CFA_def_cfa_register: r6 (rbp)
DW_CFA_advance_loc: 13 to 0000000004e31541
DW_CFA_offset: r3 (rbx) at cfa-56
DW_CFA_offset: r12 (r12) at cfa-48
DW_CFA_offset: r13 (r13) at cfa-40
DW_CFA_offset: r14 (r14) at cfa-32
DW_CFA_offset: r15 (r15) at cfa-24
--
<c0> DW_AT_name : (indirect string, offset: 0x16a5cfe): basic_ios
<1><c4>: Abbrev Number: 2 (DW_TAG_subprogram)
<c5> DW_AT_name : (indirect string, offset: 0xeb54f): ~basic_ios
<1><c9>: Abbrev Number: 3 (DW_TAG_subprogram)
<ca> DW_AT_low_pc : 0x4e31530
<d2> DW_AT_high_pc : 0x12e
<d6> DW_AT_GNU_all_call_sites: 1
<d6> DW_AT_name : (indirect string, offset: 0xbced95): LogStream
<2><da>: Abbrev Number: 6 (DW_TAG_inlined_subroutine)
<db> DW_AT_abstract_origin: <0xbf>
<df> DW_AT_ranges : 0
<e3> DW_AT_call_file : 1
<e4> DW_AT_call_line : 1262
<e6> DW_AT_call_column : 5
<2><e7>: Abbrev Number: 4 (DW_TAG_inlined_subroutine)
<e8> DW_AT_abstract_origin: <0x2a>
<ec> DW_AT_low_pc : 0x4e3157a
--
<f4e2270> DW_AT_call_line : 680
<f4e2272> DW_AT_call_column : 7
<8><f4e2273>: Abbrev Number: 7 (DW_TAG_inlined_subroutine)
<f4e2274> DW_AT_abstract_origin: <0xf4dc54d>
<f4e2278> DW_AT_ranges : 0x4e31530
<f4e227c> DW_AT_call_file : 5
<f4e227d> DW_AT_call_line : 332
<f4e227f> DW_AT_call_column : 2
<9><f4e2280>: Abbrev Number: 5 (DW_TAG_inlined_subroutine)
<f4e2281> DW_AT_abstract_origin: <0xf4dc557>
<f4e2285> DW_AT_low_pc : 0
<f4e228d> DW_AT_high_pc : 0x8
<f4e2291> DW_AT_call_file : 5
<f4e2292> DW_AT_call_line : 351
<f4e2294> DW_AT_call_column : 4
<10><f4e2295>: Abbrev Number: 4 (DW_TAG_inlined_subroutine)
<f4e2296> DW_AT_abstract_origin: <0xf4dc552>
--
000175a0 0000000004e58dbb 0000000004e58dc2
000175a0 0000000004e58dcc 0000000004e58dd3
000175a0 <End of list>
000175d0 0000000000000001 0000000000000001 (start == end)
000175d0 0000000004e31530 0000000004e3165e
000175d0 0000000004e31660 0000000004e316f8
000175d0 0000000004e31700 0000000004e317a0
000175d0 0000000004e317a0 0000000004e318bb
000175d0 0000000004e318c0 0000000004e318e8
000175d0 0000000004e31900 0000000004e31980
000175d0 0000000004e31980 0000000004e31a92
000175d0 0000000004e31aa0 0000000004e31bb2
000175d0 0000000004e31bc0 0000000004e31cd2
000175d0 0000000004e31ce0 0000000004e31df2
000175d0 0000000004e31e00 0000000004e31f12
000175d0 0000000004e31f20 0000000004e32032
000175d0 0000000004e32040 0000000004e32152
--
04e314d0 <End of list>
04e31500 0000000000000001 0000000000000001 (start == end)
04e31500 0000000000000001 0000000000000001 (start == end)
04e31500 <End of list>
04e31530 0000000000000001 0000000000000001 (start == end)
04e31530 0000000000000001 0000000000000001 (start == end)
04e31530 <End of list>
04e31560 0000000000000001 0000000000000001 (start == end)
04e31560 0000000000000001 0000000000000001 (start == end)
04e31560 <End of list>
04e31590 0000000000000001 0000000000000001 (start == end)
04e31590 0000000000000001 0000000000000001 (start == end)
04e31590 <End of list>
04e315c0 0000000000000001 0000000000000001 (start == end)
04e315c0 0000000000000001 0000000000000001 (start == end)
04e315c0 <End of list>
04e315f0 0000000000000001 0000000000000001 (start == end)
04e315f0 0000000000000001 0000000000000001 (start == end)
04e315f0 <End of list>
--
[0x00000a8a] Special opcode 117: advance Address by 8 to 0xe9 and Line by 0 to 0
[0x00000a8b] Advance PC by 8 to 0xf1
[0x00000a8d] Extended opcode 1: End of Sequence
[0x00000a90] Extended opcode 2: set Address to 0x4e31530
[0x00000a9b] Advance Line by 1262 to 1263
[0x00000a9e] Copy
[0x00000a9f] Set column to 79
[0x00000aa1] Set prologue_end to true
[0x00000aa2] Advance PC by constant 17 to 0x4e31541
[0x00000aa3] Special opcode 187: advance Address by 13 to 0x4e3154e and Line by 0 to 1263
[0x00000aa4] Set File Name to entry 4 in the File Name Table
[0x00000aa6] Set column to 9
[0x00000aa8] Advance Line by -802 to 461
[0x00000aab] Special opcode 61: advance Address by 4 to 0x4e31552 and Line by 0 to 461
[0x00000aac] Set column to 21
[0x00000aae] Set is_stmt to 0 |
|
|
Thanks, that's very helpful. So the problem is that |
|
There seems no |
|
Thank you very much. Deleting those lines does help a lot: |
|
There's a few more instances of |
|
So, deleting those lines will make I'm not sure when to accept the Thanks again! |
FYI:
But, other functions of |
And the speed difference is:
|
|
Ignoring To help figure out a solution, can you give more information on reproducing this? Which compiler and flags are you using? The DWARF should have a copy of this, such as: |
|
I'll take a try to make a minimal case in 1-2 days. |
|
Sorry the info above is incomplete. In fact I met this problem on both aarch64 and x86-64, and on the x86-64 (ubuntu 20.04 docker), it is: |
|
A minimal case would be useful. I tried clang 12.0.0 on godbolt but it includes the linkage name: https://godbolt.org/z/M1oWrhn7b |
|
Hello, here's a minimal case: // a.cc
struct Foo {
Foo();
int a;
};
Foo::Foo() { a = 1; }
struct Bar : public Foo {
Bar();
};
Bar::Bar() {}➜ t clang-18 -g1 -O2 -shared a.cc -o a.out
➜ t ~/github/addr2line/target/release/addr2line -afiC -e a.out <<< `nm a.out | grep -m1 Bar | awk '{print $1}'`
0x0000000000001110
Foo
/wo/t/a.cc:6
Bar
/wo/t/a.cc:12
➜ t clang-18 -g1 -O1 -shared a.cc -o a.out
➜ t ~/github/addr2line/target/release/addr2line -afiC -e a.out <<< `nm a.out | grep -m1 Bar | awk '{print $1}'`
0x0000000000001110
Foo
/wo/t/a.cc:6
Bar
/wo/t/a.cc:12
➜ t clang-18 -g1 -O0 -shared a.cc -o a.out
➜ t ~/github/addr2line/target/release/addr2line -afiC -e a.out <<< `nm a.out | grep -m1 Bar | awk '{print $1}'`
0x0000000000001130
Bar::Bar()
/wo/t/a.cc:12
➜ t clang-18 --version
Ubuntu clang version 18.1.3 (1ubuntu1)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
➜ t cat /etc/os-release
PRETTY_NAME="Ubuntu 24.04 LTS"
... |
|
Thanks, I can reproduce that now. The significant factor is the but if you compile with Notice how I'll think about whether there's a good way to fix this, but I think you should switch to compiling with the correct DWARF information. |
|
You said Then I wonder why it's "wrong" - C function names are simple enough and those in symbol tables should have been enough - am I right? |
|
The symbol table does not have inlined functions, so we need either |
|
Additionally, I still think that if the DWARF is correct, then the names it gives are better than the symbol table (mentioned in #324). The problem is that clang is generating DWARF that is not correct. |
|
What about querying all of |
|
|
It's fine if |
|
I don't see any opinions in libunwind/libunwind#794 about shorter DWARF. Is that the correct link? |
|
Um, the link is about:
This occurs on |
|
Ah sorry, I misread and was expecting someone from the LLVM project to be giving an opinion that this was intentional. It could easily be an oversight instead. I think |
That's not reliable behaviour, and doesn't address my concern. The simplest fix is to do what llvm-addr2line does, which is to give preference to the symbol table. I don't see any way to better than that for the DWARF generated by I will look into this more when I have time, but I don't consider it a high priority (since the result with |
Oh I see. Anyway, the current has been enough to work with Thanks a lot for this project and your patience ^_^. |
I still haven't managed to reproduce this. I'm sure that treating this as a tombstone is the right thing to do, but it would still be nice to test it in practice. The conditions to be able to reproduce this are:
|
// a.c
struct foo_st {
int member;
};
void handle_bar(void *bar);
void foo_method1(struct foo_st *foo) {
handle_bar(&foo->member);
}
void foo_method2() {
}And tests: gcc-9 -g -O3 -c -o a.o a.c
# or: gcc-9 -g -O2 -c -o a.o a.c
/home/gdh1995/github/addr2line/target/debug/addr2line -e a.o <<< 0x10
# or: /home/gdh1995/github/addr2line/target/debug/addr2line -e a.o <<< 0x0And |
|
Thanks for your continued assistance with this issue. I'm not sure that is the same problem that was first reported in this issue. That problem is because this crate doesn't handle relocations in object files. If I link that object file into a executable then it works fine: // main.c
struct foo_st;
void foo_method1(struct foo_st *foo);
void handle_bar(void *bar) {}
int main() {
foo_method1(0);
return 0;
}gcc-9 a.o main.c -o main
target/debug/addr2line -e main <<< `nm main | grep foo_method2 | cut -d ' ' -f1`Was your original report for an executable file or a relocatable object file? I can fix it to work for relocatable object files by processing relocations, but I doubt that is what you need, and I doubt it will fix the original issue. |
|
Um, the original code is from jemalloc/src/arena.o The original address is captured by If I replaced the check with |
That |
This comment was marked as outdated.
This comment was marked as outdated.
|
Seems about |
|
Having a bunch of failures grouped like that is expected because a single tombstone mid sequence will cause the line program for the entire compilation unit to be ignored (in this case I've looked into the Can you tell me which linker is being used? |
|
clang-12 and ld.lld-12 |
|
I think all the problems reported in this issue have been fixed in version 0.24.2.
I decided to do this change because the symbol table name has more information (it includes the clone suffix). |
Hello I'm searching for a faster replacement for the Binutils addr2line, and this project is incredible fast (about 1 sec vs. 12min) for my program. Many thanks!
Crash details
However, when I ran it with a non-stripped x86-64 ELF file (from clang-12), it crashed with
InvalidAddressRange,and the below code always reported
Failed to get the next row: InvalidAddressRange The end of an address range must not be before the beginning..Then I cloned
gimli, compiled it with debugging code and gettest: addr 2: 0 vs. 4:BTW, this
addr2lineworked well when providing a same input address (0x000000000bdbb6d0) while ax86_64-linux-gnu-strip -s-ed ELF file.Expected
I want to use this tool to decode tons of addresses which are recorded by gperftools CPU profiling and passed to
addr2lineby thepprofPerl script.So, might this project add an option to ignore such DWARF errors and continue to parse and output other input addresses?
The text was updated successfully, but these errors were encountered: