On Fri, 18 Jan 2008, Torsten Dreyer wrote:
> 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
>
We applied your patch and it fixed the initial segfault in slave.
(However, we experience double-free/corruption when the slave quits.)
Another strange bug is that if we start up in the wrong order (master
first, without the patch, this order caused an immediate segfault), the
initial states of the slave are messed up (altitude is -9999 ft; plane
permanently stuck in the ground). Doing a reset on the slave
fixes the problem even if we've taken off with the master.
TIA
Tibor Palinkas
-------------------------------------------------------------------------
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
