|
|
| (10 intermediate revisions by 2 users not shown) |
| Line 1: |
Line 1: |
| {{FeatureStatus
| | The Snappy Symbolication Server is a Web server for symbolicating Firefox stacks. It matches PC addresses to modules in memory and looks up the corresponding function names in server-side symbol files (.SYM files). |
| |Feature name=Snappy Symbolication Server
| |
| |Feature stage=Feature Inbox
| |
| |Feature status=In progress
| |
| |Feature version=Nightly 14
| |
| |Feature health=OK
| |
| }}
| |
| {{FeatureTeam
| |
| |Feature feature manager=bsmedberg
| |
| |Feature lead engineer=vladan
| |
| |Feature additional members=benwa, ehsan
| |
| }}
| |
| {{FeaturePageBody
| |
| |Feature overview=In nightly profiling builds (and perhaps later in regular nightlies and aurora) we want to give users the ability to profile their own slowness via an about:snappy page. We also want to submit significant chrome hangs to telemetry.
| |
| |Feature users and use cases=In order to make this useful, the reports need to be able to map stack traces to symbols, similarly to how crash-stats does this. However, we're not taking full minidumps for privacy reasons, so we want to expose a webservice based on crash-stats symbol data that can convert address/offset information to a symbolicated name.
| |
|
| |
|
| There will be two users of this data:
| | The documentation for Snappy no longer lives here. It can be found in the [https://github.com/mozilla/Snappy-Symbolication-Server/blob/master/README.md Readme on Snappy's GitHub] |
| | |
| 1) the telemetry server will use this to convert numeric stacks into symbols
| |
| 2) the client page about:snappy will use this to convert numeric stacks into symbols
| |
| |Feature functional spec=Stack data will be submitted to the server in JSON format and will be returned in JSON format. Details TBD as we iterate.
| |
| | |
| |Feature implementation plan=
| |
| # get a VM for experimentation/development with access to the symbol data and node COMPLETE
| |
| # develop the webservice behind the firewall INITIAL CODE COMPLETE, NEEDS REVISION FOR DIRECT SYMBOL ACCESS - The code is currently hosted at https://github.com/bgirard/ProfilerSymbolServer
| |
| # After development is complete, open up the webservice via a public URL
| |
| | |
| Note that the plan has changed and the server has now been rewritten in Python with extended functionality: https://github.com/vdjeric/Snappy-Symbolication-Server/
| |
| | |
| |Feature security review=
| |
| Hopefully minimal security review will be required. The webservice can run with readonly mounts in an isolated environment and should not have any private or persistent data.
| |
| https://wiki.mozilla.org/Security/Reviews/SnappySymbolSrv
| |
| | |
| |Feature privacy review=
| |
| No private information will be processed.
| |
| https://wiki.mozilla.org/Privacy/Reviews/SnappySymbolicServer
| |
| }}
| |
| {{FeatureInfo
| |
| |Feature priority=Unprioritized
| |
| |Feature theme=Performance
| |
| |Feature roadmap=Platform
| |
| |Feature list=Platform
| |
| |Feature project=Responsiveness
| |
| }}
| |
| {{FeatureTeamStatus
| |
| |Feature security status=sec-review-sched
| |
| |Feature security notes=2012.03.02
| |
| }}
| |
| | |
| == Regressions tests ==
| |
| | |
| * Perform a get request to the server
| |
| * Check if the IP in X-Forward-For is logged
| |
| * Test requests with /gecko-profiler/ path
| |
| * Test for /debug and /nodebug special paths
| |
| * Test with compressed symbols files
| |
| * Exiting with Control-C should kill the server smoothly
| |
| * Check if the host handles ill-formed requests
| |
| * Check if symbol server can forward requests
| |
| * Parse a symbol file, exit and start the server again. The server should fetch the sym file from cache
| |
| * Check if the server writes logs to files
| |