User:Callahanp/Flightgear and Simgear Code/From Command Line to Holding Short: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
(Created page with " Recently I began the effort to fully understand the skills needed to contribute to the Flightgear project's codebase. I know c++ from a course in the early 90's. I'm lookin...")
 
mNo edit summary
(8 intermediate revisions by 2 users not shown)
Line 1: Line 1:


Recently I began the effort to fully understand the skills needed to contribute to the Flightgear project's codebase.  I know c++ from a course in the early 90's.  I'm looking at Kdevelop and QTquick as development tools.
This page covers initialization in flightgear, from the command line through the Splash Page to the first frame of the aircraft in position.


=== Flightgear Codebase ===
I started by stepping through bootstrap and other modules until flightgear is up and running and the aircraft is visible holding short in a parking area, holding short or placed on a runway.
I'm made some notes, organized by source code file and function.  The result is the information below.


My area of interest is in Flightgear's code includes:
It is important to know that this is an area that as of March 2018 is under active discussion on the mailing list.  '''See [https://sourceforge.net/p/flightgear/mailman/message/36261734/  Edward d'Auvergne's e-mail on testing]'''  Some of what is written below needs to be reviewed and changed.  These changes are underway.


* telnet
Follow up discussions regarding subsystems on the flightgear-devel mailing list have resulted in changes to the way subsystems are constructed and initialized.
* phi
* reset & re-initialize
* any method to set or get a property
* the property tree itself
* configuration files
* command line parameters
 
I'm beginning to look through various parts of the Flightgear code-base to understand how the parts fit together and how supporting libraries are used in the project.  I'd like to learn how aircraft data and graphics are integrated into the working program, and how, why and where Nasal scripting is used.  To this end, I have
* Built a full debug version of the next branch
* Installed
** [https://gdbgui.com/ gdbgui]
** [https://atom.io/ atom] for basic code exploration.
 
Later I'll try QtCreator
 
 
I start by stepping through bootstrap and other modules until flightgear is up and running.
I'm making some notes.  There are three sections:
 
* '''Path''' will trace the path through modules that provide significant functionality to the Simulator until the aircraft is shown holding short or parked somewhere. only the module's source path and a brief explanation or list of why it's on the "path".
* '''Modules''' lists all the classes and methods or functions executed on the "path" as well as those that are not executed in the path.
* '''Utility Calls''' will contain notes on various library calls, noting what the call looks like, where the library comes from, what the call does and where else it might be used. These will be functions with a purpose that is not limited to flight simulation.


====From Command Line to Holding Short====
====From Command Line to Holding Short====
{{See also|Talk:Initializing_Nasal_early#Existing_Initialization_Scheme}}


When you start flight gear, several activities take place
When you start flight gear, several activities take place
Line 45: Line 25:
  * connections to multiplayer servers are made
  * connections to multiplayer servers are made
  * a scene is established as a "view" with scenery, Airport data and the Aircraft
  * a scene is established as a "view" with scenery, Airport data and the Aircraft
  * an event loop is started to adjust the view based on changes in controls, weather, aircraft position and attitude
  * an event loop is started to finish the initialization, display a splash screen.  The event loop then shows the first frame and then adjust the view as time goes on, based on changes in controls, weather, aircraft position, speed, attitude and time.
 
That's a lot, but the orchestration of all this activity takes place in just a few code files and a very few functions in those files.


We'll trace our way through the code, noting the modules, specific functions and highlight specific lines of code that make up this process.  We'll cover both the initial startup and the differences in the initialization process when resetting the application.
There are several key concepts in this startup process:
* C++ Classes
* Class Constructors and Object Construction
* Initialization,
* Binding
* Re-initialization
* Object destruction.
===Overview===
Just to get oriented a little, I'm going to list the top-level routines in the path to holding short.  Initialization happens in four stages, Some stages have very little in them, others have multiple phases and many subsystems to initialize.
{| class="wikitable"
|-
! Startup Stage !! Module !! Routine Signature !! Brief Description
|-
|  1. || Main/bootstrap.cxx || int main(int argc, int char **argv )
|
main() is the first of four stages of initialization in Flightgear.  The first stage ends when main() calls fgMainInit(argc, argv)
main contains the initial entry point and final exit point for the Flightgear application.  It initializes things that have to be done early on and decides if we're starting the full application or just a viewer, then calls fgviewerMain(argc, argv) or fgMainInit(argc, argv).  We'll skip the viewer and focus on fgMainInit. 
|-
| 2. || Main/main.cxx || int fgMainInit( int argc, char **argv )
|
fgMainInit continues with about 20 individual initializations.
fgMainInit is only the second stage of initialization. It ends with an open but blank window, and a call to fgOSMainLoop();
|-
| 3. || Viewer/fg_os_osgviewer.cxx || int fgOSMainLoop()
|
fgOSMainLoop doesn't do initialization itself.  fgOSMainLoop is ''the'' main loop for the full duration of the flightgear session. It's amazingly brief, Just four C++ statements on 12 lines of code. The loop has just two tasks:  Think of them  as "set up what has to be displayed" and "display it".  During initialization, the setup task is initialization.  The second task displays the splash screen, messages produced by the initialization and something that moves to indicate that the program is still working.  Then, after initialization, the setup part of the loop does the calculation work needed for the next frame of the simulation.  The display task then uses that data to show the simulation on the screen.
fgIdleFunction does the initialization work. fgMainLoop() handles the events and calculations for the ongoing simulation. These are called through a pointer named *idlefunc. 
The display part of the loop is the same for both of these "setup" functions.
fgIdleFunction is the third stage of initialization.  During this stage, fgOSMainLoop calls fgIdleFunction repeatedly through *idleFunc.  Each call to fgIdleFunction does a different part of the initialization. In between, the splash screen is being updated, showing which part of the initialization is in progress, and a moving progress bar to show that "something" is happening.
When the third stage is complete, *idleFunc is set to point to fgOSMainLoop.
|-
| 3. || Main/main.cxx || static void fgIdleFunction ( void )
|
fgIdleFunction handles all the third stage initializations in a number of phases. It's main work is the initialization of subsystems. It's called many times, and each phase may do one or many initializations.  There are quite a few and it takes a while.  When fgIdleFunction reaches its last initialization state, it calls registerMainLoop() to change *idleFunction to point to fgMainLoop.  Once fgIdleFunction has completed its work it is not run again unless you do a reset, but the routine that called it, fgOSMainLoop continues to run.
|-
| 4. || main/main.cxx || fgMainLoop
| fgMainLoop does not contain a loop, its running under the loop in fgOSMainLoop and will continue to run in that loop until you reset or exit flightgear.  fgMainLoop handles the fourth and final stage of initialization, waiting on the loading of scenery, the airport and the aircraft data.  All the final initialization work is handled by subsystems loaded in stage three.  Until all subsystems are fully initialized, the splash screen continues to be displayed.  Once they're all ready, the subsystems continue to run, and we find ourselves in position at an airport and ready to fly. 
|}
After initialization all of the subsystems needed to fly will continue to be invoked as needed by fgMainLoop, which is run repeatedly in the actual loop in fgOSMainLoop.
At first glance, one might think that the naming of things in this part of Flightgear is a bit off.  The names might have made sense at one point in the early development of Flightgear, but things have changed and some functionality moved, but the names were not changed.  So we end up with things like fgMainLoop that does not contain a loop.  Does it matter? Probably not.  There's other work to do that's more important.  My guess is that we just need to know how this loop works and most of the time our attention will be much further down the call stack, inside one of those sub-systems.
Question:
What in the code finally recognizes that we're ready to display the scene in stage 4?
Are the final initializations done by subsystems done in any particular order?
Is what's above this point enough to know about startup and initialization?
FGcommands.cxx and fg_scene_commands.cxx contains a number of static functions not called from c++.  are these only called from Nasal?  Is that why they are missing from the .hxx?
Do we need to show some examples of property nodes?
Would a list of functions contained in each of the modules in src/Main be of any use?
For example:
fgCommands.cxx
* static inline SGPropertyNode * get_prop (const SGPropertyNode * arg, SGPropertyNode * root)
* static inline SGPropertyNode * get_prop2 (const SGPropertyNode * arg, SGPropertyNode * root)
* static void split_value (double full_value, const char * mask, double * unmodifiable, double * modifiable)
etc
would the same list with a note on its purpose and usage be of help?
fgCommands.cxx
|
{| class="wikitable"
|-
! function signature || Description
|-
| static inline SGPropertyNode *
get_prop (const SGPropertyNode * arg, SGPropertyNode * root)
|.  gets property[0]
|-
| static inline SGPropertyNode *
get_prop2 (const SGPropertyNode * arg, SGPropertyNode * root)
| gets property[1]
|-
| static void
split_value (
double full_value, const char * mask,
double * unmodifiable, double * modifiable)
| Get a double value and split it as required.
|-
| static void
limit_value (double * value, const SGPropertyNode * arg)
|
|}
The material below are detailed notes from an initial look at the main loop.  They're just lists of what gets done where.  Would a new developer just read the actual functions and make their own notes?
|-
| Clamp or wrap a value as specified.
{| class="wikitable"
{| class="wikitable"
|-
|-
! Module
! Module
! colspan="3" | Description & Steps
! colspan="3" || Description & Steps
|-
|-
| src/Main/bootstrap Main  
| src/Main/bootstrap Main  

Revision as of 02:31, 29 May 2018

This page covers initialization in flightgear, from the command line through the Splash Page to the first frame of the aircraft in position.

I started by stepping through bootstrap and other modules until flightgear is up and running and the aircraft is visible holding short in a parking area, holding short or placed on a runway. I'm made some notes, organized by source code file and function. The result is the information below.

It is important to know that this is an area that as of March 2018 is under active discussion on the mailing list. See Edward d'Auvergne's e-mail on testing Some of what is written below needs to be reviewed and changed. These changes are underway.

Follow up discussions regarding subsystems on the flightgear-devel mailing list have resulted in changes to the way subsystems are constructed and initialized.

From Command Line to Holding Short

When you start flight gear, several activities take place

* logging is set up
* command line arguments are checked, read and saved
* a global object is created to hold state and references to managing functions of several types
* a tree of properties is built on the global object
* various static objects are created and initialized
* scenery data is downloaded using terrasync
* airport and aircraft data is scanned and made available
* scenery data is read and made available
* an interpreter is started
* connections to multiplayer servers are made
* a scene is established as a "view" with scenery, Airport data and the Aircraft
* an event loop is started to finish the initialization, display a splash screen.  The event loop then shows the first frame and then adjust the view as time goes on, based on changes in controls, weather, aircraft position, speed, attitude and time.

That's a lot, but the orchestration of all this activity takes place in just a few code files and a very few functions in those files.

We'll trace our way through the code, noting the modules, specific functions and highlight specific lines of code that make up this process. We'll cover both the initial startup and the differences in the initialization process when resetting the application.

There are several key concepts in this startup process:

  • C++ Classes
  • Class Constructors and Object Construction
  • Initialization,
  • Binding
  • Re-initialization
  • Object destruction.

Overview

Just to get oriented a little, I'm going to list the top-level routines in the path to holding short. Initialization happens in four stages, Some stages have very little in them, others have multiple phases and many subsystems to initialize.

Startup Stage Module Routine Signature Brief Description
1. Main/bootstrap.cxx int main(int argc, int char **argv )

main() is the first of four stages of initialization in Flightgear. The first stage ends when main() calls fgMainInit(argc, argv)

main contains the initial entry point and final exit point for the Flightgear application. It initializes things that have to be done early on and decides if we're starting the full application or just a viewer, then calls fgviewerMain(argc, argv) or fgMainInit(argc, argv). We'll skip the viewer and focus on fgMainInit.

2. Main/main.cxx int fgMainInit( int argc, char **argv )

fgMainInit continues with about 20 individual initializations. fgMainInit is only the second stage of initialization. It ends with an open but blank window, and a call to fgOSMainLoop();

3. Viewer/fg_os_osgviewer.cxx int fgOSMainLoop()

fgOSMainLoop doesn't do initialization itself. fgOSMainLoop is the main loop for the full duration of the flightgear session. It's amazingly brief, Just four C++ statements on 12 lines of code. The loop has just two tasks: Think of them as "set up what has to be displayed" and "display it". During initialization, the setup task is initialization. The second task displays the splash screen, messages produced by the initialization and something that moves to indicate that the program is still working. Then, after initialization, the setup part of the loop does the calculation work needed for the next frame of the simulation. The display task then uses that data to show the simulation on the screen.

fgIdleFunction does the initialization work. fgMainLoop() handles the events and calculations for the ongoing simulation. These are called through a pointer named *idlefunc. The display part of the loop is the same for both of these "setup" functions.

fgIdleFunction is the third stage of initialization. During this stage, fgOSMainLoop calls fgIdleFunction repeatedly through *idleFunc. Each call to fgIdleFunction does a different part of the initialization. In between, the splash screen is being updated, showing which part of the initialization is in progress, and a moving progress bar to show that "something" is happening. When the third stage is complete, *idleFunc is set to point to fgOSMainLoop.

3. Main/main.cxx static void fgIdleFunction ( void )

fgIdleFunction handles all the third stage initializations in a number of phases. It's main work is the initialization of subsystems. It's called many times, and each phase may do one or many initializations. There are quite a few and it takes a while. When fgIdleFunction reaches its last initialization state, it calls registerMainLoop() to change *idleFunction to point to fgMainLoop. Once fgIdleFunction has completed its work it is not run again unless you do a reset, but the routine that called it, fgOSMainLoop continues to run.

4. main/main.cxx fgMainLoop fgMainLoop does not contain a loop, its running under the loop in fgOSMainLoop and will continue to run in that loop until you reset or exit flightgear. fgMainLoop handles the fourth and final stage of initialization, waiting on the loading of scenery, the airport and the aircraft data. All the final initialization work is handled by subsystems loaded in stage three. Until all subsystems are fully initialized, the splash screen continues to be displayed. Once they're all ready, the subsystems continue to run, and we find ourselves in position at an airport and ready to fly.

After initialization all of the subsystems needed to fly will continue to be invoked as needed by fgMainLoop, which is run repeatedly in the actual loop in fgOSMainLoop.

At first glance, one might think that the naming of things in this part of Flightgear is a bit off. The names might have made sense at one point in the early development of Flightgear, but things have changed and some functionality moved, but the names were not changed. So we end up with things like fgMainLoop that does not contain a loop. Does it matter? Probably not. There's other work to do that's more important. My guess is that we just need to know how this loop works and most of the time our attention will be much further down the call stack, inside one of those sub-systems.


Question:

What in the code finally recognizes that we're ready to display the scene in stage 4?

Are the final initializations done by subsystems done in any particular order?

Is what's above this point enough to know about startup and initialization?

FGcommands.cxx and fg_scene_commands.cxx contains a number of static functions not called from c++. are these only called from Nasal? Is that why they are missing from the .hxx?

Do we need to show some examples of property nodes?

Would a list of functions contained in each of the modules in src/Main be of any use? For example: fgCommands.cxx

  • static inline SGPropertyNode * get_prop (const SGPropertyNode * arg, SGPropertyNode * root)
  • static inline SGPropertyNode * get_prop2 (const SGPropertyNode * arg, SGPropertyNode * root)
  • static void split_value (double full_value, const char * mask, double * unmodifiable, double * modifiable)

etc

would the same list with a note on its purpose and usage be of help? fgCommands.cxx |

function signature Description
static inline SGPropertyNode *

get_prop (const SGPropertyNode * arg, SGPropertyNode * root)

. gets property[0]
static inline SGPropertyNode *

get_prop2 (const SGPropertyNode * arg, SGPropertyNode * root)

gets property[1]
static void

split_value ( double full_value, const char * mask, double * unmodifiable, double * modifiable)

Get a double value and split it as required.
static void

limit_value (double * value, const SGPropertyNode * arg)

The material below are detailed notes from an initial look at the main loop. They're just lists of what gets done where. Would a new developer just read the actual functions and make their own notes? |- | Clamp or wrap a value as specified.

Module colspan="3" Description & Steps
src/Main/bootstrap Main Bootstrap provides the top level of the stack for executing either fgviewerMain or fgMainInit.
  • Enable Floating Point features with InitFPE
  • Set locale settings specific to using C or C++
  • Uninstall if requested
  • Initialize logging
  • Initialize some static objects in OSG to prevent crashes on exit
  • set the std:: terminate function
  • set the atexit function
  • pass control to the viewer with fgViewerMain or initialize using fgMainInit
  • catch throwables and other fatal error conditions, providing appropriate error messages
src/Main/Main fgMainInit( int argc, char **argv )
  • set logging level and enable logging
  • setup globals as an instance of FGGlobals.
    • see src/Main/globals.cxx constructor FGGlobals::FGGlobals()
  • make sure there's a valid FG_HOME directory and set up logging there
  • set the version & log the version, build type and Jenkins or Hudson build id
  • seed the random number generator
  • set up a few things in globals
  • decide if we're using a launcher
    • see below src/Main/Main.cxx Launcher for details
  • set read-only mode when more than one flightgear instance is found
  • load configuration data
    • see src/Main/Main.cxxfgInitConfig
  • initalize aircraft paths
    • see: src/Main/fg_init.cxx fgInitAircraftPaths and fgInitAircraft
  • create an instance of the addon manager
    • see below src/Add-ons/AddonManager.cxx
  • check that the paths are allowed when they come from an untrusted source
  • create an instance of an embedded resource manager
    • see below simgear::EmbeddedResourceManager createInstance
    • and initFlightGearEmbeddedResources
  • get the preferred language and set the locale
  • initialize the windows/graphics environment
    • see viewer/fg_os_osgviewer.cxx fgosinit(int* argc, char** argv)
  • register fgIdleFunction
    • see fgRegisterIdleHandler in Main/fg_os_common.cxx and fgIdleFUnction in Main/main.cxx
  • Initialize sockets
    • simgear::Socket::initSockets()
  • setup alpha channel for Clouds3D
    • fgOSOpenWindow(true /* request stencil buffer */);
    • fgOSResetProperties();
  • fntInit();
  • globals->get_renderer()->preinit();
  • ATIScreenSizeHack
  • fgOutputSettings();
  • disable the screensaver
  • pass control off to the master event handler
    • See viewer/fg_os_osgviewer.cxx fgOSMainLoop() (next)
  • cleanup
    • frame_signal.clear();
    • fgOSCloseWindow();
    • simgear::clearEffectCache();
    • delete globals;
    • globals = NULL;
  • delete the NavCache here. This will cause the destruction of many cached objects (eg, airports, navaids, runways).
    • delete flightgear::NavDataCache::instance();
  • return to bootstrap.cxx Main return result;
viewer/fg_os_osgviewer.cxx fgOSMainLoop()
  • Release the viewer's context at end of frame hint
    • viewer->setReleaseContextAtEndOfFrameHint(false)
  • If the viewer is not realized yet, realize it. We still see nothing in the window
    • viewer->realize()
here's the loop:
  • get the idle handler
    • fgIdleHandler idleFunc = globals->get_renderer()->getEventHandler()->getIdleHandler();
  • run the idle handler It's not clear what this is. It's either fgMainLoop or fgIdleFunction
    • (*idleFunc)()
  • update the screen
    • globals->get_renderer()->update();
  • timestamp the frame
    • viewer->frame( globals->get_sim_time_sec() );
Main/main.cxx fgIdleFunc
  • normal startup has states 0, 2, 3, 4, 5, 7, 8, 9, 10, 900 1000
  • reset startup has 2000, 2005, 2007, 8, 9, 10, 900, 1000
  • state 1000 sets fgMainLoop as the idle function. a reset sets it back to fgIdleFunc
  • state 0 checks the openGL version and sets video options
    • see checkOpenGLVersion() and fgSetVideoOptions()
  • state 2 sets /sim/rendering/initialized true and initializes terrasync with initTerrasync()
  • state 3 loads nav data
    • fgInitNav()
  • state 4 initalizes scenery, but there's not call here
  • state 5
    • initializes some general items with fgInitGeneral()
    • adds the TimeManager
      • globals->add_new_subsystem<TimeManager>(SGSubsystemMgr::INIT)
    • initializes property based commands
      • fgInitCommands(); and fgInitSceneCommands();
    • registers Subsystem Commands
      • flightgear::registerSubsystemCommands(globals->get_commands());
    • initializes the material manager
      • globals->set_matlib( new SGMaterialLib )
      • simgear::SGModelLib::setPanelFunc(FGPanelNode::load)
  • state 7
    • Initializes Position
      • flightgear::initPosition(); and flightgear::initTowerLocationListener();
    • Initializes somethingin SGModelLib
      • simgear::SGModelLib::init(globals->get_fg_root().local8BitStr(), globals->get_props());
    • initializes the time manager instantiated in state 5
      • auto timeManager = globals->get_subsystem<TimeManager>(); timeManager->init();
  • state 8
  • Create subsystems
    • fgCreateSubsystems(isReset)
  • log the time spent creating subsystems
  • state 9
    • bind subsystems
    • globals->get_subsystem_mgr()->bind();
  • state 10
    • initialize subsystems
      • SGSubsystem::InitStatus status = globals->get_subsystem_mgr()->incrementalInit();
    • remains in state 10 until SGSubsystem::INIT_DONE
  • state 900
    • do what needs doing after systems are initialized
      • fgPostInitSubsystems();
  • state 1000
    • setup OpenGl view Parameters
      • globals->get_renderer()->setupView();
    • resize the window to startup size
      • globals->get_renderer()->resize(x,y)
    • unsure what this does
      • WindowSystemAdapter::getWSA()->windows[0]->gc->add(new simgear::canvas::VGInitOperation() )
  • increment /sim/session
  • State 1000 takes a break and continues with the next call
    • sglog().setStartupLoggingEnabled(false)
  • turns off logging for startup
  • sets sim/scenery loaded to false
  • changes the idle function
    • registerMainLoop();
  • state 2000
    • Reset the application
      • fgStartNewReset();
  • state 2005 same as state 5
  • state 2007 same as state 7

Note fgResetIdleState() sets the state to 2000 and re-registers fgIdleFunction as the idle handler.

Main/main.cxx We seem to have arrived. We're at the hold short point.

Minor functions on the Path to Holding Short

sglog().setLogLevels( SG_ALL, SG_INFO )
sglog().setStartupLoggingEnabled(true); || /simgear/debug/logstream.cxx || Pretty obvious what this does. || What does sglog() actually return?
Module Description Steps
src/Main/globals Provides a global object to contain references to objects and data needed in initializing, running and terminating flightgear
  • Provides global access to
    • the property tree
    • subsystem, event, command and resource manager objects and methods
    • position, current view and aircraft orientation data
    • FG_ROOT and FG_HOME directory paths
    • time, comm channel, waypoint, and user settings data
  • uses foreach from the boost library
<boost/foreach.h> Example
<algorithm> Example Example
std::string version(FLIGHTGEAR_VERSION)
sg_srandom_time();
src/Main/Main.cxxfgInitConfig
src/Main/Main.cxx Launcher
src/Add-ons/AddonManager.cxx addons::AddonManager::createInstance()
initFlightGearEmbeddedResources see file build/flightgear/src/EmbeddedResources/FlightGear-resources.cxx,automatically generated by fgrcc
viewer/fg_os_osgviewer.cxx fgosinit(int* argc, char** argv)
Main/fg_os_common.cxx fgRegisterIdleHandler( & fgIdleFunction
detectSIMD() bootstrap.cxx returns true if the cpu supports sse2.
gethostname(_hostname, 256) unistd.h glibc returns the hostname of your computer
signal(SIGPIPE, SIG_IGN) signal.h directs SIGPIPE to the SIG_IGN signal handler - Portability: use sigaction() instead
signal(SIGSEGV, segfault_handler) signal.h Flightgear formats the message with a backtrace and exits with std:abort()
segfault_handler (int signo) bootstrap.cxx
initFPE(flightgear::Options::checkForArg(argc, argv, "enable-fpe")) main/options.cxx
bootstrap.cxx
checks the command line arguments for the enable-fpe option. Calls InitFPE with the result.
see bootstrap.cxx for more details
signal(SIGFPE, handleFPE) signal.h
bootstrap.cxx
We handle Floating Point Exceptions
setlocale(LC_ALL, "")
setlocale(LC_NUMERIC, "C")
setlocale(LC_COLLATE, "C")
return fgUninstall() fg_init.cxx Command line options are checked to determine if uninstall should be called.
sglog() /simgear/debug/logstream.cxx This initializes the log. see logstream.cxx for details
std::set_terminate(fg_terminate); <exception>
bootstrap.cxx
sets the standard template library terminate routine
atexit(fgExitCleanup) stdlib.h
bootstrap.cxx
registers the given function to be called at normal process termination, either via exit(3) or via return from the program's main(). Functions so registered are called in the reverse order of their registration; no arguments are passed
fgviewerMain(argc, argv) flightgear/Viewer/fgviewer.cxx see viewer topics for details. This is called in bootstrap.cxx if the command line arguments include --viewer
fgMainInit(argc, argv) Main/main.cxx Starts to initialize flightgear. This is called in bootstrap.cxx if command line arguments do not contain --viewer
catch block various termination for most or all errors. Read the end of bootstrap.cxx for more information
flightgear::shutdownQtApp() bootstrap
Qt
Done separately from atexit. see bootstrap.cxx for more information
crInstall(&info)
crUninstall()
CrashRpt.h #if defined(HAVE_CRASHRPT). This only happens on windows.