I found something that might be a candidate for the overflow. Around this timeframe, some sprintf("%f") code got added to the atis handler. The problem is, printf() can generate almost unbounded output for very large values* and the buffer is only 10 bytes long.
* Try this: int main() { printf("%f\n", 1e300); } The attached patch to ATC/atis.cxx runs the value through a 32 bit integer to do the conversion, which will nicely truncate the value to fit within a 10 byte buffer. Note that this isn't necessarily the bug. The property in question is a tied value, which would have to contain garbage to trigger the overflow. Perhaps it might itself be overwritten with garbage by another overflow, maybe by a funny terrain interaction? That would jive with the report of a single tile causing the crash. It's something to try, anyway. Andy Index: atis.cxx =================================================================== RCS file: /var/cvs/FlightGear-0.9/source/src/ATC/atis.cxx,v retrieving revision 1.20 diff -u -r1.20 atis.cxx --- a/atis.cxx 24 Mar 2004 00:28:52 -0000 1.20 +++ b/atis.cxx 10 Apr 2004 15:37:57 -0000 @@ -184,9 +184,12 @@ if(ident.substr(0,2) == "EG" && fgGetBool("/sim/atc/use-millibars") == true) { // Convert to millibars for the UK! P *= 33.864; - sprintf(buf, "%.0f", P); + sprintf(buf, "%i", (int)(P+0.5)); } else { - sprintf(buf, "%.2f", P); + // Pass through an integer to avoid buffer overflows from + // very large values. Consider snprintf() instead... + int round = (int)(100*P + 0.5); + sprintf(buf, "%.2f", round * 0.01); } transmission += " / Altimeter "; tempstr1 = buf; _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel