SUMMARY When analyzing a profile in Ubuntu Asahi (Ubuntu on a 13" M2 MacBook Air), it always says "Trace recursion detected - corrupt data file?" and all allocations are reported under "<unresolved function> in ", even though the binary was compiled with `-g` and wasn't stripped. It does record a bunch of different numbers for allocations, so numbers of allocations, leaks, etc. all have seemingly correct values, just all aggregated together. STEPS TO REPRODUCE 1. Install heaptrack in Ubuntu-Asahi 2. `heaptrack <some binary>` 3. Analyze results OBSERVED RESULT "Trace recursion detected - corrupt data file?" and all allocations are reported under "<unresolved function> in " EXPECTED RESULT No corrupted data files and allocations broken out by function. SOFTWARE/OS VERSIONS Heaptrack apt package version: 1.5.0+dfsg1-2ubuntu3 Operating System: Kubuntu 24.10 KDE Plasma Version: 6.1.5 KDE Frameworks Version: 6.6.0 Qt Version: 6.6.2 Kernel Version: 6.12.0-1002-asahi-arm (64-bit) Graphics Platform: Wayland Processors: 4 × Apple Avalanche (M2), 4 × Apple Blizzard (M2) Memory: 22.7 GiB of RAM Graphics Processor: Apple M2 Product Name: Apple MacBook Air (13-inch, M2, 2022) U-Boot Version: 2024.04 ADDITIONAL INFORMATION
does this only happen on asahi-linux? does it happen with all binaries, i.e. also with, let's say, `ls` or `find`? it certainly works fine for me, but I'm neither using ubuntu nor asahi
(In reply to Milian Wolff from comment #1) > does this only happen on asahi-linux? > > does it happen with all binaries, i.e. also with, let's say, `ls` or `find`? > > it certainly works fine for me, but I'm neither using ubuntu nor asahi Yeah, I only see this in Ubuntu Asahi. I haven’t tested with other distros on this hardware, but I use Heaptrack in Ubuntu, Arch, and Rocky just fine on x86 machines. Yes, it happens with every binary I’ve tried.
last time I tried it works fine on arm32 and arm64, so if this is asahi specific then you need to debug it yourself. I have no apple hardware (or intention to get some), so unless you give me an easy way to reproduce it via docker/qemu or the like then there's nothing I can do to help you and you are on your own.
(In reply to Milian Wolff from comment #3) > last time I tried it works fine on arm32 and arm64, so if this is asahi > specific then you need to debug it yourself. I have no apple hardware (or > intention to get some), so unless you give me an easy way to reproduce it > via docker/qemu or the like then there's nothing I can do to help you and > you are on your own. If I clone from github and build it manually it works (both debug and release builds, both the master and 1.5 branches), so I assume it's something with how Ubuntu is building their aarch64 packages. I'll file a bug with them.
(In reply to Daniel Green from comment #4) > (In reply to Milian Wolff from comment #3) > > last time I tried it works fine on arm32 and arm64, so if this is asahi > > specific then you need to debug it yourself. I have no apple hardware (or > > intention to get some), so unless you give me an easy way to reproduce it > > via docker/qemu or the like then there's nothing I can do to help you and > > you are on your own. > > If I clone from github and build it manually it works (both debug and > release builds, both the master and 1.5 branches), so I assume it's > something with how Ubuntu is building their aarch64 packages. I'll file a > bug with them. https://bugs.launchpad.net/ubuntu/+source/kdevelop/+bug/2096816