Towards better troubleshooting: Difference between revisions
Line 13: | Line 13: | ||
These will typically require changes on the C++ side, but would still be good to have whenever someone makes a bug report: | These will typically require changes on the C++ side, but would still be good to have whenever someone makes a bug report: | ||
* for better diagnostics, and better [[Subsystem-level Memory Tracking for FlightGear|end-user bug reports]], we could consider exposing a cross-platform process and system utilities module via [[Nasal/CppBind]], such as e.g. [https://github.com/giampaolo/psutil psutil] (Windows, MacOS & BSD/Unix) {{Not done}} | |||
* expose scenery version info [http://forum.flightgear.org/viewtopic.php?f=25&t=22288&p=202503#p202503] {{Not done}} | * expose scenery version info [http://forum.flightgear.org/viewtopic.php?f=25&t=22288&p=202503#p202503] {{Not done}} | ||
* expose all startup arguments (would just be copied to a single property) {{Not done}} | * expose all startup arguments (would just be copied to a single property) {{Not done}} |
Revision as of 19:23, 12 July 2014
Note This place is supposed to keep track of all the ideas that we usually come up with after each release to improve the quality of end-user bug reports. It mostly boils down to showing additional information in the about dialog, or including it in the startup log file created in $FG_HOME, or maybe even making it available in the new crash reporting tool eventually. Most of these are fairly trivial to implement, it just seems that we don't typically have a need for them until someone shows up having a real problem who is not able to build from source... |
You may also want to check out the Helping users in the long term
Trivial
These are already available in the property tree, i.e. just requires editing about.xml:
- expose threading mode Not done
- expose renderer mode (classic vs. rembrandt / osgEarth) Not done
- expose availability of Built-in Profiler Not done
Core changes
These will typically require changes on the C++ side, but would still be good to have whenever someone makes a bug report:
- for better diagnostics, and better end-user bug reports, we could consider exposing a cross-platform process and system utilities module via Nasal/CppBind, such as e.g. psutil (Windows, MacOS & BSD/Unix) Not done
- expose scenery version info [1] Not done
- expose all startup arguments (would just be copied to a single property) Not done
- expose complete content of fgfsrc (could be read into the property tree) Not done
- expose cmake/compiler flags Not done
- expose release/debug build info (osg,simgear & fg) Not done
- expose architecture (32bit/64 bit) e.g. via __i386__ and __x86_64__ on Intel or via cmake [2] Not done
- expose amount of physical RAM available Not done
- expose amount of used RAM Not done
- expose degree of swapping Not done
- provide some means to show GLSL errors in a dedicated place, i.e. the loglist ? Not done
- maybe provide an option to attach the startup log file to a flight recorder "tape" so that people can more easily share reproducible flights ?
- keep track of Nasal callbacks running via timers/listeners and maintain a list of origin (FILE/LINE, handle/identifier) so that we can inspect a list of "Nasal processes" [3]
- investigate providing support for Nasal backtraces across timers/listeners as per Philosopher's posting [4]
Runtime stuff
- provide a switch to enable/disable updating of canvas/groups on/off (or placements?), to help with troubleshooting
- Investigate extending Canvas::Element to optionally keep track of memory required for each element (use/sub-class osg::ref_ptr), so that we can provide some runtime info Not done
- Provide a means to list all running Nasal callbacks invoked via timers/listeners[5] Not done
- Extend FGStatsHandler to expose Nasal GC stats via osg::StatsHandler Not done
The built-in osgviewer stats can be extended with custom stats, that works by subclassing osg::StatsHandler, this is already done in $FG_SRC/Viewer/FGEventHandler.?xx The class can be extended to add your own stats via osgViewer::StatsHandler::addUserStatsLine() |
- Canvas::Element/Canvas::Group should be extended to gather SGTimeStamp-based stats for each group/element, so that people can better tell what's going on behind the scenes [6] Not done
- use a separate draw mask for cockpit panels (e.g. via a corresponding XML attribute that serves as a marker), so that the impact of heavy cockpits can be better evaluated Not done
- whenever there's an exception while booting, we should try to re-init the sim and increase the log level to provide crashrpt with better info [7]