I am testing the udp version of doing master/slave copies of FlightGear here
this morning. I'm doing this with a stock v1.0 version. So far everything
seems to be behaving well. I'm not seeing any rapid memory leak, and so far
no crash.
Are you seeing this only with file I/O? Are you seeing this with network
I/O? How long do you need to have the system running before you see memory
thrashing or a crash?
Thanks,
Curt.
On Jan 21, 2008 7:03 AM, tpalinkas wrote:
>
>
> 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
>
--
Curtis Olson: http://baron.flightgear.org/~curt/
-------------------------------------------------------------------------
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
