https://bugs.kde.org/show_bug.cgi?id=473695
Milian Wolff <m...@milianw.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REPORTED |CONFIRMED
Ever confirmed|0 |1
--- Comment #1 from Milian Wolff <m...@milianw.de> ---
with dart installed from the arch package I get this:
```
$ heaptrack dart main.dart
heaptrack output will be written to "/home/milian/heaptrack.dart.8966.zst"
starting application, this might take some time...
Hello
# it hangs here
```
it hangs because it waits for $something to write to the pipe and then close
it, but that never happens - our injection works but nothing ever calls any of
the functions we intercept.
it seems that's b/c dart uses `tc_malloc` instead of malloc, which somehow
messes with our interception logic. I.e. with `gdb` I get:
```
$ gdb main.exe
(gdb) break malloc
(gdb) r
Breakpoint 1.1, 0x0000555555a28944 in tc_malloc ()
(gdb) bt
#0 0x0000555555a28944 in tc_malloc ()
#1 0x00007ffff7c43bc0 in ?? () from /usr/lib/libc.so.6
#2 0x0000555555783604 in MallocExtension::Initialize() ()
#3 0x0000555555778e13 in ?? ()
#4 0x00007ffff7c27dfe in __libc_start_main () from /usr/lib/libc.so.6
#5 0x0000555555751be5 in _start ()
```
and indeed, this is pretty strange:
```
$ nm -aD main.exe | grep malloc
00000000004d4940 T __libc_malloc
00000000004d4940 T malloc
00000000004d4940 T tc_malloc
```
note how these _all_ have the same address. I tried to intercept `tc_malloc`
like we do for `mi_malloc` but that doesn't work apparently...
--
You are receiving this mail because:
You are watching all bug changes.
