https://bugs.kde.org/show_bug.cgi?id=428689
--- Comment #4 from Milian Wolff <m...@milianw.de> --- I think it's more reliable to query for the size of the type size using GDB directly, as accessing the function parameters of inlined frames would not be possible in a release build - and the allocator will most probably get inlined. I mean you can do that in GDB: ``` (gdb) p sizeof(Foo) $1 = 16 ``` Before we'd try to get that information though I'd like to port heaptrack away from libbacktrace to elfutils instead, as I don't think getting that information would be easily possible with libbacktrace or libdwarf directly. Furthermore, note how this common case cannot be handled without parsing the actual *source code*: ``` struct Foo { int a; char b; double c; }; int main() { auto b = new Foo[100]; return 0; }; ``` GDB shows this backtrace in a debug build: ``` #0 0x00007ffff7b0fc90 in malloc () from /usr/lib/libc.so.6 #1 0x00007ffff7e5053a in operator new (sz=1600) at /build/gcc/src/gcc/libstdc++-v3/libsupc++/new_op.cc:50 #2 0x000055555555579b in main () at test.cpp:4 ``` We don't know the type nor the number of elements :( -- You are receiving this mail because: You are watching all bug changes.