FlightGear Newsletter April 2014: Difference between revisions

Jump to navigation Jump to search
m
Line 92: Line 92:
[http://sourceforge.net/p/flightgear/mailman/message/32183541/] [http://sourceforge.net/p/flightgear/mailman/message/32185064/] [http://sourceforge.net/p/flightgear/mailman/message/32185188/] [http://sourceforge.net/p/flightgear/mailman/message/32185412/] [http://sourceforge.net/p/flightgear/mailman/message/32185690/] [http://sourceforge.net/p/flightgear/mailman/message/32185691/] [http://sourceforge.net/p/flightgear/mailman/message/32185923/]
[http://sourceforge.net/p/flightgear/mailman/message/32183541/] [http://sourceforge.net/p/flightgear/mailman/message/32185064/] [http://sourceforge.net/p/flightgear/mailman/message/32185188/] [http://sourceforge.net/p/flightgear/mailman/message/32185412/] [http://sourceforge.net/p/flightgear/mailman/message/32185690/] [http://sourceforge.net/p/flightgear/mailman/message/32185691/] [http://sourceforge.net/p/flightgear/mailman/message/32185923/]


=== How to troubleshoot FlightGear crashes ===
The recent 2 release cycles have made one thing pretty obvious: more and more end-users are faced with obscure crashes, so called "segfaults" - unfortunately, developers cannot easily reproduce those in most cases. Thus, we need our contributors to provide better diagnostics. However, the process isn't exactly straightforward for non-developers, but at least Linux-based users can typically provide all the required information even without having to be programmers themselves.
A segfault is another word for "application crash", it's a so called "segmentation fault", where the FlightGear program is doing things that it wasn't designed to do, such as accessing invalid memory for example, so that the operating system will terminate the process because its behavior is no longer valid/correct.
These segfaults will typically happen due to coding errors, either in FlightGear or one of its dependencies (libraries like SimGear, plib, OpenSceneGraph or OpenAL), and at times due to a combination of issues in several dependencies.
In order to see what was going on when the crash occurred, you'll need to build a binary with debugging symbols enabled/included, usually this includes FlightGear and SimGear - and possibly even OSG (OpenSceneGraph, normally only if your crash happens inside rendering related code).
A so called backtrace is basically pretty much like a flight data recorder tape/log that is used to conduct a post-crash analysis.
A binary with debugging symbols included will contain additional information that helps developers track down what was causing a certain crash, such as for example the file name, function, line number, variable that was accessed before the crash happened. This is analogous to how a FDR/CVR on an airplane records certain parameters like position, orientation, altitude, velocities, configuration, cockpit conversations etc. This can also be used by developers to see who is responsible for a certain segfault/bug, i.e. which commit introduced the bug.
Debugging FlightGear crashes is significantly simplified by having access to such runtime data, because we can basically go back in time and see what the FlightGear program was doing shortly before the crash.
Learn more at [[Howto:Debugging FlightGear Crashes#Debugging_Segfaults_.26_Obtaining_Backtraces|Debugging Segfaults & Obtaining Backtraces]]...
=== Under the Hood of: Nasal OOP (by Philosopher & galvedro) ===
=== Under the Hood of: Nasal OOP (by Philosopher & galvedro) ===


Line 124: Line 140:


Continue reading at [[Object oriented programming in Nasal]]...
Continue reading at [[Object oriented programming in Nasal]]...


===Orbital Rendering:Earthview ===
===Orbital Rendering:Earthview ===

Navigation menu