: New feature! MozillaWiki is now mobile-friendly. Visit from a mobile device to see new mobile theme + try editing. Release details.

Snappy Symbolication Server

From MozillaWiki
Jump to: navigation, search
Please use "Edit with form" above to edit this page.


Snappy Symbolication Server
Stage Feature Inbox
Status In progress
Release target Nightly 14
Health OK
Status note `


Product manager `
Directly Responsible Individual bsmedberg
Lead engineer vladan
Security lead `
Privacy lead `
Localization lead `
Accessibility lead `
QA lead `
UX lead `
Product marketing lead `
Operations lead `
Additional members benwa, ehsan

Open issues/risks


Stage 1: Definition

1. 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.

2. Users & 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:

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

3. Dependencies


4. Requirements




Stage 2: Design

5. Functional specification

Stack data will be submitted to the server in JSON format and will be returned in JSON format. Details TBD as we iterate.

6. User experience design


Stage 3: Planning

7. Implementation plan

  1. get a VM for experimentation/development with access to the symbol data and node COMPLETE
  2. 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
  3. 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/

8. Reviews

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

Privacy review

No private information will be processed. https://wiki.mozilla.org/Privacy/Reviews/SnappySymbolicServer

Localization review




Quality Assurance review


Operations review


Stage 4: Development

9. Implementation


Stage 5: Release

10. Landing criteria


Feature details

Priority Unprioritized
Rank 999
Theme / Goal Performance
Roadmap Platform
Secondary roadmap `
Feature list Platform
Project Responsiveness
Engineering team `

Team status notes

  status notes
Products ` `
Engineering ` `
Security sec-review-sched 2012.03.02
Privacy ` `
Localization ` `
Accessibility ` `
Quality assurance ` `
User experience ` `
Product marketing ` `
Operations ` `

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