Hi all,
I think there is a bug when using the native protocol to link two instances of
FlightGear via network or when recording and playing back flights using
fgfs --native=file,out,20,fgfs.out
and
fgfs --native,file,in,20,fgfs.out --fdm=external
The "external" FlightGear crashes and after some investigation I think the
problem is a missing operator =() method in FDM/flight.hxx
The problem is:
In Network/native.cxx a buffer is read either from network of from a file
containing the previously written fdm state. The content of the buffer is
than assigned to the current fdm state by doing
*cur_fdm_state = buf;
both variables are of type FGInterface which currently lacks a operator =()
method, so the compiler uses a simple memcpy to copy one object to the other.
This is almost ok but for the ground_cache object. This is a complex object
containing a std::vector<FGGroundCache::Triangle>. This vector seems to store
memory pointers to the Triangle-vertices. This is a very bad thing because
these pointers are invalid for any other FlightGear session and dereferencing
them causes a segmentation fault.
A very ugly - if not disgusting - workaround is adding the following to the
public methods of FGInterface in FDM/flight.hxx:
virtual const FGInterface & operator = ( FGInterface & src ) {
char * start = (char*)&inited;
char * end = (char*)&ground_cache;
memcpy( &inited, &src.inited, end-start );
prepare_ground_cache_m( 0, geodetic_position_v, 100.0 );
}
This gets called instead of a memcpy when assinging one FGInterface to another
and it does the memcpy for all member variables but the ground_cache. The
ground_cache itself is initialized for the recovered position with a fix
reference time of 0 and a radius of 100m.
At least this change fixes the segfault when replaying with the native
protocol, but I don't think this is the kind of code we want to see in
FlightGear for two reasons:
a) The pointer arithmetic assuming simple datatypes between the inited and
ground_cache variable
b) A constant used for reference time and the radius.
While a) may be circumnavigated by using explicit assignments for all
variables, I have no good idea for b). The radius might be saved when doing
the output, but I do not understand the idea of the reference time...
And there is one thing that is going round in my head: Curt reported, that he
does not have this problem at all and no one else (except tpalinkas) reported
this crash. Maybe this a a compiler/library problem?
Thanks for reading all that - any comment or help is appreciated.
Torsten
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
