Using a local build with a local server configured as: --------------- ; SymbolPaths is generally the only section Windows users care to modify. ; This section lists the directories snappy looks for local symbols. [SymbolPaths] Firefox = c:\Mozilla\src\mozilla-central\_obj-browser-opt\dist\crashreporter-symbols ; properly generated with mach buildsymbols Windows = c:\Symbols ; where visual studio downloads symbols, but this is useless anyway (.pdb != .sym) Thunderbird = [General] hostname = 0.0.0.0 portNumber = 8004 ; If any symbols of interest aren't available locally (e.g. Windows DLLs), ; this forwards request to the official Mozilla symbol server ;remoteSymbolServer = http://symbolapi.mozilla.org:80/ ; it's always down... [MemoryCache] maxMemCacheFiles = 0 [DiskCache] diskCachePath = %(TEMP)s\snappy\cache maxDiskCacheFiles = 0 [Log] maxFiles = 10 maxFileSize = 1048576 logPath = %(TEMP)s\log\snappy ; Valid settings: CRITICAL, ERROR, WARNING, INFO, DEBUG, NOTSET logLevel = DEBUG [SymbolURLs] MozillaS3 = https://s3-us-west-2.amazonaws.com/org.mozilla.crash-stats.symbols-public/v1/ ---------------- Callgraph shows method names correctly for GeckoMain (and other chrome process threads I enabled) but not for Content (=main thread of plugin-container.exe). Is this expected? Or is it a bug in the symbolication worker? For reference, the only change I've made to the GeckoProfiler extension is just this: https://github.com/mayhemer/Gecko-Profiler-Addon/commit/d0700d7f31fd94af8ed167e17eeef6b98b8b571d

It's expected to work. Last I checked it was working on windows but I can't check since the server is down.