Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
W
weston
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 273
    • Issues 273
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 117
    • Merge Requests 117
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • wayland
  • weston
  • Issues
  • #144

Closed
Open
Opened 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
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: wayland/weston#144