Patch from Melchior Franz:

It seems that the airport database was changed some day and the End?Flags
changed from floats to strings. The database definition, though, was not
adapted and still created number entries. Reading out these flags led to
access to memory, that was never initialized. While it didn't cause crashes
during normal use, it actually caused one when I ran fgfs in ddd. Seems,
that the concerned memory region wasn't zeroed out then and hence uncovered
the bug.

Of course, the runways.mk4 database has to be re-created with the new
definitions.

diff --git a/src/Airports/runways.cxx b/src/Airports/runways.cxx
index 75ad21984c94142033ac96c1bbfe83576a71a9e4..b768ea61b39a2dbaa0d60b6cb3fa712c72f9b1b0 100644 (file)
--- a/src/Airports/runways.cxx
+++ b/src/Airports/runways.cxx
@@ -61,7 +61,7 @@ FGRunways::FGRunways( const string& file ) {
 
     vRunway = new c4_View;
     *vRunway = 
-       storage->GetAs("runway[ID:S,Rwy:S,Longitude:F,Latitude:F,Heading:F,Length:F,Width:F,SurfaceFlags:S,End1Flags:F,End2Flags:F]");
+       storage->GetAs("runway[ID:S,Rwy:S,Longitude:F,Latitude:F,Heading:F,Length:F,Width:F,SurfaceFlags:S,End1Flags:S,End2Flags:S]");
 
     next_index = 0;
 }
@@ -410,7 +410,6 @@ int FGRunwaysUtil::load( const string& file ) {
 
 // save the data in gdbm format
 bool FGRunwaysUtil::dump_mk4( const string& file ) {
-
     // open database for writing
     c4_Storage storage( file.c_str(), true );
 
@@ -430,7 +429,7 @@ bool FGRunwaysUtil::dump_mk4( const string& file ) {
 
     // Start with an empty view of the proper structure.
     c4_View vRunway =
-       storage.GetAs("runway[ID:S,Rwy:S,Longitude:F,Latitude:F,Heading:F,Length:F,Width:F,SurfaceFlags:S,End1Flags:F,End2Flags:F]");
+       storage.GetAs("runway[ID:S,Rwy:S,Longitude:F,Latitude:F,Heading:F,Length:F,Width:F,SurfaceFlags:S,End1Flags:S,End2Flags:S]");
 
     c4_Row row;