Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • W weston
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 315
    • Issues 315
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 122
    • Merge requests 122
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • wayland
  • weston
  • Issues
  • #144
Closed
Open
Created Sep 17, 2018 by Daniel Stone@danielsOwner

Post-mortem debugging from assertion failures

#143 describes how to make our assert()s more helpful for users and us upstream trying to triage issues. Often though, the response to a bug report is asking the reporter to re-run the same scenario with more logging information, sometimes with bespoke add-more-logging patches. This might be difficult, especially if the issue only happens intermittently and would require gigabytes of log data to be generated.

Since we already generate log data with the debug infrastructure from #133 (closed), it would be great if we could selectively enable post-mortem debugging where:

  • all (or selected) debug scopes were active all the time regardless of whether or not there was an active streaming client
  • an internal client was created always recording these scopes into a ring buffer
  • on assertion failure, these ring buffers would all be dumped, along with any head information required (e.g. the timeline scope would need to be preceded by a dump of all available objects)
  • to debug things which don't trip asserts (e.g. screen blinks unpleasantly, glitch observed in animations, whatever), a debug hotkey was available which would dump the last available debug data for later analysis

The internal stream 'client' might also be useful for simplifying the implementation of Weston's 'log' scope, and allowing other scopes to be captured. For example, there is no way currently to capture output from the drm-backend during startup.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking