mstange / samply

Command-line sampling profiler for macOS and Linux
Apache License 2.0
2.23k stars 56 forks source link

Can no longer find debug symbols after macOS 15 sequoia upgrade #389

Open byroot opened 16 hours ago

byroot commented 16 hours ago

My knowledge about linkers and such is extremely limited, so I'm afraid I won't be able to give a very detailed bug report.

I'm an happy use of samply on macOS, and I've been using it a lot to profile native Ruby gems, such as https://github.com/ruby/json. However, since I upgraded my machine to macOS 15 (Sequoia), it's no longer able to find symbols for the compiled bundle, so it makes the profiler pretty much unusable.

Since I have another machine still on macOS 14, I did look at possible differences. On the old machine when recording with --verbose I see two files being opened that aren't on macOS 15:

Opening file "/Users/byroot/src/github.com/ruby/json/ext/json/ext/generator.bundle"
Opening file "/Users/byroot/src/github.com/ruby/json/ext/json/ext/generator/generator.o"

From some googling around, it seems like Apple made some change to how they generate/store debug symbols, now you're supposed to read them from a .bundle.dSYM directory?

Looking at the files generated by clang, it looks like this:

./ext/json/ext/generator.bundle
./ext/json/ext/generator/generator.o
./ext/json/ext/generator/generator.bundle.dSYM
./ext/json/ext/generator/generator.bundle.dSYM/Contents
./ext/json/ext/generator/generator.bundle.dSYM/Contents/Resources
./ext/json/ext/generator/generator.bundle.dSYM/Contents/Resources/Relocations
./ext/json/ext/generator/generator.bundle.dSYM/Contents/Resources/Relocations/aarch64
./ext/json/ext/generator/generator.bundle.dSYM/Contents/Resources/Relocations/aarch64/generator.bundle.yml
./ext/json/ext/generator/generator.bundle.dSYM/Contents/Resources/DWARF
./ext/json/ext/generator/generator.bundle.dSYM/Contents/Resources/DWARF/generator.bundle
./ext/json/ext/generator/generator.bundle.dSYM/Contents/Info.plist

The .o still exists, but samply no longer tries to open it.

mstange commented 6 hours ago

I can reproduce this locally. Example profile: https://share.firefox.dev/3YtKZuF

I think the problem is on the sampling side, not on the symbolication side. Looking into it.

mstange commented 5 hours ago

If I attach to the process with lldb, it has these five modules at the end of image list:

[299] 4FA2B384-8C96-3984-B984-A8461E6096AD 0x0000000100134000 /opt/homebrew/Cellar/ruby/3.3.5/lib/ruby/3.3.0/arm64-darwin24/enc/encdb.bundle 
[300] A0818C55-9967-3749-B96E-4F1F3FAD7F82 0x0000000100160000 /opt/homebrew/Cellar/ruby/3.3.5/lib/ruby/3.3.0/arm64-darwin24/enc/trans/transdb.bundle 
[301] 4E8F8FC3-B7BE-30EC-8E63-097984739A20 0x0000000100450000 /opt/homebrew/Cellar/ruby/3.3.5/lib/ruby/3.3.0/arm64-darwin24/monitor.bundle 
[302] 8F171032-37BE-3928-88A6-23AECBDEE568 0x00000001000a0000 /opt/homebrew/lib/ruby/gems/3.3.0/gems/json-2.7.2/lib/json/ext/parser.bundle 
[303] 0D550828-F949-3239-B400-3F9D82D87934 0x0000000100480000 /opt/homebrew/lib/ruby/gems/3.3.0/gems/json-2.7.2/lib/json/ext/generator.bundle 

However, in my enumerate_dyld_images function, I get 0 for both imageLoadAddress and imageFilePath for these last five modules. I haven't found out why yet.