[Bug binutils/28588] significant performance regression in addr2line
https://sourceware.org/bugzilla/show_bug.cgi?id=28588 Joel Hock changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from Joel Hock --- I re-tested, and this is fixed by 30cbd32aec3. I'm closing this out as resolved / fixed. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29785] memory bloat in version 2.39
https://sourceware.org/bugzilla/show_bug.cgi?id=29785 Joel Hock changed: What|Removed |Added CC||joelhock at gmail dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28588] New: significant performance regression in addr2line
https://sourceware.org/bugzilla/show_bug.cgi?id=28588 Bug ID: 28588 Summary: significant performance regression in addr2line Product: binutils Version: 2.38 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: joelhock at gmail dot com Target Milestone: --- Commit ca8f6bc629c causes a significant performance issue for my use of addr2line. Specifically, the use of lookup_func_by_offset() exhibits quadratic complexity when processing a new compile unit. One of our larger compile units has 80k entries in the funcinfo table, many of which I believe come from C++ inlined subroutines. This takes almost 20 seconds to process, whereas before this commit, processing the compile unit was nearly instantaneous. The regression is especially felt when using a tool such as google-pprof, which queries addresses across many compile units; what used to take 1 minute before that commit now takes 10. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28834] New: incorrect detection of "DWARF error: section .debug_str is larger than its filesize"
https://sourceware.org/bugzilla/show_bug.cgi?id=28834 Bug ID: 28834 Summary: incorrect detection of "DWARF error: section .debug_str is larger than its filesize" Product: binutils Version: 2.37 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: joelhock at gmail dot com Target Milestone: --- Commit 647cebce12a can cause valid sections to be considered corrupt if their uncompressed size is greater than the size of the entire binary, resulting in warnings like: addr2line: DWARF error: section .debug_str is larger than its filesize! (0xb60c570 vs 0x9309705) One example binary we have is 150MB total; however, the .debug_str section is 190MB uncompressed (and only 27MB compressed). I’m not sure what the best fix is to keep the protection of intended by the commit without causing these false positives. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28834] incorrect detection of "DWARF error: section .debug_str is larger than its filesize"
https://sourceware.org/bugzilla/show_bug.cgi?id=28834 --- Comment #2 from Joel Hock --- I can't upload the binary, but the uncompressed size (b6e3fb5 in the output below) is correct. This output is from a different, but similar, binary than what was generating the original error message I posted: $ readelf -t mybinary [Nr] Name Type Address OffsetLink Size EntSize Info Align Flags ... [38] .debug_str PROGBITS 07259234 0 01a18720 0001 0 1 [0830]: MERGE, STRINGS, COMPRESSED ZLIB, 0b6e3fb5, 1 A 10x heuristic would have worked in this case, fwiw. Joel -- You are receiving this mail because: You are on the CC list for the bug.
