[valgrind] [Bug 465465] Eviction Emulation in Cachegrind for Detecting Cache Conflicts
https://bugs.kde.org/show_bug.cgi?id=465465 --- Comment #15 from Nick Nethercote --- The existing cache and branch simulations are very simplistic, and about 20 years out of date. I think hardware counters are a much better way of getting cache statistics. I recently made `--cache-sim=no` the default for this reason. I understand that the statistics you've added aren't available via hardware counters. But still I worry that using an unrealistic simulation as the foundation could lead to inaccurate results. Another thing: in the example output file you have lines like these: > 4,496,605,023 (51.80%) 47,791,341,277 (5545.9%) 127,816 (2819.7%) 147,917 > (23112.0%) 73,046 (1014.2%) 154,413 (203.7%) 8,192 (51.35%) > binary_search_test The percentages in the all the new columns (everything other than `Ir`) greatly exceed 100%, which seems wrong. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 469146] massif --ignore-fn does not ignore inlined functions
https://bugs.kde.org/show_bug.cgi?id=469146 --- Comment #17 from Nick Nethercote --- It has been a long time since I looked at this code. I don't have much to add other than the changes seem plausible -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 467472] Rewrite `cg_annotate` in Python
https://bugs.kde.org/show_bug.cgi?id=467472 Nick Nethercote changed: What|Removed |Added Resolution|--- |FIXED Status|REPORTED|RESOLVED --- Comment #4 from Nick Nethercote --- I just merged a slightly improved version of the attached patch: https://sourceware.org/git/?p=valgrind.git;a=commit;h=4650b7949ae3a41326e52ae454a9202493c41444 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 467472] Rewrite `cg_annotate` in Python
https://bugs.kde.org/show_bug.cgi?id=467472 --- Comment #3 from Nick Nethercote --- Created attachment 157350 --> https://bugs.kde.org/attachment.cgi?id=157350&action=edit New cg_annotate.in file -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 467472] Rewrite `cg_annotate` in Python
https://bugs.kde.org/show_bug.cgi?id=467472 --- Comment #2 from Nick Nethercote --- Created attachment 157349 --> https://bugs.kde.org/attachment.cgi?id=157349&action=edit Patch minus cg_annotate.in changes (easier to read) -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 467472] Rewrite `cg_annotate` in Python
https://bugs.kde.org/show_bug.cgi?id=467472 --- Comment #1 from Nick Nethercote --- Created attachment 157348 --> https://bugs.kde.org/attachment.cgi?id=157348&action=edit Patch -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 467472] New: Rewrite `cg_annotate` in Python
https://bugs.kde.org/show_bug.cgi?id=467472 Bug ID: 467472 Summary: Rewrite `cg_annotate` in Python Classification: Developer tools Product: valgrind Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: cachegrind Assignee: n...@valgrind.org Reporter: n.netherc...@gmail.com Target Milestone: --- Perl was a reasonable choice for `cg_annotate` in 2002, but not in 2023. Also, the existing structure of the code is not good. These two things make it hard to modify `cg_annotate` in any significant way. Benefits of the change: - Now written in a language that is (a) nice, and (b) not moribund. - Easier to maintain, due to (a) abovementioned better language, (b) better code structure, and (c) better language tooling, such as formatters, type checkers, and linters. - The new version is a little shorter. - It runs about 2x faster. - Argument handling is more standard. E.g. things like `--context 2`, `--auto`, `--no-auto` are supported. (The old forms that require `=` are still supported, though the `=yes`/`=no` forms are deprecated.) The behaviour and output of the new version is identical for typical uses, but there are some very minor changes for edge cases, which nobody is likely to notice. For example: - The file format is slightly changed: I removed support for '.' counts, which had the same meaning as '0'. This was a feature that Cachegrind never used, and the old script handled it inconsistently. - The new version will abort on a malformed data line. The old version would just print a warning and continue. The commit also adds a new test `ann3` that tests many parts of `cg_annotate` that weren't tested previously, and tweaks the existing `ann2` test. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 452758] Valgrind does not read properly DWARF5 as generated by Clang14
https://bugs.kde.org/show_bug.cgi?id=452758
--- Comment #47 from Nick Nethercote ---
My test Rust program was this, in `a.rs`:
> fn main() {
> println!("hello world");
> }
And I compiled with `rustc +nightly a.rs` to produce the executable `a`.
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 452758] Valgrind does not read properly DWARF5 as generated by Clang14
https://bugs.kde.org/show_bug.cgi?id=452758 --- Comment #46 from Nick Nethercote --- > Could you test again with top of tree and see whether --read-var-info=yes > also works OK? My normal workflow works well. It uses Cachegrind and DHAT, which don't need `--read-var-info=yes`. I also tested Memcheck on a trivial Rust program and `--read-var-info=yes` had problems: > ==19085== Memcheck, a memory error detector > ==19085== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. > ==19085== Using Valgrind-3.20.0.GIT and LibVEX; rerun with -h for copyright > info > ==19085== Command: ./a > ==19085== > > parse DIE(readdwarf3.c:3994): confused by: > <0>: Abbrev Number: 1 (DW_TAG_compile_unit) > DW_AT_producer: (indirect string, offset: 0x0): clang LLVM (rustc > version 1.63.0-nightly (420c970cb 2022-06-09)) > DW_AT_language: 28 > DW_AT_name: (indirect string, offset: 0x41): > library/std/src/lib.rs/@/std.85a61a41-cgu.0 > DW_AT_stmt_list : 0 > DW_AT_comp_dir: (indirect string, offset: 0x6d): > /rustc/420c970cb1edccbf60ff2aeb51ca01e2300b09ef > DW_AT_GNU_pubnames: 1 > DW_AT_low_pc : 0x0 > DW_AT_ranges : 322832 > parse_type_DIE: > --19085-- WARNING: Serious error when reading debug info > --19085-- When reading debug info from /home/njn/dev/rustc-perf/a: > --19085-- confused by the above DIE > hello world > ==19085== > ==19085== HEAP SUMMARY: > ==19085== in use at exit: 0 bytes in 0 blocks > ==19085== total heap usage: 11 allocs, 11 frees, 3,181 bytes allocated > ==19085== > ==19085== All heap blocks were freed -- no leaks are possible > ==19085== > ==19085== For lists of detected and suppressed errors, rerun with: -s > ==19085== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 452758] Valgrind does not read properly DWARF5 as generated by Clang14
https://bugs.kde.org/show_bug.cgi?id=452758 --- Comment #35 from Nick Nethercote --- With the additional commits things are working again for Rust code, thanks! -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 452758] Valgrind does not read properly DWARF5 as generated by Clang14
https://bugs.kde.org/show_bug.cgi?id=452758 --- Comment #25 from Nick Nethercote --- (In reply to Nick Nethercote from comment #23) > FYI: several people are experiencing this when running Valgrind on code > compiled with the current nightly Rust compiler. Unfortunately, this is still happening. E.g if you have an up-to-date rustc (e.g. updated via `rustup` with `rustup update nightly`). > [gulf:~/dev/rustc-perf] vg1 --trace-children=yes rustc +nightly --version > ==787430== Memcheck, a memory error detector > ==787430== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. > ==787430== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info > ==787430== Command: > /home/njn/.rustup/toolchains/532be942ddf8f40d086e54d157453434b16e9647/bin/rustc > ==787430== > ### unhandled dwarf2 abbrev form code 0x25 > ### unhandled dwarf2 abbrev form code 0x25 > ### unhandled dwarf2 abbrev form code 0x25 > ### unhandled dwarf2 abbrev form code 0x23 > ### unhandled dwarf2 abbrev form code 0x25 > ### unhandled dwarf2 abbrev form code 0x25 > ### unhandled dwarf2 abbrev form code 0x25 > ### unhandled dwarf2 abbrev form code 0x23 > ==787430== Valgrind: debuginfo reader: ensure_valid failed: > ==787430== Valgrind: during call to ML_(img_get) > ==787430== Valgrind: request for range [1903633023, +4) exceeds > ==787430== Valgrind: valid image size of 1932688 for image: > ==787430== Valgrind: > "/home/njn/.rustup/toolchains/532be942ddf8f40d086e54d157453434b16e9647/bin/rustc" > ==787430== > ==787430== Valgrind: debuginfo reader: Possibly corrupted debuginfo file. > ==787430== Valgrind: I can't recover. Giving up. Sorry. > ==787430== -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 452758] Valgrind does not read properly DWARF5 as generated by Clang14
https://bugs.kde.org/show_bug.cgi?id=452758 Nick Nethercote changed: What|Removed |Added CC||n.netherc...@gmail.com --- Comment #23 from Nick Nethercote --- FYI: several people are experiencing this when running Valgrind on code compiled with the current nightly Rust compiler. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 452058] Generated suppressions contain a mix of mangled (physical) and demangled (inline) frames
https://bugs.kde.org/show_bug.cgi?id=452058 --- Comment #4 from Nick Nethercote --- > Does this depend on the rustc version used? I tried a few versions: 1.57.0, 1.60.0, nightly 1.62, they all behaved the same on my Ubuntu 21.10 box. It looks to me like you're not getting any inline frames in your stack trace. This could happen if you're using a Valgrind prior to the fix for bug 445668, maybe? Anyway, your diagnosis of the underlying problem sounds entirely correct to me. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 452058] New: Generated suppressions contain a mix of mangled (physical) and demangled (inline) frames
https://bugs.kde.org/show_bug.cgi?id=452058
Bug ID: 452058
Summary: Generated suppressions contain a mix of mangled
(physical) and demangled (inline) frames
Product: valgrind
Version: unspecified
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: jsew...@acm.org
Reporter: n.netherc...@gmail.com
Target Milestone: ---
Put this Rust program in `a.rs`:
use std::io::{stdin, Read};
fn main() {
let mut buf = vec![];
if let Err(e) = stdin().read(&mut buf) {
println!("{}", e)
}
}
Then build it with: rustc a.rs
Then run: valgrind --leak-check=full --show-leak-kinds=all
--gen-suppressions=all ./a
Then hit enter, to provide the running program with necessary input.
On termination, Memcheck prints two suppressions. Here's the first one, which
is enough to show the problem:
{
Memcheck:Leak
match-leak-kinds: reachable
fun:malloc
fun:alloc
fun:alloc_impl
fun:allocate
fun:exchange_malloc
fun:new
fun:from
fun:_ZN3std10sys_common5mutex12MovableMutex3new17h4e64539bf4ba99a6E
fun:new>
fun:{closure#0}
fun:{closure#0}>,
std::io::stdio::stdin::{closure#0}>
fun:{closure#0}>,
std::lazy::{impl#10}::get_or_init::{closure#0}, !>
fun:_ZN3std4sync4once4Once15call_once_force28_$u7b$$u7b$closure$u7d$$u7d$17ha9375aeb05e4aae3E
fun:_ZN3std4sync4once4Once10call_inner17hb3a655ef2ff7c156E
fun:call_once_force
fun:_ZN3std4lazy21SyncOnceCell$LT$T$GT$10initialize17h3a3ef5fbb9e2970eE
fun:get_or_try_init>,
std::lazy::{impl#10}::get_or_init::{closure#0}, !>
fun:get_or_init>,
std::io::stdio::stdin::{closure#0}>
fun:_ZN3std2io5stdio5stdin17h94821c2f5cbdd619E
fun:_ZN1a4main17h8bbda9164eb1d7fdE
fun:_ZN4core3ops8function6FnOnce9call_once17hb0b8acf7ed5a9c1fE
fun:_ZN3std10sys_common9backtrace28__rust_begin_short_backtrace17hedc3d4705fc28138E
fun:_ZN3std2rt10lang_start28_$u7b$$u7b$closure$u7d$$u7d$17h478bd93d3dae3c53E
fun:call_once<(), (dyn core::ops::function::Fn<(), Output=i32> +
core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe)>
fun:do_call<&(dyn core::ops::function::Fn<(), Output=i32> +
core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe), i32>
fun:try +
core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe)>
fun:catch_unwind<&(dyn core::ops::function::Fn<(), Output=i32> +
core::marker::Sync + core::panic::unwind_safe::RefUnwindSafe), i32>
fun:{closure#2}
fun:do_call
fun:try
fun:catch_unwind
fun:_ZN3std2rt19lang_start_internal17hd15a47be08101c28E
fun:_ZN3std2rt10lang_start17h99d3162981a37fa3E
}
Suppressions are supposed to use *mangled* function names, but this has a mix
of mangled and demangled names. I did some digging and discovered that physical
stack frames are correctly showing as mangled, but inline stack frames are
incorrectly showing as demangled.
The Rust compiler tends to inline aggressively. This bug makes it very hard to
write suppressions, because frames that might be inlined one day might be
non-inlined later on after making moderate changes to a program.
This bug is preventing me from adding a useful suppression for the Rust
standard library. See https://github.com/rust-lang/rust/issues/80406 for
details.
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 445916] Demangle Rust v0 symbols with .llvm suffix
https://bugs.kde.org/show_bug.cgi?id=445916 --- Comment #2 from Nick Nethercote --- https://github.com/rust-lang/rust/issues/60705#issuecomment-976064467 suggests that we should only cut off what comes after '.', *not* '$'. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 445916] Demangle Rust v0 symbols with .llvm suffix
https://bugs.kde.org/show_bug.cgi?id=445916 Nick Nethercote changed: What|Removed |Added CC||n.netherc...@gmail.com --- Comment #1 from Nick Nethercote --- I agree that cutting off after `.` or `$` is fine for Rust v0 symbols. I personally never find that suffix useful. AFAIK Valgrind uses the libiberty demangler. How does that work? Is there scope for a Valgrind-specific fix, or would it be better to get the suffix trimmed in libiberty and then import updated code into Valgrind? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 445668] Inline stack frame generation is broken for Rust binaries
https://bugs.kde.org/show_bug.cgi?id=445668 --- Comment #8 from Nick Nethercote --- > The Rust compiler currently sometimes generates symbols with a > `.llvm.` suffix. These violate the v0 spec, which doesn't allow '.' > chars, and the libiberty/Valgrind demangler doesn't demangle them. It's a > problem that needs to be fixed on the Rust side. Going back to this (and I know it's a tangent), there's now some disagreement about whether this needs to be fixed on the Rust side, or the libiberty/Valgrind side: https://github.com/rust-lang/rust/issues/60705#issuecomment-974011409 :( -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 445668] Inline stack frame generation is broken for Rust binaries
https://bugs.kde.org/show_bug.cgi?id=445668 --- Comment #7 from Nick Nethercote --- The one-line fix works on the big example! Thank you. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 445668] Inline stack frame generation is broken for Rust binaries
https://bugs.kde.org/show_bug.cgi?id=445668 --- Comment #4 from Nick Nethercote --- Created attachment 143715 --> https://bugs.kde.org/attachment.cgi?id=143715&action=edit Compiled file Here's the binary produced by Rust 1.56.1 for `rustc -g a.rs` on my x86-64 Linux box. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 445668] Inline stack frame generation is broken for Rust binaries
https://bugs.kde.org/show_bug.cgi?id=445668 --- Comment #3 from Nick Nethercote --- Created attachment 143713 --> https://bugs.kde.org/attachment.cgi?id=143713&action=edit Rust reproducer I've written a tiny program that reproduces the problem. - I compiled with Rust 1.56.1 with `rustc -g a.rs`. - I ran DHAT with `vg-in-place --tool=dhat --dhat-out-file=dhout ./a`. - I viewed `dhout` with `dh_view.html`. Trunk Valgrind has a first PP like this: ``` │ #1: 0x1123BB: alloc::alloc::alloc (alloc.rs:86) │ #2: 0x112446: alloc::alloc::Global::alloc_impl (alloc.rs:166) │ #3: 0x112B29: ::allocate (alloc.rs:226) │ #4: 0x110991: alloc::raw_vec::finish_grow (raw_vec.rs:510) │ #5: 0x110E85: alloc::raw_vec::RawVec::grow_amortized (raw_vec.rs:443) │ #6: 0x111045: alloc::raw_vec::RawVec::reserve::do_reserve_and_handle (raw_vec.rs:334) │ #7: 0x11101B: alloc::raw_vec::RawVec::reserve (raw_vec.rs:338) │ #8: 0x1135DF: alloc::vec::Vec::reserve (mod.rs:805) │ #9: 0x1139AF: a::main (a.rs:5) │ #10: 0x11206A: core::ops::function::FnOnce::call_once (function.rs:227) │ #11: 0x111F5D: std::sys_common::backtrace::__rust_begin_short_backtrace (backtrace.rs:125) ``` With the abovementioned commit reverted, the first PP looks like this: ``` │ #1: 0x1123BB: alloc::alloc::alloc (alloc.rs:86) │ #2: 0x112446: alloc::alloc::Global::alloc_impl (alloc.rs:166) │ #3: 0x112B29: ::allocate (alloc.rs:226) │ #4: 0x110991: alloc::raw_vec::finish_grow (raw_vec.rs:510) │ #5: 0x110E85: alloc::raw_vec::RawVec::grow_amortized (raw_vec.rs:443) │ #6: 0x111045: alloc::raw_vec::RawVec::reserve::do_reserve_and_handle (raw_vec.rs:334) │ #7: 0x11101B: alloc::raw_vec::RawVec::reserve (raw_vec.rs:338) │ #8: 0x1135DF: alloc::vec::Vec::reserve (mod.rs:805) │ #9: 0x1139AF: f4 (a.rs:5) │ #10: 0x1139AF: f3 (a.rs:12) │ #11: 0x1139AF: f2 (a.rs:17) │ #12: 0x1139AF: f1 (a.rs:22) │ #13: 0x1139AF: a::main (a.rs:26) │ #14: 0x11206A: core::ops::function::FnOnce::call_once (function.rs:227) │ #15: 0x111F5D: std::sys_common::backtrace::__rust_begin_short_backtrace (backtrace.rs:125) ``` -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 445668] Inline stack frame generation is broken for Rust binaries
https://bugs.kde.org/show_bug.cgi?id=445668 --- Comment #2 from Nick Nethercote --- > (*) BTW. What is this? It looks like a mangled Rust v0 symbol, but it isn't > because it (I also checked with c++filt) cannot be demangled. The Rust compiler currently sometimes generates symbols with a `.llvm.` suffix. These violate the v0 spec, which doesn't allow '.' chars, and the libiberty/Valgrind demangler doesn't demangle them. It's a problem that needs to be fixed on the Rust side. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 445668] Inline stack frame generation is broken for Rust binaries
https://bugs.kde.org/show_bug.cgi?id=445668 Nick Nethercote changed: What|Removed |Added CC||m...@klomp.org -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 445668] New: Inline stack frame generation is broken for Rust binaries
https://bugs.kde.org/show_bug.cgi?id=445668
Bug ID: 445668
Summary: Inline stack frame generation is broken for Rust
binaries
Product: valgrind
Version: unspecified
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: jsew...@acm.org
Reporter: n.netherc...@gmail.com
Target Milestone: ---
Here is some DHAT output I am getting with Rust code:
> └── PP 1.14/14 {
> Total: 118,312 bytes (0.05%, 60.74/Minstr) in 11,864 blocks (1.12%,
> 6.09/Minstr), avg size 9.97 bytes, avg lifetime 60,918.19 instrs (0% of
> program duration)
> Max: 40 bytes in 5 blocks, avg size 8 bytes
> At t-gmax: 0 bytes (0%) in 0 blocks (0%), avg size 0 bytes
> At t-end: 0 bytes (0%) in 0 blocks (0%), avg size 0 bytes
> Reads: 178,976 bytes (0.03%, 91.89/Minstr), 1.51/byte
> Writes:130,464 bytes (0.05%, 66.98/Minstr), 1.1/byte
> Allocated at {
> #1: 0xA2D0172:
> _RNvMs0_NtCs5l0EXMQXRMU_21rustc_data_structures17obligation_forestINtB5_16ObligationForestNtNtNtCsdozMG8X9FIu_21rustc_trait_selection6traits7fulfill26PendingPredicateObligationE22register_obligation_atB1v_.llvm.8517020237817239694
> (alloc.rs:87)
> #2: 0xA2C42B2:
> _RINvMs0_NtCs5l0EXMQXRMU_21rustc_data_structures17obligation_forestINtB6_16ObligationForestNtNtNtCsdozMG8X9FIu_21rustc_trait_selection6traits7fulfill26PendingPredicateObligationE19process_obligationsNtB1s_16FulfillProcessorINtB6_7OutcomeB1q_NtNtCsgI90OQiJWEs_11rustc_infer6traits20FulfillmentErrorCodeEEB1w_
> (mod.rs:459)
> #3: 0xA27EA42:
> _RNvMs_NtNtCsdozMG8X9FIu_21rustc_trait_selection6traits7fulfillNtB4_18FulfillmentContext6select.llvm.5302840341462405287
> (fulfill.rs:140)
> }
> }
Here's what it should look like:
>└── PP 1.14/14 {
> Total: 118,312 bytes (0.05%, 60.81/Minstr) in 11,864 blocks (1.12%,
> 6.1/Minstr), avg size 9.97 bytes, avg lifetime 60,857.47 instrs (0% of
> program duration)
> Max: 40 bytes in 5 blocks, avg size 8 bytes
> At t-gmax: 0 bytes (0%) in 0 blocks (0%), avg size 0 bytes
> At t-end: 0 bytes (0%) in 0 blocks (0%), avg size 0 bytes
> Reads: 178,976 bytes (0.03%, 91.99/Minstr), 1.51/byte
> Writes:130,464 bytes (0.05%, 67.05/Minstr), 1.1/byte
> Allocated at {
> #1: 0xA2CD172: alloc (alloc.rs:87)
> #2: 0xA2CD172: alloc_impl (alloc.rs:169)
> #3: 0xA2CD172: allocate (alloc.rs:229)
> #4: 0xA2CD172: exchange_malloc (alloc.rs:318)
> #5: 0xA2CD172:
> new
> (mod.rs:192)
> #6: 0xA2CD172:
> _RNvMs0_NtCs5l0EXMQXRMU_21rustc_data_structures17obligation_forestINtB5_16ObligationForestNtNtNtCsdozMG8X9FIu_21rustc_trait_selection6traits7fulfill26PendingPredicateObligationE22register_obligation_atB1v_.llvm.8517020237817239694
> (mod.rs:376)
> #7: 0xA2C12B2:
> _RINvMs0_NtCs5l0EXMQXRMU_21rustc_data_structures17obligation_forestINtB6_16ObligationForestNtNtNtCsdozMG8X9FIu_21rustc_trait_selection6traits7fulfill26PendingPredicateObligationE19process_obligationsNtB1s_16FulfillProcessorINtB6_7OutcomeB1q_NtNtCsgI90OQiJWEs_11rustc_infer6traits20FulfillmentErrorCodeEEB1w_
> (mod.rs:459)
> #8: 0xA27BA42:
> _RNvMs_NtNtCsdozMG8X9FIu_21rustc_trait_selection6traits7fulfillNtB4_18FulfillmentContext6select.llvm.5302840341462405287
> (fulfill.rs:140)
> }
> }
I bisected the problem to this commit:
commit 75e3ef0f3b834f75f49333d35b5a040060247b03
Author: Mark Wielaard
Date: Thu Sep 16 22:01:47 2021 +0200
readdwarf3: Skip units without addresses when looking for inlined functions
When a unit doesn't cover any addresses skip it because no actual code
will be inside. Also use skip_DIE instead of read_DIE when not parsing
(skipping) children.
Reverting this commit fixed the problem, though the reversion was a bit messy
because some things have changed since.
Mark, I don't understand much about dwarf3. Any idea what might be wrong? I was
profiling the Rust compiler which is very large and complicated. If necessary,
I could try to create a smaller Rust program that reproduces the error.
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 445184] Rust v0 symbol demangling is broken
https://bugs.kde.org/show_bug.cgi?id=445184 Nick Nethercote changed: What|Removed |Added Resolution|--- |FIXED Status|REPORTED|RESOLVED -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 445235] Java/Ada/D demangling is probably broken
https://bugs.kde.org/show_bug.cgi?id=445235 Bug 445235 depends on bug 445184, which changed state. Bug 445184 Summary: Rust v0 symbol demangling is broken https://bugs.kde.org/show_bug.cgi?id=445184 What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 445184] Rust v0 symbol demangling is broken
https://bugs.kde.org/show_bug.cgi?id=445184 --- Comment #4 from Nick Nethercote --- I filed #445235 for Java/Ada/D. Pushed as: commit 4831385c6706b377851284adc4c4545fff4c6564 (HEAD -> master, origin/master, origin/HEAD) Author: Nicholas Nethercote Date: Tue Nov 9 12:30:07 2021 +1100 Fix Rust v0 demangling. It's currently broken due to a silly test that prevents the v0 demangling code from even running. The commit also adds a test, to avoid such problems in the future. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 445235] New: Java/Ada/D demangling is probably broken
https://bugs.kde.org/show_bug.cgi?id=445235 Bug ID: 445235 Summary: Java/Ada/D demangling is probably broken Product: valgrind Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: jsew...@acm.org Reporter: n.netherc...@gmail.com CC: jsew...@acm.org, m...@klomp.org, philippe.waroqui...@skynet.be Depends on: 445184 Target Milestone: --- +++ This bug was initially created as a clone of Bug #445184 +++ Valgrind has code to demangle symbols for: C++, Rust, Java, Ada, and D. But the Java/Ada/D demangling is probably broken because the code is unreachable. `VG_(demangle)` has an initial test that requires that the first two chars be "_Z" or "_R", which excludes a bunch of cases. Also, the code in `ML_(cplus_demangle)` that calls the demanglers for Java/Ada/D is a bit different to that for C++ and Rust (in the way the `*_DEMANGLING` constants are used), which may also be a problem. >From a quick look at the code, I think the following is true. - C++ symbols usually start with "_Z", but "_GLOBAL_" is also possible, which won't work. - Rust symbols start with "_Z" or "_R". - Java symbols are a subset of C++ symbols, so should be ok, modulo possible "_GLOBAL_" cases, and possible AUTO_DEMANGLING problems. - D symbols start with "_D", and so will be broken. - Ada symbols can start with "_ada_", or with a lower-case letter, and so will be broken. Referenced Bugs: https://bugs.kde.org/show_bug.cgi?id=445184 [Bug 445184] Rust v0 symbol demangling is broken -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 445184] Rust v0 symbol demangling is broken
https://bugs.kde.org/show_bug.cgi?id=445184 Nick Nethercote changed: What|Removed |Added Blocks||445235 Referenced Bugs: https://bugs.kde.org/show_bug.cgi?id=445235 [Bug 445235] Java/Ada/D demangling is probably broken -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 445184] Rust v0 symbol demangling is broken
https://bugs.kde.org/show_bug.cgi?id=445184 --- Comment #3 from Nick Nethercote --- > What about the Java Ada/gnat and D demangling defined in ML_(cplus_demangle)? > We seem to miss demangling them too because they (probably) don't start with > _Z or _R and aren't guarded by AUTO_DEMANGLING. > Has that also always been broken? Did we simple not notice because nobody > uses valgrind with those languages? >From a quick look at the code, I think the following is true. - C++ symbols usually start with "_Z", but "_GLOBAL_" is also possible, which won't work. - Java symbols are a subset of C++ symbols, so should be ok, modulo possible "_GLOBAL_" cases, and possible AUTO_DEMANGLING problems. - D symbols start with "_D", and so will be broken. - Ada symbols can start with "_ada_", or with a lower-case letter, and so will be broken. I found the AUTO_DEMANGLING stuff a bit confusing, but you are right that the code for Rust and C++ looks a bit different to the code for Java/Ada/D, in that respect. I suspect that you are also right about Java/Ada/D demangling being broken but nobody noticing due to low levels of usage. Fixing the Java/Ada/D problems is outside the scope of this bug, and I'm not familiar enough with those languages to fix and test things anyway. Here's what I'll do: I'll file a new bug pointing out the problems, update my commit to include a comment in `VG_(demangle)` that points to the bug, and then push. That way the Rust problems will be fixed, and the Java/Ada/D problems at least will be documented. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 445184] Rust v0 symbol demangling is broken
https://bugs.kde.org/show_bug.cgi?id=445184 --- Comment #1 from Nick Nethercote --- I have push permission for the repository, so once people are happy with this (assuming they are) I can push it myself. Thanks! -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 445184] New: Rust v0 symbol demangling is broken
https://bugs.kde.org/show_bug.cgi?id=445184
Bug ID: 445184
Summary: Rust v0 symbol demangling is broken
Product: valgrind
Version: unspecified
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: jsew...@acm.org
Reporter: n.netherc...@gmail.com
Target Milestone: ---
Created attachment 143357
--> https://bugs.kde.org/attachment.cgi?id=143357&action=edit
Fix Rust v0 demangling.
Rust has an old symbol mangling scheme ("legacy") and a new scheme ("v0"). The
tracking issue for switching to the new scheme is at
https://github.com/rust-lang/rust/issues/60705.
Valgrind has supported the legacy scheme for a long time. Bug #431306 added
code to support the v0 scheme, which was released in 3.18. Unfortunately, due
to an erroneous condition in the outer layer of the demangling code, the v0
demangling code is never reached. C++ and legacy symbols start with "_Z", but
v0 symbols start with "_R", and this erroneous condition only checks for the
former.
It's possible that this wasn't noticed because the Rust compiler is still using
legacy mangling; you need to run with `-Z symbol-mangling-version=v0` to enable
v0 mangling.
The attachment fixes the problem and adds a test. I have confirmed that the
test fails without the fix -- because the one legacy symbol is demangled
correctly, but the two v0 symbols are not. I have also confirmed the validity
of the fix by doing large scale profiling of the Rust compiler, which is using
v0 symbols internally.
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 409678] improvement suggestion for dhat
https://bugs.kde.org/show_bug.cgi?id=409678 --- Comment #5 from Nick Nethercote --- FWIW, you can run some tests of DHAT's viewer by loading dhat with `?test=1` appended to the URL. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 406578] More general Access Counts
https://bugs.kde.org/show_bug.cgi?id=406578
--- Comment #1 from Nick Nethercote ---
Valgrind 3.15 just came out and it completely overhauled DHAT. The new version
is much better.
The output is now in a tree. The root node of the tree covers the entire
program, and looks like this:
> AP 1/1 (25 children) {
> Total: 1,355,253,987 bytes (100%, 67,454.81/Minstr) in 5,943,417 blocks
> (100%, 295.82/Minstr), avg size 228.03 bytes, avg lifetime 3,134,692,250.67
> instrs (15.6% of program duration)
> At t-gmax: 423,930,307 bytes (100%) in 1,575,682 blocks (100%), avg size
> 269.05 bytes
> At t-end: 258,002 bytes (100%) in 2,129 blocks (100%), avg size 121.18
> bytes
> Reads: 5,478,606,988 bytes (100%, 272,685.7/Minstr), 4.04/byte
> Writes:2,040,294,800 bytes (100%, 101,551.22/Minstr), 1.51/byte
> Allocated at {
> #0: [root]
> }
> }
I'm not sure I understand exactly what you're asking for, but:
- "how many times was an allocator accessed" might be the "5,943,417 blocks"
part
- "What is the read count of any width at any offset across all of blocks"
might be the "Reads: 5,478,606,988 bytes" part, though that's a byte count
rather than a read count.
Does that help?
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 406352] valgrind 3.15.0-RC1 fails cachegrind/callgrind ann tests because of missing a.c
https://bugs.kde.org/show_bug.cgi?id=406352 Nick Nethercote changed: What|Removed |Added CC||n.netherc...@gmail.com --- Comment #1 from Nick Nethercote --- > +# They just serves as input for cg_annotate in ann1 and ann2. s/serves/serve/ -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 399355] Add callgrind_diff
https://bugs.kde.org/show_bug.cgi?id=399355 --- Comment #13 from Nick Nethercote --- I haven't looked into the problems reported in comment 6. I don't see why this shouldn't be able to work, but the Callgrind format does have a lot of bells and whistles that the Cachegrind format does not, so they have to all be handled appropriately. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 402369] Overhaul DHAT
https://bugs.kde.org/show_bug.cgi?id=402369 Nick Nethercote changed: What|Removed |Added Resolution|--- |FIXED Status|REPORTED|RESOLVED --- Comment #11 from Nick Nethercote --- Landed as https://sourceware.org/git/?p=valgrind.git;a=commit;h=441bfc5f51c7f5f80cc6491d23cbe2dc711d191f -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 402369] Overhaul DHAT
https://bugs.kde.org/show_bug.cgi?id=402369 --- Comment #10 from Nick Nethercote --- > I think the order of the Sort Metrics in the documentation should match that > in dh_view.html. I just double-checked; as far as I can tell it does match. Which ones do you think are out of order? > How much work would it be to have a custom sort/filter option in the viewer? That sounds difficult. I'm having trouble even imagining how it would work. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 402369] Overhaul DHAT
https://bugs.kde.org/show_bug.cgi?id=402369 --- Comment #5 from Nick Nethercote --- > It might be interesting to replace the wordFM by an xtree, It may. Nonetheless, I'd rather land the code as-is, because it's a major improvement over the existing DHAT. We can consider optimizations to the implementation later :) -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 402369] Overhaul DHAT
https://bugs.kde.org/show_bug.cgi?id=402369 Nick Nethercote changed: What|Removed |Added Attachment #117020|0 |1 is obsolete|| --- Comment #4 from Nick Nethercote --- Created attachment 117393 --> https://bugs.kde.org/attachment.cgi?id=117393&action=edit patch Here is an updated patch with documentation written. I think this is ready to land. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 402369] Overhaul DHAT
https://bugs.kde.org/show_bug.cgi?id=402369 --- Comment #2 from Nick Nethercote --- If you want to try it out easily: - save the attached file - visit http://njn.valgrind.org/dh_view.html and load the saved file. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 402369] Overhaul DHAT
https://bugs.kde.org/show_bug.cgi?id=402369 --- Comment #1 from Nick Nethercote --- Created attachment 117022 --> https://bugs.kde.org/attachment.cgi?id=117022&action=edit Sample output file Here is output from a run of the Rust compiler under DHAT. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 402369] New: Overhaul DHAT
https://bugs.kde.org/show_bug.cgi?id=402369
Bug ID: 402369
Summary: Overhaul DHAT
Product: valgrind
Version: unspecified
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: callgrind
Assignee: josef.weidendor...@gmx.de
Reporter: n.netherc...@gmail.com
Target Milestone: ---
Created attachment 117020
--> https://bugs.kde.org/attachment.cgi?id=117020&action=edit
patch
I have totally overhauled DHAT. The current version is useful, but has some
annoyances and deficiencies. The new version is much better. I have used
extensively on the Rust compiler, using it on more than 20 PRs.
The only incomplete part is that I haven't updated the documentation. I plan to
do that just before landing, so that if I get feedback about the UI that causes
me to change the output I don't need to update the docs again.
What follows is the commit message, which describes the changes.
Overhaul DHAT.
This commit thoroughly overhauls DHAT, moving it out of the
"experimental" ghetto. It makes moderate changes to DHAT itself,
including dumping profiling data to a JSON format output file. It also
implements a new data viewer (as a web app, in dhat/dh_view.html).
The main benefits over the old DHAT are as follows.
- The separation of data collection and presentation means you can run a
program once under DHAT and then sort the data in various ways. Also,
full data is in the output file, and the viewer chooses what to omit.
- The data can be sorted in more ways than previously. Some of these
sorts involve useful filters such as "short-lived" and "zero reads or
zero writes".
- The tree structure view avoids the need to choose stack trace depth.
This avoids both the problem of not enough depth (when records that
should be distinct are combined, and may not contain enough
information to be actionable) and the problem of too much depth (when
records that should be combined are separated, making them seem less
important than they really are).
- Byte and block measures are shown with a percentage relative to the
global count, which helps gauge relative significance of different
parts of the profile.
- Byte and blocks measures are also shown with an allocation rate
(bytes and blocks per million instructions), which enables comparisons
across multiple profiles, even if those profiles represent different
workloads.
- Both global and per-node measurements are taken at the global heap
peak ("At t-gmax"), which gives Massif-like insight into the point of
peak memory use.
- The final/liftimes stats are a bit more useful than the old deaths
stats. (E.g. the old deaths stats didn't take into account lifetimes
of unfreed blocks.)
- The handling of realloc() has changed. The sequence `p = malloc(100);
realloc(p, 200);` now increases the total block count by 2 and the
total byte count by 300. Previously it increased them by 1 and 200.
The new handling is a more operational view that better reflects the
effect of allocations on performance. It makes a significant
difference in the results, giving paths involving reallocation (e.g.
repeated pushing to a growing vector) more prominence.
Other things of note:
- There is now testing, both regression tests that run within the
standard test suite, and viewer-specific tests that cannot run within
the standard test suite. The latter are run by loading
dh_view.html?test=1 in a web browser.
- The commit puts all tool lists in Makefiles (and similar files) in a
consistent order: memcheck, cachegrind, callgrind, helgrind, drd,
massif, dhat, lackey, none; exp-sgcheck, exp-bbv.
- A lot of fields in dh_main.c have been given more descriptive names.
Those names now match those used in dh_view.js.
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 401454] Add a --show-percs option to cg_annotate and callgrind_annotate.
https://bugs.kde.org/show_bug.cgi?id=401454 --- Comment #2 from Nick Nethercote --- Landed as https://sourceware.org/git/?p=valgrind.git;a=commit;h=e6e837752183dd2c0ef00bf687b9fe759bd6553c -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 401454] Add a --show-percs option to cg_annotate and callgrind_annotate.
https://bugs.kde.org/show_bug.cgi?id=401454 --- Comment #1 from Nick Nethercote --- I don't think this will be a controversial change, given that it doesn't change default behaviours. I will land it early next week if there are no objections in the meantime. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 401454] New: Add a --show-percs option to cg_annotate and callgrind_annotate.
https://bugs.kde.org/show_bug.cgi?id=401454
Bug ID: 401454
Summary: Add a --show-percs option to cg_annotate and
callgrind_annotate.
Product: valgrind
Version: unspecified
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: cachegrind
Assignee: n...@valgrind.org
Reporter: n.netherc...@gmail.com
Target Milestone: ---
Created attachment 116523
--> https://bugs.kde.org/attachment.cgi?id=116523&action=edit
patch
Add a --show-percs option to cg_annotate and callgrind_annotate.
Because it's very useful. As part of this, the "percentage of events
annotated" numbers at the bottom of the output is changed to "events
annotated" so that --show-percs doesn't compute a percentage of a
percentage.
Example output lines:
> 4,967,137,442 (100.0%) PROGRAM TOTALS
>
> 4,543 (25.23%)17,566 ( 0.43%)47,993 ( 0.92%)
> /build/glibc-OTsEL5/glibc-2.27/elf/dl-lookup.c
>
> 1 ( 0.01%) 2,000,001 (49.29%) 3,000,004 (57.36%) for (int i = 0; i <
> 100; i++) {
The commit also adds some much-needed tests for cg_annotate and
callgrind_annotate.
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 399301] Use inlined frames in Massif XTree output.
https://bugs.kde.org/show_bug.cgi?id=399301 --- Comment #2 from Nick Nethercote --- Any reason not to land this? I think it's ready. It's a simple change and a clear improvement. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 399355] Add callgrind_diff
https://bugs.kde.org/show_bug.cgi?id=399355 Nick Nethercote changed: What|Removed |Added Attachment #115396|0 |1 is obsolete|| --- Comment #5 from Nick Nethercote --- Created attachment 115743 --> https://bugs.kde.org/attachment.cgi?id=115743&action=edit Updated version This fixes the problem that Philippe identified. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 399322] Improve callgrind_annotate output
https://bugs.kde.org/show_bug.cgi?id=399322 Nick Nethercote changed: What|Removed |Added Blocks|399355 | Referenced Bugs: https://bugs.kde.org/show_bug.cgi?id=399355 [Bug 399355] Add callgrind_diff -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 399355] Add callgrind_diff
https://bugs.kde.org/show_bug.cgi?id=399355 Nick Nethercote changed: What|Removed |Added Depends on|399322 | Referenced Bugs: https://bugs.kde.org/show_bug.cgi?id=399322 [Bug 399322] Improve callgrind_annotate output -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 399355] Add callgrind_diff
https://bugs.kde.org/show_bug.cgi?id=399355 Bug 399355 depends on bug 399322, which changed state. Bug 399322 Summary: Improve callgrind_annotate output https://bugs.kde.org/show_bug.cgi?id=399322 What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 399322] Improve callgrind_annotate output
https://bugs.kde.org/show_bug.cgi?id=399322 Nick Nethercote changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |FIXED Depends on|399301 | --- Comment #2 from Nick Nethercote --- Landed as https://sourceware.org/git/?p=valgrind.git;a=commitdiff;h=331949c1c5cf78909a50c6b3559f36d9dcdeea79 Referenced Bugs: https://bugs.kde.org/show_bug.cgi?id=399301 [Bug 399301] Use inlined frames in Massif XTree output. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 399301] Use inlined frames in Massif XTree output.
https://bugs.kde.org/show_bug.cgi?id=399301 Nick Nethercote changed: What|Removed |Added Blocks|399322 | Referenced Bugs: https://bugs.kde.org/show_bug.cgi?id=399322 [Bug 399322] Improve callgrind_annotate output -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 399355] Add callgrind_diff
https://bugs.kde.org/show_bug.cgi?id=399355 --- Comment #4 from Nick Nethercote --- Thank you for the feedback. I will look at the failures next week. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 399355] Add callgrind_diff
https://bugs.kde.org/show_bug.cgi?id=399355 --- Comment #2 from Nick Nethercote --- Is it really worth splitting the patch? I guess you could put the threshold changes in one patch and everything else in another, but it doesn't seem worth the effort. I did the original threshold changes in Cachegrind while writing cg_diff... I don't remember the exact reason (it was a few years ago) but I did the threshold changes in response to the results I was getting from cg_diff. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 399322] Improve callgrind_annotate output
https://bugs.kde.org/show_bug.cgi?id=399322 Nick Nethercote changed: What|Removed |Added Blocks||399355 Referenced Bugs: https://bugs.kde.org/show_bug.cgi?id=399355 [Bug 399355] Add callgrind_diff -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 399355] New: Add callgrind_diff
https://bugs.kde.org/show_bug.cgi?id=399355 Bug ID: 399355 Summary: Add callgrind_diff Product: valgrind Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: callgrind Assignee: josef.weidendor...@gmx.de Reporter: n.netherc...@gmail.com CC: josef.weidendor...@gmx.de, jsew...@acm.org Depends on: 399301, 399322 Target Milestone: --- Created attachment 115396 --> https://bugs.kde.org/attachment.cgi?id=115396&action=edit Add callgrind_diff Cachegrind has cg_diff, and it's useful. Callgrind should have callgrind_diff too. Referenced Bugs: https://bugs.kde.org/show_bug.cgi?id=399301 [Bug 399301] Use inlined frames in Massif XTree output. https://bugs.kde.org/show_bug.cgi?id=399322 [Bug 399322] Improve callgrind_annotate output -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 399301] Use inlined frames in Massif XTree output.
https://bugs.kde.org/show_bug.cgi?id=399301 Nick Nethercote changed: What|Removed |Added Blocks||399355 Referenced Bugs: https://bugs.kde.org/show_bug.cgi?id=399355 [Bug 399355] Add callgrind_diff -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 399301] Use inlined frames in Massif XTree output.
https://bugs.kde.org/show_bug.cgi?id=399301 Nick Nethercote changed: What|Removed |Added Blocks||399322 Referenced Bugs: https://bugs.kde.org/show_bug.cgi?id=399322 [Bug 399322] Improve callgrind_annotate output -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 399322] New: Improve callgrind_annotate output
https://bugs.kde.org/show_bug.cgi?id=399322 Bug ID: 399322 Summary: Improve callgrind_annotate output Product: valgrind Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: callgrind Assignee: josef.weidendor...@gmx.de Reporter: n.netherc...@gmail.com CC: jsew...@acm.org Depends on: 399301 Target Milestone: --- Created attachment 115370 --> https://bugs.kde.org/attachment.cgi?id=115370&action=edit Improve callgrind_annotate output callgrind_annotate doesn't insert commas in call counts, and it doesn't sort the caller/callee lists in the call tree. The attached patch fixes both of these problems. Referenced Bugs: https://bugs.kde.org/show_bug.cgi?id=399301 [Bug 399301] Use inlined frames in Massif XTree output. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 399301] New: Use inlined frames in Massif XTree output.
https://bugs.kde.org/show_bug.cgi?id=399301 Bug ID: 399301 Summary: Use inlined frames in Massif XTree output. Product: valgrind Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: jsew...@acm.org Reporter: n.netherc...@gmail.com Target Milestone: --- Created attachment 115360 --> https://bugs.kde.org/attachment.cgi?id=115360&action=edit Use inlined frames in Massif XTree output DHAT can show inlined frames, but Massif currently can't. The attached patch fixes this. I have tested that it works on the Rust compiler, which was my motivating example: see https://github.com/rust-lang/rust/issues/52028#issuecomment-402409368, especially the part "Massif doesn't get great stack traces due to inlining, but DHAT does a better job by using debuginfo." -- You are receiving this mail because: You are watching all bug changes.
