Towards better troubleshooting: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
Line 21: Line 21:
* Expose renderer mode (classic vs. rembrandt / osgEarth) {{Not done}}
* Expose renderer mode (classic vs. rembrandt / osgEarth) {{Not done}}
* Expose availability of [[Built-in Profiler]] {{Not done}}
* Expose availability of [[Built-in Profiler]] {{Not done}}
* show location of $FG_HOME in help/about dialog as a button to open it via file explorer ?


== Core changes ==
== Core changes ==

Revision as of 19:04, 31 October 2015

These are some ideas towards better troubleshooting that we usually come up with after each release to improve the quality of end-user bug reports. 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... 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.

You may also want to check out this post on the forum: Re:Helping users in the long term

Background

Cquote1.png I'm interested in going through the entire fleet to create a new base level that all aircraft will be flyable. I'm not talking about fixing clunky FDMs or incomplete parts, but really basic maintenance - aircraft which start with tonnes of errors, and especially aircraft that cannot be started. If you had a list or could point out a few, that'd be awesome! I know there is tonnes of information in old forum posts about this, but for me it's quicker just to start each up one by one and test. If you do have a good list, maybe it would be good to start a new topic.
— bugman (Sun Apr 26). Looking for aircraft with 'paper cut' bugs.
(powered by Instant-Cquotes)
Cquote2.png

Trivial

These are already available in the property tree, i.e. just requires editing about.xml:

  • Expose threading mode Not done Not done
  • Expose renderer mode (classic vs. rembrandt / osgEarth) Not done Not done
  • Expose availability of Built-in Profiler Not done Not done
  • show location of $FG_HOME in help/about dialog as a button to open it via file explorer ?

Core changes

Screen shot showing the property browser running on Netbook in a patched version of FlightGear with resource tracking support using the cross platform SIGAR library.
Screen shot showing the property browser running on Netbook in a patched version of FlightGear with resource tracking support using the cross platform SIGAR library.
CPU information exposed to the property tree using the SIGAR library


These will typically require changes on the C++ side, but would still be good to have whenever someone makes a bug report:

  • separate OpenGL/GLSL logging/log file for troubleshooting graphics related startup errors rendering FG useless (e.g. faulty drivers) [1]
  • case-sensitive path checking [2]
  • write the current pid (process ID) to the property tree, so that this can be used for debugging purposes (or even just for the suffix of log files) Not done Not done
  • add startup options to override/ignore startup files and trigger a navdb cache rebuild [3] Not done Not done
  • expose number of active timers/listeners[4] Not done Not done
  • introduce a tag for FDM properties to optionally notice listeners being tied to FDM rate, as per [5]
  • provide support for an optional TRACECB (callback) mode where multiple identical callbacks are reported ? Not done Not done
  • we could also provide a property and use it as a "soft limit" for the number of listeners per property before a warning is shown, e.g. ~20-50 ? Not done Not done
Cquote1.png I used two places to check how many Uniforms are created. EDXH (Isle of Helgoland in the North Sea) - barely any scenery; And KSFO with AI Traffic enabled, you know the scenery complexity.At EDXH, the Effect system attaches approx. 1500 Listeners to the property tree but only to 17 unique properties. At KSFO, the Effect system attaches some 10000 Listeners to the property tree - but also only to 17 unique properties. That's with shader quality set to zero (all off).

On my old Laptop, (1.6GHz dual core, GeForce Go 7400, 3Gb RAM) FlightGear has becom barely usable over the last few years. Framerates of max 20 at EDXH and single digits at KSFO.


Cquote2.png
  • Subsystem-level Memory Tracking for FlightGear (RAM/VRAM, CPU/GPU utilization) Not done Not done
  • 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 Not done
  • Nasal callback tracking (timers/listeners) [6]
  • Nasal callback tracing, i.e. identical callbacks being called more than once per frame ?
  • Expose scenery version info [7] [8] Not done Not done
  • Expose all startup arguments (would just be copied to a single property) and log them to the log file [9] Not done Not done
  • Expose complete content of fgfsrc (could be read into the property tree) Not done Not done
  • Expose cmake/compiler flags Not done Not done
  • Expose release/debug build info (osg,simgear & fg) Not done Not done
  • Expose architecture (32bit/64 bit) e.g. via __i386__ and __x86_64__ on Intel or via cmake [10] [11] Not done Not done
  • Expose amount of physical RAM availableNot done Not done
  • Expose amount of used RAMNot done Not done
  • Expose degree of swappingNot done Not done
  • Provide some means to show GLSL errors in a dedicated place, i.e. the loglist ?Not done 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" [12]
  • Investigate providing support for Nasal backtraces across timers/listeners as per Philosopher's posting [13]
  • Extend Initializing Nasal early to provide a startup mode where the Nasal engine will be fully shut-down at run-time for better troubleshooting

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 Not done
  • Provide a means to list all running Nasal callbacks invoked via timers/listeners[14] Not done Not done
  • Extend FGStatsHandler to expose Nasal GC stats via osg::StatsHandler Not done Not done
Cquote1.png 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()

You can even register totally custom stats via osg::Stats

The main suspects in this case are probably 1) scenery, 2) cockpit, 3) Nasal (GC - bottleneck() function in simgear/nasal )
For the Nasal stats, you'll probably want to register them in FGNasalSys::FGNasalSys() by accessing globals->viewer->
That should give you a better idea about what's going on there, and it's been suggested by core developers, too:

http://www.mail-archive.com/flightgear- ... 37823.html

Cquote1.png Another goal is to add more node bits (and a GUI dialog to control them) so

various categories of objects can be disabled during the update pass. This will
mean the direct hit of, say, AI models vs particles vs random trees can be
measured. Of course it won't account for resources (memory, textures) burned by
such things, but would still help different people identify slowness on their
setups.

Cquote2.png

— Hooray (Sun Feb 23). Re: New Aircraft: the Extra500.
(powered by Instant-Cquotes)
Cquote2.png


  • 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 [15] Not done 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 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 [16]